Your SlideShare is downloading. ×
0
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Олег Царев, Кирилл Коринский   Сравнительный анализ хранилищ данных
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,655

Published on

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

No Downloads
Views
Total Views
1,655
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
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 oleg.tsarev@percona.com http://percona.com/ Kirill A. Korinskiy kkorinsky@rooxteam.com http://www.roox.ru/

×