Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

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

•
•
Ontico
Ontico

Highload++ 2013

Related slideshows

Кирилл Алешин, Ламбда Архитектура на практике
Кирилл Алешин, Ламбда Архитектура на практикеКирилл Алешин, Ламбда Архитектура на практике
Кирилл Алешин, Ламбда Архитектура на практике
 
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"
 
Распределённый кэш или хранилище данных. Что выбрать?
Распределённый кэш или хранилище данных. Что выбрать?Распределённый кэш или хранилище данных. Что выбрать?
Распределённый кэш или хранилище данных. Что выбрать?
 
1 of 16
Download to read offline
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  

More Related Content

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

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