Cassandra  vs.  In-­‐Memory  Data  Grid    in  e-­‐Commerce

 Соловьев  Александр  solovyov.a.g@gmail.com  

Пилотный  проект:  перевод  иерархического  online-­‐каталога  продуктов  на  Cassandra Предыдущая  версия  каталога  построена  на  In-­‐Memory  Data  Grid  Oracle  Coherence.  Данные  из  основного  хранилища  (DB2)  загружаются  в  кластер  Coherence,  и  в  дальнейшем  читаются  только  оттуда.    Основные  цели  миграции:  • Минимизация  времени  рестарта  кластера  • Как  минимум  две  копии  данных  в  двух  разных  дата-­‐центрах  • Быстрое  восстановление  из  бэкапа    

Очень  вкратце  об  архитектуре  решения

• Сервер  приложений:  бизнес-­‐логика  +  web-­‐сервисы  •  …плюс  Coherence  near  (local)  cache  •  несколько  узлов  за  балансировщиком  нагрузки.  

• Coherence  IMDG  как  хранилище  данных    

Какой  должна  быть  система,  чтобы  решать  эти  задачи? Некоторые  идеи:  • Хранение  данные  на  диске,  это  сделает  данными  доступными  сразу  же  после  старта.  Дисковый  кэш  ОС  должен  быть  включен.  • Key-­‐value  storage    Дополнительные  пожелания:  • Простая  схема  развертывания  •  Java-­‐based  

Основные  варианты,  из  которых  делался  выбор • MongoDB  

•  exclusive  lock-­‐on-­‐write  на  уровне  коллекции  •  сложная  схема  деплоймента:  несколько  типов  узлов  •  Single  Point  Of  Failure  –  config  servers  •  non-­‐Java  

• HBase  •  изначально  построена  для  аналитики  •  Single  Point  Of  Failure  –  namenodes  •  сложный  деплоймент  

Основные  варианты,  из  которых  делался  выбор • Cassandra  

•  Простая  схема  кластера  (только  один  тип  узлов)  •  no  Single  Point  Of  Failure  •  Поддержка  нескольких  дата-­‐центров  «из  коробки»  •  Поддерживает  частичные  обновления  по  ключу  •  Была  достаточно  быстра  на  тестах…  в  случае,  если  объем  данных  не  больше,  чем  оперативная  память  на  всех  серверах  •  Написана  на  Java  

• Coherence  +  backing-­‐map  с  хранением  данных  на  диске  

Основные  требования  и  сценарии

•  Запросы  на  чтение:  5000  TPS  •  запрос  может  включать  в  себя  несколько  последовательных  обращений  к  хранилищу  данных  •  запрос  может  содержать  несколько  ключей  (mul�-­‐gets)  

• Поддержка  частичных  обновлений  по  ключу  • Обновление  всех  данных  раз  в  сутки  • Availability  24x7  • Размер  каталога  –  десятки  миллионов  ключей:  продукты,  их  атрибуты  и  т.д.  

Популярный  вопрос:  «Зачем  так  сложно?»

«Давайте  возьмем  MySQL,  покрытый  кэшом.  Или  что-­‐нибудь  еще  проще  –  свое  файловое  хранилище»    Да,  это  было  бы  хорошим  вариантом,  но:  • Нужна  масштабируемость  • Мы  хотим  хранить  копии  данных  в  двух  дата-­‐центрах  

Вкратце  о  Cassandra

• Распределенное  key-­‐value  хранилище  • Модель  хранения  данных  на  базе  столбцов  •  Eventually  consistent?  -­‐  Tunable  consistency  • Построена  на  Log-­‐Structured  Merge  Tree    h�p://en.wikipedia.org/wiki/Apache_Cassandra  h�p://cassandra.apache.org/  

Еще  раз  об  архитектуре  решения

• Сервер  приложений:  бизнес-­‐логика  +  web-­‐сервисы  •  …плюс  локальные  кэши  на  борту  •  Несколько  узлов  за  балансировщиком  нагрузки.  

• Cassandra  как  хранилище  данных  •  DataStax  Java  Driver  для  сервера  приложений  

 

Как  тестировали  на  производительность

• Produc�on-­‐ready  реализация  •  4  сервера  (16  CPU,  24  GB)  x  1  Cassandra  instance  •  2  сервера  x  2  app  servers  •  100  GB  тестовых  данных  • Основной  тест  –  запросы  на  чтение  

•  длительность  теста  –  1  час  •  до  500  «пользователей»  •  равномерное  распределение  запрашиваемых  элементов  

Что  улучшило  производительность

• Корректно  настройте  ваш  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    

Что  улучшило  производительность

• Ключ  «родительского»  объекта  как  первый  компонент  составного  ключа  для  дочерних  объектов:  PRIMARY  KEY  (parent-­‐ID,  child-­‐ID).  •  уменьшает  число  запросов  к  Cassandra  и  дисковую  активность  •  +15%  TPS,  +2x  latency  

• Локальные  кэши  на  серверах  приложений:  +15%  TPS  

Интересные  факты

• Мониторинг  GC  на  узлах  кластера  Cassandra  •  на  рекомендованных  настройках  все  достаточно  хорошо  J  

• Кэширование  всех  данных  в  памяти  JVM  Cassandra  (caching  =  ALL)  почти  не  улучшило  результаты  –  данные  в  дисковом  кэше  ОС  • Хранение  данных  в  собственном  формате  (например,  JSON),  если  не  требуется  частичного  обновления  •  позволяет  избежать  создания  большого  числа  tombstones,  если  частью  значений  являются  Cassandra-­‐коллекции  

•  token-­‐aware  маршрутизация  запросов  к  кластеру  

Как  итог:

• Cassandra  –  достаточно  зрелый  и  стабильный  продукт  • Сравнима  по  производительности  с  In-­‐Memory  Data  Grid’ами,  если  суммарный  объем  данных  не  больше,  чем  общая  память  кластера  • Активно  развивается.  Имеет  большое  community.  Достаточно  хорошая  платная  поддержка  от  DataStax.  

Спасибо!  

   

…и  ваши  вопросы  J