Cassandra  vs.  In-­‐Memory  Data  Grid    
in  e-­‐Commerce
	
  Соловьев	
  Александр	
  
solovyov.a.g@gmail.com	
  
Пилотный  проект:  перевод  иерархического  
online-­‐каталога  продуктов  на  Cassandra
Предыдущая	
  версия	
  каталога	...
Очень  вкратце  об  архитектуре  решения
•  Сервер	
  приложений:	
  бизнес-­‐логика	
  +	
  web-­‐сервисы	
  
•  …плюс	
 ...
Какой  должна  быть  система,  чтобы  решать  
эти  задачи?
Некоторые	
  идеи:	
  
•  Хранение	
  данные	
  на	
  диске,	
...
Основные  варианты,  из  которых  делался  
выбор
•  MongoDB	
  
•  exclusive	
  lock-­‐on-­‐write	
  на	
  уровне	
  колл...
Основные  варианты,  из  которых  делался  
выбор
•  Cassandra	
  
•  Простая	
  схема	
  кластера	
  (только	
  один	
  т...
Основные  требования  и  сценарии
•  Запросы	
  на	
  чтение:	
  5000	
  TPS	
  
•  запрос	
  может	
  включать	
  в	
  се...
Популярный  вопрос:  «Зачем  так  сложно?»
«Давайте	
  возьмем	
  MySQL,	
  покрытый	
  кэшом.	
  Или	
  что-­‐нибудь	
  е...
Вкратце  о  Cassandra
•  Распределенное	
  key-­‐value	
  хранилище	
  
•  Модель	
  хранения	
  данных	
  на	
  базе	
  с...
Еще  раз  об  архитектуре  решения
•  Сервер	
  приложений:	
  бизнес-­‐логика	
  +	
  web-­‐сервисы	
  
•  …плюс	
  локал...
Как  тестировали  на  производительность
•  Produc•on-­‐ready	
  реализация	
  
•  4	
  сервера	
  (16	
  CPU,	
  24	
  GB...
Что  улучшило  производительность
•  Корректно	
  настройте	
  ваш	
  Cassandra-­‐кластер:	
  
•  выключить	
  swap	
  
• ...
Что  улучшило  производительность
•  Ключ	
  «родительского»	
  объекта	
  как	
  первый	
  компонент	
  составного	
  
кл...
Интересные  факты
•  Мониторинг	
  GC	
  на	
  узлах	
  кластера	
  Cassandra	
  
•  на	
  рекомендованных	
  настройках	
...
Как  итог:
•  Cassandra	
  –	
  достаточно	
  зрелый	
  и	
  стабильный	
  продукт	
  
•  Сравнима	
  по	
  производительн...
 

Спасибо!

	
  
	
  
…и	
  ваши	
  вопросы	
  J	
  
Upcoming SlideShare
Loading in …5
×

Александр Соловьёв, Griddynamics.com

706 views
641 views

Published on

Highload++ 2013

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
706
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Александр Соловьёв, Griddynamics.com

  1. 1. Cassandra  vs.  In-­‐Memory  Data  Grid     in  e-­‐Commerce  Соловьев  Александр   solovyov.a.g@gmail.com  
  2. 2. Пилотный  проект:  перевод  иерархического   online-­‐каталога  продуктов  на  Cassandra Предыдущая  версия  каталога  построена  на  In-­‐Memory  Data  Grid   Oracle  Coherence.  Данные  из  основного  хранилища  (DB2)   загружаются  в  кластер  Coherence,  и  в  дальнейшем  читаются  только   оттуда.     Основные  цели  миграции:   •  Минимизация  времени  рестарта  кластера   •  Как  минимум  две  копии  данных  в  двух  разных  дата-­‐центрах   •  Быстрое  восстановление  из  бэкапа    
  3. 3. Очень  вкратце  об  архитектуре  решения •  Сервер  приложений:  бизнес-­‐логика  +  web-­‐сервисы   •  …плюс  Coherence  near  (local)  cache   •  несколько  узлов  за  балансировщиком  нагрузки.   •  Coherence  IMDG  как  хранилище  данных    
  4. 4. Какой  должна  быть  система,  чтобы  решать   эти  задачи? Некоторые  идеи:   •  Хранение  данные  на  диске,  это  сделает  данными  доступными   сразу  же  после  старта.  Дисковый  кэш  ОС  должен  быть  включен.   •  Key-­‐value  storage     Дополнительные  пожелания:   •  Простая  схема  развертывания   •  Java-­‐based  
  5. 5. Основные  варианты,  из  которых  делался   выбор •  MongoDB   •  exclusive  lock-­‐on-­‐write  на  уровне  коллекции   •  сложная  схема  деплоймента:  несколько  типов  узлов   •  Single  Point  Of  Failure  –  config  servers   •  non-­‐Java   •  HBase   •  изначально  построена  для  аналитики   •  Single  Point  Of  Failure  –  namenodes   •  сложный  деплоймент  
  6. 6. Основные  варианты,  из  которых  делался   выбор •  Cassandra   •  Простая  схема  кластера  (только  один  тип  узлов)   •  no  Single  Point  Of  Failure   •  Поддержка  нескольких  дата-­‐центров  «из  коробки»   •  Поддерживает  частичные  обновления  по  ключу   •  Была  достаточно  быстра  на  тестах…  в  случае,  если  объем  данных  не   больше,  чем  оперативная  память  на  всех  серверах   •  Написана  на  Java   •  Coherence  +  backing-­‐map  с  хранением  данных  на  диске  
  7. 7. Основные  требования  и  сценарии •  Запросы  на  чтение:  5000  TPS   •  запрос  может  включать  в  себя  несколько  последовательных  обращений   к  хранилищу  данных   •  запрос  может  содержать  несколько  ключей  (mul•-­‐gets)   •  Поддержка  частичных  обновлений  по  ключу   •  Обновление  всех  данных  раз  в  сутки   •  Availability  24x7   •  Размер  каталога  –  десятки  миллионов  ключей:  продукты,  их   атрибуты  и  т.д.  
  8. 8. Популярный  вопрос:  «Зачем  так  сложно?» «Давайте  возьмем  MySQL,  покрытый  кэшом.  Или  что-­‐нибудь  еще   проще  –  свое  файловое  хранилище»     Да,  это  было  бы  хорошим  вариантом,  но:   •  Нужна  масштабируемость   •  Мы  хотим  хранить  копии  данных  в  двух  дата-­‐центрах  
  9. 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. 10. Еще  раз  об  архитектуре  решения •  Сервер  приложений:  бизнес-­‐логика  +  web-­‐сервисы   •  …плюс  локальные  кэши  на  борту   •  Несколько  узлов  за  балансировщиком  нагрузки.   •  Cassandra  как  хранилище  данных   •  DataStax  Java  Driver  для  сервера  приложений    
  11. 11. Как  тестировали  на  производительность •  Produc•on-­‐ready  реализация   •  4  сервера  (16  CPU,  24  GB)  x  1  Cassandra  instance   •  2  сервера  x  2  app  servers   •  100  GB  тестовых  данных   •  Основной  тест  –  запросы  на  чтение   •  длительность  теста  –  1  час   •  до  500  «пользователей»   •  равномерное  распределение  запрашиваемых  элементов  
  12. 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. 13. Что  улучшило  производительность •  Ключ  «родительского»  объекта  как  первый  компонент  составного   ключа  для  дочерних  объектов:  PRIMARY  KEY  (parent-­‐ID,  child-­‐ID).   •  уменьшает  число  запросов  к  Cassandra  и  дисковую  активность   •  +15%  TPS,  +2x  latency   •  Локальные  кэши  на  серверах  приложений:  +15%  TPS  
  14. 14. Интересные  факты •  Мониторинг  GC  на  узлах  кластера  Cassandra   •  на  рекомендованных  настройках  все  достаточно  хорошо  J   •  Кэширование  всех  данных  в  памяти  JVM  Cassandra  (caching  =  ALL)   почти  не  улучшило  результаты  –  данные  в  дисковом  кэше  ОС   •  Хранение  данных  в  собственном  формате  (например,  JSON),  если   не  требуется  частичного  обновления   •  позволяет  избежать  создания  большого  числа  tombstones,  если  частью   значений  являются  Cassandra-­‐коллекции   •  token-­‐aware  маршрутизация  запросов  к  кластеру  
  15. 15. Как  итог: •  Cassandra  –  достаточно  зрелый  и  стабильный  продукт   •  Сравнима  по  производительности  с  In-­‐Memory  Data  Grid’ами,   если  суммарный  объем  данных  не  больше,  чем  общая  память   кластера   •  Активно  развивается.  Имеет  большое  community.  Достаточно   хорошая  платная  поддержка  от  DataStax.  
  16. 16.   Спасибо!     …и  ваши  вопросы  J  

×