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.
Сравнительный анализ  хранилищ данных      Коринский и Царев
О чём этот доклад?●   Существует пропасть между разработчиками и DBA    Отсутствуют популярные материалы по данной теме●  ...
Зачем нужны транзакции?●   Примеры:    ●   Оплата счёта    ●   Размещение поста в блоге    ●   Покупка билета
Транзакциии●   Транзакция - <здесь по идее нужно определение>●   Наивно: последовательность действий, со    следующими сво...
Транзакции●   Atomic: Последовательность действий    применияется целиком, либо не применяется    вообще●   Consistence: Д...
Партицирование●   Партицирование - деление данных на части между    различными файлами, разделами диска или машинами в    ...
Аспекты партицирования●   Виды: способы деления данных на части●   Назначение: какие проблемы решает●   Примеры: использов...
Функциональная декомпозиция●   Суть: Данные бьются на части в соотвествии с    семантикой.●   Возможные критерии:    ●   Т...
Горизонтальное партицирование●   Суть: Множество однотипных данных разделяется на (равные) части    по некоторому критерию...
Горизонтальное партицирование●   Примеры хеш-функций:    ●   Числа: остаток от деления на десять (десять        возможных ...
Вертикальное партицирование●   Суть: Однотипные данные разделяются    группируются в части по атрибутам●   Критерии:    ● ...
Column/Row-oriented system●   Суть: данные организуются либо по строкам, либо по    колонкам●   Row-oriented:    ●   Все а...
Enviroment●   Операционные системы●   Файловые системы●   Сеть●   Аппаратура●   Поддержка на уровне хранилища
Транзакции и партицирование●   Транзакции вносят свои проблемы:    ●   atomic: синхронность применения        (консистентн...
Репликация●   Репликация - способ    синхронизации (приведение в    соответствие) частей данных●   Виды репликации:    ●  ...
Master-Slave репликация●   Все изменения применяются на    master●   Slave-узлы получает обновления с    master●   Slave-у...
Назначение●   Резервные копии - плохая идея●   Распределение нагрузки●   Таргетирование запросов
Таргетирование запросов●   Различные хранилища на    master/slave:    ●   master - OLTP, slave – OLAP    ●   master - SQL,...
Таргетирование запросов●   Различная схема данных:    ●   master содержит просто таблицы для записи    ●   slave имеет доп...
Таргетирование запросов●   Различная схема данных:    ●   master содержит просто таблицы для записи    ●   slave имеет доп...
Master-Master репликация●   Суть: Изменения производятся    одновременно на нескольких master●   Защищаемся от выхода из с...
Транзакции и репликации●   Транзакции вносят свои проблемы    ●   master-slave: транзакции на slave        запаздывают    ...
Consistency●   Система всегда выдает корректные,    непротиворечивые, ответы.●   Данные не могут потеряться после    завер...
Availability●   Система обязана всегда выдавать    ответы - независимо от    аппаратных сбоев отдельных    узлов.
Partition tolerance●   Система продолжает работать    корректно при недоступности    части узлов.
Проблема CAP теоремы Только два из трех
Про что говорим●   Voldemort, Riak, cassandra, MySQL    cluster●   MongoDB, Hbase,    memcache/memcached, berkleydb●   Pos...
+Consistency +Availability -Partition tolerance●   PostgreSQL●   MySQL●   Oracle●   TimesTen
PostgreSQL●   Очень много разных индексов●   PostGIS●   Репликация внешними средствами●   Сложна
MySQL●   Привычная база●   Есть репликация●   Простота поддержки
Oracle●   Умеет все●   Дорого
TimesTen●   Быстрая in memory база●   Простота●   Цена
PostgreSQL vs MySQL vs Oracle vs TimesTen●   есть деньги oracle/timesten●   хватает – postgres●   иначе mysql
+Availability +Partition tolerance -Consistency●   Voldemort●   Riak●   Cassandra●   MySQL cluster
Voldemort●   Написан на Java, REST●   Key-value●   LinkedIn●   разные backend
Riak●   Написан на Erlang, REST●   Key-value●   разные backend
Riak vs Voldemort●   Одинаковы
Cassandra●   Написана на Java, Thrift api●   Column-oriented●   Разные датацентры
MySQL cluster●   Написана на С●   Честный SQL●   in memeory
Riak/Voldemort vs Cassandra vs MySQL cluster●   совместимость MySQL●   map reduce: Riak
+Consistency +Partiotion tolerance -Availability●   MongoDB●   Hbase●   memcache/memcached●   berkleydb
MongoDB●   Написана на C++, BSON●   Key-value●   github, sourceforge, bit.ly, disqus
Hbase●   Написана на Java, REST●   column-oriented
memcache/memcached●   Написаны на С, Простой протокол●   Key-value●   используется везде
berkleydb●   Написана на С, C-API●   Key-value●   стоит денег
MongoDB vs Hbase bs memcached vs berkleydb●   кеш memcached●   hbase как замена bigtable●   встраиваемая berkleydb
CAP Solution●   Жертвуем Consistency●   Разбиваем систему на части●   Система в разные моменты    времени находиться в раз...
Счастья нет●   У каждой задачи свои требования●   У каждого хранилища свои сильные и    слабые стороны●   Хранилище под за...
Any question? Oleg Tsarev               Kirill A. Korinskiy oleg.tsarev@percona.com   kkorinsky@rooxteam.com http://percon...
Upcoming SlideShare
Loading in …5
×

Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)

1,081 views

Published on

  • Be the first to comment

Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)

  1. 1. Сравнительный анализ хранилищ данных Коринский и Царев
  2. 2. О чём этот доклад?● Существует пропасть между разработчиками и DBA Отсутствуют популярные материалы по данной теме● Доклад является обзорным● Авторы - не DBA!
  3. 3. Зачем нужны транзакции?● Примеры: ● Оплата счёта ● Размещение поста в блоге ● Покупка билета
  4. 4. Транзакциии● Транзакция - <здесь по идее нужно определение>● Наивно: последовательность действий, со следующими свойствами: ● Atomic ● Consistence ● Isolated ● durability
  5. 5. Транзакции● Atomic: Последовательность действий применияется целиком, либо не применяется вообще● Consistence: Действия оставляют базу в непротиворечивом состоянии.● Isolated: транзакции работают независимо● Durability: после применения не может потеряться
  6. 6. Партицирование● Партицирование - деление данных на части между различными файлами, разделами диска или машинами в кластере.● Примеры: ● Социальные сети хранят тексты постов и картинки пользователей на различных серверах ● Информация о клиентах мобильного оператора распределена по регионам ● Сервер для обработки пользователя выбирается по первой букве имени
  7. 7. Аспекты партицирования● Виды: способы деления данных на части● Назначение: какие проблемы решает● Примеры: использование в реальных проектах● Enviroment: наличие и условия решений● Транзакции: как партицирование влияет на транзакции
  8. 8. Функциональная декомпозиция● Суть: Данные бьются на части в соотвествии с семантикой.● Возможные критерии: ● Тип данных (текст, картинки, видео) ● Изменчивость данных (статический контент или динамический?) ● Назначение данных (личные данные пользователей, публичные сообщения)
  9. 9. Горизонтальное партицирование● Суть: Множество однотипных данных разделяется на (равные) части по некоторому критерию● Критерии: ● Географическая рассредоточенность (в каждом регионе своя база) ● Надежность сервиса (обычные пользователи/платные аккаунты) ● Дата поступления данных (удобство поддержки, снижение нагрузки) ● Хеш-функция: отображение большего множества в меньшее (примеры далее)
  10. 10. Горизонтальное партицирование● Примеры хеш-функций: ● Числа: остаток от деления на десять (десять возможных значений) ● Логин пользователя: первая буква ника (мощность алвафита - множество возможных значений) ● "Идеальная": рабивает множество на равные части (таблица значений функции)
  11. 11. Вертикальное партицирование● Суть: Однотипные данные разделяются группируются в части по атрибутам● Критерии: ● Востребованность (часть колонок нужна редко) ● Масштабируемость (равномерно распределяем данные)
  12. 12. Column/Row-oriented system● Суть: данные организуются либо по строкам, либо по колонкам● Row-oriented: ● Все атрибуты каждой записи лежат рядом ● Записи лежат в файле последотельно● Column-oriented: ● Для каждого атрибута отдельный файл ● При чтении необходимо делать соединение
  13. 13. Enviroment● Операционные системы● Файловые системы● Сеть● Аппаратура● Поддержка на уровне хранилища
  14. 14. Транзакции и партицирование● Транзакции вносят свои проблемы: ● atomic: синхронность применения (консистентность) ● consistence: издержки на синхронизацию ● isolated: всё хорошо ● durability: что там с отказоустойчивостью?
  15. 15. Репликация● Репликация - способ синхронизации (приведение в соответствие) частей данных● Виды репликации: ● master-slave ● master-master
  16. 16. Master-Slave репликация● Все изменения применяются на master● Slave-узлы получает обновления с master● Slave-узлов может быть несколько
  17. 17. Назначение● Резервные копии - плохая идея● Распределение нагрузки● Таргетирование запросов
  18. 18. Таргетирование запросов● Различные хранилища на master/slave: ● master - OLTP, slave – OLAP ● master - SQL, slave - документо- ориентированная база ● Скорей всего репликацию придётся писать руками
  19. 19. Таргетирование запросов● Различная схема данных: ● master содержит просто таблицы для записи ● slave имеет дополнительные индексы ● slave имеют более узкие типы данных
  20. 20. Таргетирование запросов● Различная схема данных: ● master содержит просто таблицы для записи ● slave имеет дополнительные индексы ● slave имеют более узкие типы данных
  21. 21. Master-Master репликация● Суть: Изменения производятся одновременно на нескольких master● Защищаемся от выхода из строя master- узла● Снижение нагрузки на master-узел● Снижение нагрузки от slave-узлов
  22. 22. Транзакции и репликации● Транзакции вносят свои проблемы ● master-slave: транзакции на slave запаздывают ● master-master: как применять транзакции?
  23. 23. Consistency● Система всегда выдает корректные, непротиворечивые, ответы.● Данные не могут потеряться после завершения записи.● Не может быть так, что один и тот же запрос к данным (выборка данных, поиск, и т.д.) в зависимости от узла выдавал различные данные.
  24. 24. Availability● Система обязана всегда выдавать ответы - независимо от аппаратных сбоев отдельных узлов.
  25. 25. Partition tolerance● Система продолжает работать корректно при недоступности части узлов.
  26. 26. Проблема CAP теоремы Только два из трех
  27. 27. Про что говорим● Voldemort, Riak, cassandra, MySQL cluster● MongoDB, Hbase, memcache/memcached, berkleydb● PostgreSQL, MySQL, Oracle, TimesTen
  28. 28. +Consistency +Availability -Partition tolerance● PostgreSQL● MySQL● Oracle● TimesTen
  29. 29. PostgreSQL● Очень много разных индексов● PostGIS● Репликация внешними средствами● Сложна
  30. 30. MySQL● Привычная база● Есть репликация● Простота поддержки
  31. 31. Oracle● Умеет все● Дорого
  32. 32. TimesTen● Быстрая in memory база● Простота● Цена
  33. 33. PostgreSQL vs MySQL vs Oracle vs TimesTen● есть деньги oracle/timesten● хватает – postgres● иначе mysql
  34. 34. +Availability +Partition tolerance -Consistency● Voldemort● Riak● Cassandra● MySQL cluster
  35. 35. Voldemort● Написан на Java, REST● Key-value● LinkedIn● разные backend
  36. 36. Riak● Написан на Erlang, REST● Key-value● разные backend
  37. 37. Riak vs Voldemort● Одинаковы
  38. 38. Cassandra● Написана на Java, Thrift api● Column-oriented● Разные датацентры
  39. 39. MySQL cluster● Написана на С● Честный SQL● in memeory
  40. 40. Riak/Voldemort vs Cassandra vs MySQL cluster● совместимость MySQL● map reduce: Riak
  41. 41. +Consistency +Partiotion tolerance -Availability● MongoDB● Hbase● memcache/memcached● berkleydb
  42. 42. MongoDB● Написана на C++, BSON● Key-value● github, sourceforge, bit.ly, disqus
  43. 43. Hbase● Написана на Java, REST● column-oriented
  44. 44. memcache/memcached● Написаны на С, Простой протокол● Key-value● используется везде
  45. 45. berkleydb● Написана на С, C-API● Key-value● стоит денег
  46. 46. MongoDB vs Hbase bs memcached vs berkleydb● кеш memcached● hbase как замена bigtable● встраиваемая berkleydb
  47. 47. CAP Solution● Жертвуем Consistency● Разбиваем систему на части● Система в разные моменты времени находиться в разных позициях CAP теоремы
  48. 48. Счастья нет● У каждой задачи свои требования● У каждого хранилища свои сильные и слабые стороны● Хранилище под задачу, а не задачу под хранилище● Одного хранилища мало● Правильное решение - всегда компромис
  49. 49. Any question? Oleg Tsarev Kirill A. Korinskiy oleg.tsarev@percona.com kkorinsky@rooxteam.com http://percona.com/ http://www.roox.ru/

×