2. Пилотный проект: перевод иерархического
online-‐каталога продуктов на Cassandra
Предыдущая
версия
каталога
построена
на
In-‐Memory
Data
Grid
Oracle
Coherence.
Данные
из
основного
хранилища
(DB2)
загружаются
в
кластер
Coherence,
и
в
дальнейшем
читаются
только
оттуда.
Основные
цели
миграции:
• Минимизация
времени
рестарта
кластера
• Как
минимум
две
копии
данных
в
двух
разных
дата-‐центрах
• Быстрое
восстановление
из
бэкапа
3. Очень вкратце об архитектуре решения
• Сервер
приложений:
бизнес-‐логика
+
web-‐сервисы
• …плюс
Coherence
near
(local)
cache
• несколько
узлов
за
балансировщиком
нагрузки.
• Coherence
IMDG
как
хранилище
данных
4. Какой должна быть система, чтобы решать
эти задачи?
Некоторые
идеи:
• Хранение
данные
на
диске,
это
сделает
данными
доступными
сразу
же
после
старта.
Дисковый
кэш
ОС
должен
быть
включен.
• Key-‐value
storage
Дополнительные
пожелания:
• Простая
схема
развертывания
• Java-‐based
5. Основные варианты, из которых делался
выбор
• MongoDB
• exclusive
lock-‐on-‐write
на
уровне
коллекции
• сложная
схема
деплоймента:
несколько
типов
узлов
• Single
Point
Of
Failure
–
config
servers
• non-‐Java
• HBase
• изначально
построена
для
аналитики
• Single
Point
Of
Failure
–
namenodes
• сложный
деплоймент
6. Основные варианты, из которых делался
выбор
• Cassandra
• Простая
схема
кластера
(только
один
тип
узлов)
• no
Single
Point
Of
Failure
• Поддержка
нескольких
дата-‐центров
«из
коробки»
• Поддерживает
частичные
обновления
по
ключу
• Была
достаточно
быстра
на
тестах…
в
случае,
если
объем
данных
не
больше,
чем
оперативная
память
на
всех
серверах
• Написана
на
Java
• Coherence
+
backing-‐map
с
хранением
данных
на
диске
7. Основные требования и сценарии
• Запросы
на
чтение:
5000
TPS
• запрос
может
включать
в
себя
несколько
последовательных
обращений
к
хранилищу
данных
• запрос
может
содержать
несколько
ключей
(mul•-‐gets)
• Поддержка
частичных
обновлений
по
ключу
• Обновление
всех
данных
раз
в
сутки
• Availability
24x7
• Размер
каталога
–
десятки
миллионов
ключей:
продукты,
их
атрибуты
и
т.д.
8. Популярный вопрос: «Зачем так сложно?»
«Давайте
возьмем
MySQL,
покрытый
кэшом.
Или
что-‐нибудь
еще
проще
–
свое
файловое
хранилище»
Да,
это
было
бы
хорошим
вариантом,
но:
• Нужна
масштабируемость
• Мы
хотим
хранить
копии
данных
в
двух
дата-‐центрах
9. Вкратце о Cassandra
• Распределенное
key-‐value
хранилище
• Модель
хранения
данных
на
базе
столбцов
• Eventually
consistent?
-‐
Tunable
consistency
• Построена
на
Log-‐Structured
Merge
Tree
hŒp://en.wikipedia.org/wiki/Apache_Cassandra
hŒp://cassandra.apache.org/
10. Еще раз об архитектуре решения
• Сервер
приложений:
бизнес-‐логика
+
web-‐сервисы
• …плюс
локальные
кэши
на
борту
• Несколько
узлов
за
балансировщиком
нагрузки.
• Cassandra
как
хранилище
данных
• DataStax
Java
Driver
для
сервера
приложений
11. Как тестировали на производительность
• Produc•on-‐ready
реализация
• 4
сервера
(16
CPU,
24
GB)
x
1
Cassandra
instance
• 2
сервера
x
2
app
servers
• 100
GB
тестовых
данных
• Основной
тест
–
запросы
на
чтение
• длительность
теста
–
1
час
• до
500
«пользователей»
• равномерное
распределение
запрашиваемых
элементов
12. Что улучшило производительность
• Корректно
настройте
ваш
Cassandra-‐кластер:
• выключить
swap
• commit
log
и
данные
-‐
на
разных
дисках
• берем
«правильный»
network
interface
• Асинхронные
запросы
для
нескольких
ключей
+
token-‐aware
rou•ng
на
стороне
сервера
приложений:
+15%
TPS
• Используйте
последнюю
версию
Cassandra
• Пример:
v.
1.2.6
=>
v.
1.2.8
=
+15%
TPS,
+2x
latency
13. Что улучшило производительность
• Ключ
«родительского»
объекта
как
первый
компонент
составного
ключа
для
дочерних
объектов:
PRIMARY
KEY
(parent-‐ID,
child-‐ID).
• уменьшает
число
запросов
к
Cassandra
и
дисковую
активность
• +15%
TPS,
+2x
latency
• Локальные
кэши
на
серверах
приложений:
+15%
TPS
14. Интересные факты
• Мониторинг
GC
на
узлах
кластера
Cassandra
• на
рекомендованных
настройках
все
достаточно
хорошо
J
• Кэширование
всех
данных
в
памяти
JVM
Cassandra
(caching
=
ALL)
почти
не
улучшило
результаты
–
данные
в
дисковом
кэше
ОС
• Хранение
данных
в
собственном
формате
(например,
JSON),
если
не
требуется
частичного
обновления
• позволяет
избежать
создания
большого
числа
tombstones,
если
частью
значений
являются
Cassandra-‐коллекции
• token-‐aware
маршрутизация
запросов
к
кластеру
15. Как итог:
• Cassandra
–
достаточно
зрелый
и
стабильный
продукт
• Сравнима
по
производительности
с
In-‐Memory
Data
Grid’ами,
если
суммарный
объем
данных
не
больше,
чем
общая
память
кластера
• Активно
развивается.
Имеет
большое
community.
Достаточно
хорошая
платная
поддержка
от
DataStax.
