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

  • 459 views
Uploaded on

Highload++ 2013

Highload++ 2013

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
459
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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