Документ сравнивает использование Cassandra и in-memory data grid в контексте электронной коммерции, описывая миграцию онлайн-каталога на Cassandra для повышения производительности и надежности. Основное внимание уделяется архитектуре решения, требованиям к производительности и причинам выбора Cassandra как системы хранения данных. Также упоминаются улучшения производительности и особенности, такие как поддержка нескольких дата-центров и отсутствие единой точки сбоя.

1. Cassandra vs. In-­‐Memory Data Grid
in e-­‐Commerce
Соловьев
Александр
solovyov.a.g@gmail.com

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.

16.
Спасибо!
…и
ваши
вопросы
J