Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

942 views

Published on

Highload++ 2013

  • Be the first to comment

  • Be the first to like this

Александр Соловьёв, 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  

×