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

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

  • 1,612 views
Published

 

  • 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
1,612
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
19
Comments
0
Likes
1

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