• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

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

  • 2,700 views
Published

 

Published in Technology , Self Improvement
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,700
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
26
Comments
0
Likes
3

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