Опыт внедрения и использования распределенной...
TRANSCRIPT
Опыт внедрения и использования распределенной системы хранения данных на основе
Voldemort+Tarantool
О чем данный доклад?
• Опыт использования NoSQL разных типов
• Архитектура существующего решения на основе BerkeleyDB
• Цель внедрения распределенной системы хранения данных
• Архитектура хранилища данных на основе Voldemort и Tarantool
• Проблемы, с которыми столкнулись и пути их решения
• Преимущества и недостатки каждого из решений
• Результаты внедрения на примере сервиса отправки сообщений
Существующее решениеАрхитектурно хранилище CP-типа с горизонтальным партиционированием:one-db — BerkeleyDB 4.5 (Си) + Remote Interface (JBoss remoting)
Node 1
Remote interface
Master 1
Slave 1
Node 2
Remote interface
Master 2
Slave 2
Node N
Remote interface
Master N
Slave N
Remote clients
JBoss remoting JBoss remoting JBoss remoting
Партиционирование по младшему байту ключа. 256 возможных партиций
...
Недостатки существующего решения
• Невысокая производительность < 10K операций в секунду с одной ноды
• Низкая отказоустойчивость (SPOF)
• Сложное обслуживание (ручная работа по восстановлению)
• Высокая стоимость оборудования (В случае интенсивных операций update slave может использоваться только как backup)
Цель внедрения распределенной системы хранения данных
• Высокая отказоустойчивость (SPOF)
• Неограниченная масштабируемость без down time
• Максимальная производительность на чтение/запись
• Возможность использования дешевого железа
• Простота обслуживания (минимум ручной работы, только для восстановления персистентных отказов оборудования)
Свойства распределенных систем AP-типа
+ Высокая доступность (High Availability), отсутствие SPOF
+ Устойчивость к отказам сегментов сети (Partition tolerance)
+ Масштабируемость без down time
- Eventual Consistency (согласованность в конечном счете)
- Неопределенное состояние данных в случае timeout или quorum fail
Анализ существующих решений• Cassandra 0.6.4
+ Табличная модель данных (на подобие Google Big Table)+ Поддерживает Hinted Handoff+ Java- Отсутствие механизма разрешения конфликтов (есть только timestamp для колонки)
• Voldemort 0.8.1+ Разные backend (default BerkeleyDB)+ Механизм отслеживания параллельных изменений (Vector Clock)+ Java- Отсутствие Hinted Handoff
• Riak+ Сопоставим с Voldemort- Erlang
Исследование производительностиТесты для кластера 3 ноды с replication factor 3, read/write quorum 2 Сервера SuperMicro 2 CPU(8 cores), RAM 32 GB, 500 GB SATA 7200. Размер данных < 5Kb, объем данных 25G, сценарий: read 50%, write 50%
• Cassandra 0.6.4 Read: ~8-9K ops Write: > 20K ops Увеличение размеров хранимых данных для разрешения конфликтов
• Voldemort 0.8.1 (BerkeleyDB) Read: ~32K ops Write: ~7.5K ops
• Voldemort 0.8.1 (Tarantool) Read: ~36K ops Write: ~9K ops
Архитектура на основе Voldemort + Tarantool Node 1
Voldemort
Tarantool
Voldemort clientsQuorum r=2, w=2
...
Cleanup SchedulerQuorum r=2, w=3
Node 2
Voldemort
Tarantool
Node N
Voldemort
Tarantool
Функционирование Voldemort cluster
• Replication factor 3, quorum read: 2, write:2. R+W>N (strong consistency)
• Vector clock + Custom conflict resolver
• Использование проверок для уменьшения повторных обновлений
• Segment locks на каждой ноде для операций модифицирующих данные
• Использование soft delete (маркировка)
• Нет Hinted Handoff (частично компенсируется процедурой cleanup)
Функционирование Cleanup scheduler
• Сканирование всех ключей хранимых в Tarantool
• Проверка данных в Voldemort на наличие признака soft delete
• Восстановление данных по read repair
• Для hard delete необходимо перемаркировать с quorum write 3.
В случае успешной маркировки возможно физическое удаление
Проблемы, с которыми столкнулись
• Отсутствие Hinted Handoff (реализовано в версии 0.9)• Ошибка в работе процедуры восстановления ноды кластера:
- Заливались данные, которые не принадлежат данной ноде согласно hash ring- Переполнение in-memory storage+ Используется собственный fix (должно быть исправлено в версии 0.9)
• Особенности процедуры перебалансировки- Нельзя одновременно переносить партиции с репликами друг друга- Для равномерной балансировки требуется предварительный анализ кластерной конфигурации.
Нагрузка на примере сервиса обмена сообщениями Отосланных сообщений ~170M в день
Операций с диалогами ~30K в секунду (чтений 22K, запись 8К)
СообщенияДиалоги
Результаты внедрения распределенного хранилища для пользовательских диалогов
• Отсутствие SPOF• Масштабируемость без down time• Уменьшение размеров кластера с 18 серверов до 10 (загрузка RAM на 50%)• Время старта кластера ~10 минут• Время полного восстановления ноды с реплик ~30минут• Необходимость ручной работы только в случае down time на нодах с
пересечением данных• Увеличение среднего времени операций на ~80%• Наличие небольшого количества повторных изменений ~3∙10-5% (~100 в
день)
Количество операций, выполняющихся на
Voldemort cluster, в 5 минут
Количество операций, выполняющихся
с пользовательскими диалогами, в 5 минут
Среднее время выполнения операций с диалогами
