Downloaded 17 times
Uploaded byAleksandr Maklakov
Architecture of NoSQL distributed clusters on AWS
Документ рассматривает проектирование глобально распределенных кластеров NoSQL на платформе AWS, включая подходы к созданию систем и выбор технологий, таких как Cassandra и MongoDB. Обсуждаются причины, по которым появились распределенные NoSQL базы данных, и предоставляются практические рекомендации по проектированию схем данных, их взаимодействию с приложениями и планированию мониторинга. В заключении подчеркивается важность адаптации решений к специфике каждого проекта и проведение пробного тестирования выбранной технологии.
Architecture of NoSQL distributed clusters on AWS
- 1.
- 2. Программа и цели презентации • Рассмотрим основные проблемы, связанные с проектированием глобально распределенных кластеров NoSQL и опишем подход к проектированию подобных систем • Посмотрим, как этот подход может быть использован на примере построения глобально распределенных кластеров Cassandra и MongoDB •Разберемся в отличиях и особенностях проектирования в зависимости от типа БД и её реализации
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. Решения NoSQL на платформе AWS S3 + Athena NoSQL on EC2 Полностью управляемый сервис баз данных NoSQL, обеспечивающий прогнозируемую высокую производительность с эффективной масштабируемостью. Amazon DynamoDBдает клиентам возможность переложить на AWS административную нагрузку, по управлению распределенными базами данных и их масштабированием. Amazon Athena – это интерактивный сервис запросов, позволяющий легко анализировать данные в хранилище Amazon S3 с помощью стандартных средств SQL. У Athena –нет инфраструктуры, требующей настройки или управления, поэтому можно сразу же приступить к анализу данных. Вычислительное облако Amazon Elastic Compute Cloud (Amazon EC2) – это веб-сервис, предоставляющий безопасные масштабируемые вычислительные ресурсы в облаке. Он помогает разработчикам, облегчая проведение крупномасштабных вычислений в облаке. Amazon EMR – это веб- сервис, который позволяет компаниям, ученым, аналитикам и разработчикам легко и недорого обрабатывать огромные объемы данных. В нем используется удаленная инфраструктура Hadoop, работающая в масштабной вычислительной инфраструктуре Amazon Elastic Compute Cloud. EMR
- 10. Подход к проектированию глобально распределенных NoSQL БД • Оценка необходимости создания распределенной системы и применимости NoSQL • Проектирование сценария использования •Выбор технологии NoSQL • Проектирование приложений • Проектирование технической реализации • Проектирование и организация операционной деятельности
- 11. Нужны ли в вашем проекте распределенные NoSQL решения • Высокая нагрузка существенно изменяющаяся во времени • Отсутствие критических требований к консистентностиданных • Парадоксально высокий uptime • Относительно простая схема без наличия значительного количества связей • Отсутствие необходимости моментально строить отчетность по всему объему данных • Высокие требования к latency со стороны клиентских приложений • Высокие требования к консистентности данных • Стабильная нагрузка без существенных изменений в течение времени • Относительно редко меняющаяся схема в хорошо определенной предметной области • Отсутствие сверх высоких требований по доступности и latency по запросам со стороны приложений • Необходимость строить отчетность / анализ с использованием полного функционала SQL
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. Проектирование схемы данных • Наборы данных (keyspaces, collections) • Идентификационные ключи и ключи распределения данных •Структура индексов • Структура коллекций • Структура запросов • Структура связей Проектирование схемы данных существенно различается в зависимости от класса БД (document-oriented, key-value, graph, etc.) и в большой степени зависит от особенностей реализации конкретной БД.
- 19.
- 20. Проектирование схемы данных • Правильный выбор PRIMARY_KEY • Корректное разделение на keyspacesи column families • Массовое дублирование данных • Структура запросов • Пред процессинг данных для формирования отчетности и read-intensive workloads
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32. Планирование вычислительных сетей • Топология сети • Конфигурация сети •Высокая доступность сети / каналов • Маршрутизация • Правила firewall’ов • MTU • Оптимизация трафика
- 33.
- 34. Планирование мониторинга • Мониторинг вычислительных ресурсов • CPU •RAM • Disk IO, saturation • Network throughput, saturation • Мониторинг системных процессов • Write Logs • Garbage Collection • Locks • Queueing • Мониторинг узлов кластера БД • Read / Write IO • Read / Write Latency • Internal tasks • Мониторинг запросов приложений • Unavailable Errors • Timeout Errors • Other types of exceptions • Мониторинг состояния кластера • Nodes status • Replication status / lag Сильно зависит от специфики реализации конкретной базы данных на уровне узла (чтение / запись данных) и на уровне кластера (репликация).
- 35.
- 36.
- 37. Планирование обслуживания • Уведомления и реагирование на инциденты • Alarms & notifications (правильные метрики •RCA • Playbook • Настройка и контроль выполнения рутинных операций на уровне кластера • Anti-entropy operations • Cluster-wide clean-ups • Cluster-wide / Shard-wide backups • Other • Настройка и контроль выполнения рутинных операций на уровне узлов кластера • Defragmentation • Compression / Compaction • Encryption • Incremental and Full Backup • Index re-build
- 38. Пример: Планирование обслуживания • Regular cluster / partition wide repair of data (depends on gc_grace_period) •Cluster wide time sync • Per node compactions procedures • Manual split of SSTables to avoid appearance of HUGE SSTables • Rotate log files • Per node data defragmentation
- 39. Вместо заключения • Не существуетодного решения на все случаи жизни • Контекст имеет значение и решение должно изменяться вслед за изменением контекста • Приложение и код должны быть адаптированы к БД • Наилучший способ проверить ваш выбор БД для применения в вашем решении – провести Proof-of-Concept
- 40.