Сравнительный анализ
хранилищ данных
Коринский и Царев
О чём этот доклад?
● Существует пропасть между разработчиками и DBA
Отсутствуют популярные материалы по данной теме
● Докл...
Зачем нужны транзакции?
● Примеры:
● Оплата счёта
● Размещение поста в блоге
● Покупка билета
Транзакциии
● Транзакция - <здесь по идее нужно определение>
● Наивно: последовательность действий, со
следующими свойства...
Транзакции
● Atomic: Последовательность действий
применияется целиком, либо не применяется
вообще
● Consistence: Действия ...
Партицирование
● Партицирование - деление данных на части между
различными файлами, разделами диска или машинами в
кластер...
Аспекты партицирования
● Виды: способы деления данных на части
● Назначение: какие проблемы решает
● Примеры: использовани...
Функциональная декомпозиция
● Суть: Данные бьются на части в соотвествии с
семантикой.
● Возможные критерии:
● Тип данных ...
Горизонтальное партицирование
● Суть: Множество однотипных данных разделяется на (равные) части
по некоторому критерию
● К...
Горизонтальное партицирование
● Примеры хеш-функций:
● Числа: остаток от деления на десять (десять
возможных значений)
● Л...
Вертикальное партицирование
● Суть: Однотипные данные разделяются
группируются в части по атрибутам
● Критерии:
● Востребо...
Column/Row-oriented system
● Суть: данные организуются либо по строкам, либо по
колонкам
● Row-oriented:
● Все атрибуты ка...
Enviroment
● Операционные системы
● Файловые системы
● Сеть
● Аппаратура
● Поддержка на уровне хранилища
Транзакции и партицирование
● Транзакции вносят свои проблемы:
● atomic: синхронность применения
(консистентность)
● consi...
Репликация
● Репликация - способ
синхронизации (приведение в
соответствие) частей данных
● Виды репликации:
● master-slave...
Master-Slave репликация
● Все изменения применяются на
master
● Slave-узлы получает обновления с
master
● Slave-узлов може...
Назначение
● Резервные копии - плохая идея
● Распределение нагрузки
● Таргетирование запросов
Таргетирование запросов
● Различные хранилища на
master/slave:
● master - OLTP, slave – OLAP
● master - SQL, slave - докум...
Таргетирование запросов
● Различная схема данных:
● master содержит просто таблицы для записи
● slave имеет дополнительные...
Таргетирование запросов
● Различная схема данных:
● master содержит просто таблицы для записи
● slave имеет дополнительные...
Master-Master репликация
● Суть: Изменения производятся
одновременно на нескольких master
● Защищаемся от выхода из строя ...
Транзакции и репликации
● Транзакции вносят свои проблемы
● master-slave: транзакции на slave
запаздывают
● master-master:...
Consistency
● Система всегда выдает корректные,
непротиворечивые, ответы.
● Данные не могут потеряться после
завершения за...
Availability
● Система обязана всегдавсегда выдавать
ответы - независимо от
аппаратных сбоев отдельных
узлов.
Partition tolerance
● Система продолжает работать
корректнокорректно при недоступности
части узлов.
Проблема CAP теоремы
Только два из трех
Про что говорим
● Voldemort, Riak, cassandra, MySQL
cluster
● MongoDB, Hbase,
memcache/memcached, berkleydb
● PostgreSQL, ...
+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
oleg.tsarev@percona.com
http://percona.com/
Kirill A. Korinskiy
kkorinsky@rooxteam.com
http://ww...
Upcoming SlideShare
Loading in …5
×

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

3,643 views

Published on

Published in: Technology, Self Improvement
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
3,643
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
36
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

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

  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 oleg.tsarev@percona.com http://percona.com/ Kirill A. Korinskiy kkorinsky@rooxteam.com http://www.roox.ru/

×