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

1,978 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,978
On SlideShare
0
From Embeds
0
Number of Embeds
315
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Сравнительный анализ хранилищ данных Коринский и Царев... Плоды многолетних размышлений v. 1.0 @ #ADD 2010
  2. 2. Введение
  3. 3. Содержание ● Постановка проблемы ● Что такое распределенные хранилища ● Обзор доступных хранилищ
  4. 4. Друзья в социальной сети Задача: получить список друзей. ● Facebook - 500M пользователей - 5M rps ● ВКонтакте - 100M пользователей - 1M rps ● Мой Мир - 50M пользователей - 0.5M rps ● Toy net - 10 пользователей - <1 rps
  5. 5. Матрица смежности таблица: – оси таблицы – пользователи; – ячейки таблицы – связь. ● ВКонтактe/Facebook: один бит ● Мой Мир: шесть байт ● Toy net: один бит
  6. 6. Список смежных вершин каждый элемент: ● пара (UID, UID), UID – 4 байта): – Facebook – Вконтакте – Toy net ● кортеж (UID, UID, Info – 6 байт): – Мой Мир
  7. 7. Генерация списка друзей каждый элемент: ● Facebook/ВКонтакте - 8 байт. ● Мой Мир - 14 байт. ● Toy net - 1 байт?
  8. 8. Генерация списка друзей Матрица смежности: ● Сканируем строку таблицы ● Проверяем каждый столбец строки ● Каждая ячейка сообщает отношения
  9. 9. Генерация списка друзей (просто) Список смежных вершин: ● Каждый элемент - (Кто?, С кем?, Что?) ● Фильтруем список по "Кто?" ● Усеченный список содержит всех друзей
  10. 10. Генерация списка друзей (сложно) Список смежных вершин: ● Каждый элемент - (Кто?, С кем?, Что?, Следующий) ● Находим первый элемент с нужным Кто? ● Вытягиваем весь список
  11. 11. Масштабы: memory Матрица смежности: ● Facebook: 28421 Петабайт ● ВКонтакте: 1136 Петабайт ● Мой Мир: 13642 Петабайт ● Toy net: 16 байт
  12. 12. Масштабы: memory Список смежных вершин (сложно): ● Facebook: 69 Гигабайт ● ВКонтакте: 14 Гигабайт ● Мой мир: 97 гигабайт ● Toy net: 200 байт
  13. 13. Масштабы: latency DDR3 ECC2 (DDR3-1066E): ● 8 гигабит в секунду максимум ● 8 гигабайт - $1500-2000 ● Страница памяти - 4 килобайта ● 2 миллиона страниц в секунду
  14. 14. Масштабы: latency Матрица смежности: ● Facebook: 16 rps ● ВКонтакте: 80 rps ● Мой мир: 40 rps ● Toy net: 2 000 000 rps
  15. 15. Масштабы: latency Список смежных вершин (сложно): ● 150 друзей у каждого в среднем ● 150 страниц на генерацию списка ● Итог: 14 000 rps
  16. 16. Масштабы: memory/latency Список смежных вершин (просто) ● Нет смысла рассматривать, full scan
  17. 17. Оптимизация матрици смежности ● Матрица смежности сильно разряжена ● Можно производить адаптивную упаковку ● Реализация станет сложней
  18. 18. Оптимизация списка смежных вершин ● Список смежных вершин можно группировать по "Кто?" ● Возрастёт потребление памяти ● Реализация станет сложней
  19. 19. Видео: постановка задачи ● Существуют различные кодеки ● Разные характеристики: – Размер ролика – Потребляемая при конвертации память – Количество вычислений при конвертации – Качество записи
  20. 20. Видео: решение ● Несжатое видео ● H.264
  21. 21. Видео: "Экстремумы" ● CPU-limited: H.264 требует много вычислений. ● Memory-limited: Несжатое видео требует много памяти для хранения ● Latency-limited: Несжатое видео требует много памяти для хранения ● Latency-limited: H.264 требуети время на конвертацию
  22. 22. Видео: выводы ● В задаче с видео тоже есть "экстремумы" ● Каждый их решений имеет свои минусы ● Три точки экстремума: CPU, Memory, Latency.
  23. 23. Основные оси ● CPU ● Memory ● Latency ● Сложность
  24. 24. Производные оси ● Бюджет проекта ● Сроки ● Опыт разработчиков ● Аппаратура ● Имеющиеся инструменты
  25. 25. Выводы ● Основная задача HighLoad - поиск локального оптимума. ● Иногда задача не разрешима в имеющихся условиях ● Наша цель - познакомить слушателей с ключевыми факторами
  26. 26. Виды партицирования ● Функциональная декомпозиция ● Горизонтальное партицирование ● Вертикальное партицирование
  27. 27. Manual partitioning ● Разделяем данные на уровне приложения ● Требует дополнительной работы ● Теряется транзакционность
  28. 28. Automatic partitioning ● Тяжело поддержать на уровне хранилища ● Приходится указывать критерии партицирования ● Универсальные критерии не работают
  29. 29. Иные аспекты партицирования ● На каждом узле выбирается: – Аппаратура – Хранилище – Операционная система ● В случае HDD хранилища: файловая система
  30. 30. Репликация ● Master-Master: все узлы равноправны ● Master-Slave: главные и ведомые узлы
  31. 31. offline транзакции Для клиента транзакция завершается после исполнения на текущем узлетекущем узле.
  32. 32. online транзакции Для клиента транзакция завершается после исполнения на всех узлахвсех узлах.
  33. 33. Consistency ● Система всегда выдает корректные, непротиворечивые, ответы. ● Не может быть так, что после записи данные потерялись. ● Не может быть так, что один и тот же запрос к данным (выборка данных, поиск, и т.д.) в зависимости от узла выдавал различные данные.
  34. 34. Availability ● Система обязана выдавать всегда выдавать ответы - независимо от аппаратных сбоев отдельных узлов.
  35. 35. Partition tolerance ● Система продолжает работать корректно при недоступности части узлов.
  36. 36. Пример: +A +C -P ● Обычная СУБД
  37. 37. Пример: + С + P - A ● Система с online транзакции
  38. 38. Пример: +A +P -C ● Система с offline транзакциями
  39. 39. Проблема CAP теоремы ● Только два из трех
  40. 40. CAP Solution ● Жертвуем Consistency ● Разбиваем систему на части ● CAP теорема работает в каждый момент времени
  41. 41. Interface: access ● Library: клиентская библиотека ● ODBC: стандартный интерфейс доступа ● Embedded: встраиваемая база ● Telnet: простой сетевой протокол
  42. 42. Interface: method ● API: интерфейс доступа ● DSL: domain-speicific-language ● SQL (суть DSL): structured query language
  43. 43. Interface: abstraction level ● Search: поиск и выборка значений по ключу ● Query (Search included): поиск, выборка и обработка значений
  44. 44. Interface: реализации ● PostgreSQL: lib/ODBC, SQL, Query ● MySQL: lib/ODBC, SQL, Query ● MySQL NDB-cluster: lib, SQL, Query ● Oracle: lib/ODBC, SQL, Query ● Oracle Timesten: ODBC, SQL, Query ● Riak: lib, API/DSL, Query ● MongoDB: lib, API/DSL, Query
  45. 45. Interface: реализации ● Hadoop: lib, API, Query ● Mnesia: embedded, DSL, Query ● memcached: telnet, DSL, Search ● memcachedb: telnet, DSL, Search ● berkleydb: embedded, API, Search ● voldemort: lib, API/DSL, Query ● cassandra: lib, API/DSL, Search
  46. 46. Storage ● RAM: все данные находятся в оперативной памяти ● Filesystem: система использует для хранения файлы ● Raw partition: система использует раздел диска
  47. 47. Storage: реализации ● PostgreSQL: FS, RAM ● MySQL: FS, RAM ● MySQL NDB-cluster: RAM ● Oracle: Raw, FS, RAM ● Oracle Timesten: RAM ● Riak: FS, RAM ● MongoDB: FS
  48. 48. Storage: реализации ● Hadoop: FS ● Mnesia: FS, RAM ● memcached: RAM ● memcachedb: FS ● berkleydb: FS, RAM ● Voldemort: FS, RAM ● Cassandra: FS
  49. 49. Persistent ● Полная (full): данные гарантированно не теряются ● Частичная (partial): может потеряться последние несколько транзакций ● Отсутствует (loose): данные не сохраняться вообще
  50. 50. Persistent: реализации ● PostgreSQL: full ● MySQL: full, partial ● MySQL NDB-cluster: partial, loose ● Oracle: full, partial, loose ● Oracle Timesten: partial, loose ● Riak: full, loose ● MongoDB: full
  51. 51. Persistent: реализации ● Hadoop: full ● Mnesia: full, loose ● memcached: loose ● memcachedb: full ● berkleydb: full, partial ● Voldemort: full, loose ● Cassandra: full
  52. 52. Динамическая типизация ● Гетерогенный доступ ● Единообразный доступ
  53. 53. Статическая типизация ● Целостность данных ● Высокая производительность ● Экономия памяти
  54. 54. Реализации ● PostgreSQL: Статическая ● MySQL: Статическая ● MySQL NDB-cluster: Статическая ● Oracle: Статическая ● Oracle Timesten: Статическая ● Riak: Динамическая
  55. 55. Реализации ● MongoDB: Динамическая ● Hadoop: Динамическая ● Mnesia: Динамическая ● memcached: Динамическая ● memcachedb: Динамическая ● berkleydb: Динамическая ● Voldemort: Динамическая ● Cassandra: Динамическая
  56. 56. Cost/license ● PostgreSQL: BSD-like ● MySQL: GPL 2.0/just call ● MySQL NDB-cluster: GPL 2.0/just call ● Oracle: $47,500 ● Oracle Timesten: $41,500 ● Riak: Apache 2.0 ● MongoDB: AGPL 3.0
  57. 57. Cost/license ● Hadoop: Apache 2.0 ● Mnesia: Erlang Public License ● memcached: BSD ● memcachedb: BSD ● berkleydb: Sleepycat License/$9,800 ● Voldemort: Apache 2.0 ● Cassandra: Apache 2.0
  58. 58. Счастья нет ● У каждой задачи свои требования ● У каждого хранилища свои сильные и слабые стороны ● Хранилище под задачу, а не задачу под хранилище ● Одного хранилища мало ● Правильное решение всегда компромис
  59. 59. Any question? Oleg Tsarev oleg.tsarev@percona.com http://percona.com/ Kirill A. Korinskiy kkorinsky@rooxteam.com http://www.roox.ru/

×