Download to read offline
Uploaded byIT Event
Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"
Документ рассматривает проектирование глобально распределенных кластеров NoSQL на платформе AWS, подчеркивая важность учета специфики баз данных и сценариев использования. Обсуждаются различные подходы, технологии, особенности проектирования и мониторинга, а также преимущества использования сервисов, таких как Amazon DynamoDB и Amazon S3 с Athena. В конце документа подчеркивается, что одно универсальное решение не существует, и выбор технологии должен уточняться в зависимости от контекста и требований приложения.
More Related Content
Similar to Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"
Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"
- 2. Architecture of NoSQL distributedclusters on AWS Andrey Zaychikov Solutions Architect, Amazon Web Services, Luxembourg
- 3. Программа и целипрезентации • Рассмотрим основные проблемы, связанные с проектированием глобально распределенных кластеров NoSQL и опишем подход к проектированию подобных систем • Посмотрим, как этот подход может быть использован на примере построения глобально распределенных кластеров Cassandra и MongoDB • Разберемся в отличиях и особенностях проектирования в зависимости от типа БД и её реализации
- 4. Почему появились распределенныеNoSQL БД? Сложность схем данных Объем данных Uptime
- 5. Характерные черты распределенныхсистем Сложное поведение Сложная структура
- 6.
- 7.
- 8.
- 9. Значение Cloud Computingдля NoSQL Скорость масштабирования Простота организации глобального присутствия On-demand pricing
- 10. Решения NoSQL наплатформе AWS DynamoDB S3 + Athena NoSQL on EC2 (+ EBS) Полностью управляемый сервис баз данных NoSQL, обеспечивающий прогнозируемую высокую производительность с эффективной масштабируемостью. Amazon DynamoDB дает клиентам возможность переложить на AWS административную нагрузку, по управлению распределенными базами данных и их масштабированием. Amazon Athena – это интерактивный сервис запросов, позволяющий легко анализировать данные в хранилище Amazon S3 с помощью стандартных средств SQL. У Athena –нет инфраструктуры, требующей настройки или управления, поэтому можно сразу же приступить к анализу данных. Вычислительное облако Amazon Elastic Compute Cloud (Amazon EC2) – это веб-сервис, предоставляющий безопасные масштабируемые вычислительные ресурсы в облаке. Он помогает разработчикам, облегчая проведение крупномасштабных вычислений в облаке.
- 11. Подход к проектированиюглобально распределенных NoSQL БД • Оценка необходимости создания распределенной системы и применимости NoSQL • Проектирование сценария использования • Выбор технологии NoSQL • Проектирование приложений • Проектирование технической реализации • Проектирование и организация операционной деятельности
- 12. Нужны ли ввашем проекте распределенные NoSQL решения • Высокая нагрузка существенно изменяющая во времени • Отсутствие существенных требований к консистентности данных • Парадоксально высокий uptime • Относительно простая схема без наличия существенного количества связей • Отсутствие необходимости моментально строить отчетность по всему объему данных • Высокие требования к latency со стороны клиентских приложений • Высокие требования к консистентности данных • Стабильная нагрузка без существенных изменений в течение времени • Относительно редко меняющаяся схема в хорошо определенной предметной области • Отсутствие сверх высоких требований по доступности и latency по запросам со стороны приложений • Необходимость строить отчетность / анализ с использованием полного функционала SQL
- 13.
- 14. Выбор технологии • Спецификаприложений • Сценарий использования • Модель развертывания • Собственная экспертиза • Необходимость тюнинга • Схема данных • Показатели производительности • Показатели надежности • Специфика развития продукта • Модель обслуживания DynamoDB Cloud-based Self-managed (EC2) Key-value Document-oriented Graph Mixed
- 15.
- 16.
- 17.
- 18. Проектирование схемы данных •Наборы данных (keyspaces, collections) • Идентификационные ключи и ключи распределения данных • Структура индексов • Структура коллекций • Структура запросов • Структура связей Проектирование схемы данных существенно различается в зависимости от класса БД (document-oriented, key-value, graph, etc.) и в большой степени зависит от особенностей реализации конкретной БД.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. Выбор типов вычислительныхресурсов и хранилищ Всегда базируется на специфике базы данных, специфике схемы и паттернов доступа. Тип вычислительных ресурсов и хранилищ должен адаптироваться под конкретные нужды. Cassandra MongoDB
- 27.
- 28.
- 29.
- 30. Планирование вычислительных сетей •Топология сети • Конфигурация сети • Высокая доступность сети / каналов • Маршрутизация • Правила firewall’ов • MTU • Оптимизация трафика
- 31.
- 32. Планирование мониторинга • Мониторингвычислительных ресурсов • 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 Сильно зависит от специфики реализации конкретной базы данных на уровне узла (чтение / запись данных) и на уровне кластера (репликация).
- 33.
- 34.
- 35. Планирование обслуживания • Уведомленияи реагирование на инциденты • 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
- 36. Пример: Планирование обслуживания •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
- 37. Вместо заключения • Несуществует одного решения на все случаи жизни • Контекст имеет значение и решение должно изменяться вслед за изменением контекста • Приложение и код должны быть адаптированы к БД • Наилучший способ проверить ваш выбор БД для применения в вашем решении – провести Proof- of-Concept
- 38.