Масштабирование баз данных

5,419 views

Published on

Доклад Евгения Шишкина на конференции Application Developer Days-4. г.Минск 13 декабря 2013

Published in: Education

Масштабирование баз данных

  1. 1. МАСШТАБИРОВАНИЕ БАЗ ДАННЫХ common sense
  2. 2. Евгений Шишкин DBA, wargaming.net eshishki@gmail.com
  3. 3. — We define a DBMS as a complete software system used to define, create, manage, update and query a database. © Gartner БД общего назначения, OldSQL: MySQL, PostgreSQL Специализированные, NewSQL: VoltDB, Vertica, Clustrix NoSQL: HBase, Cassandra, CouchDB, Aerospark, MongoDB
  4. 4. SCALABILITY IS A FUNCTION Мы хотим добавить ресурсов и работать быстрее или обрабатывать больше. Amdahl's law Gustafson-Barsis' Law Neil J. Gunther's Universal Scalability Law
  5. 5. Amdahl's law У нас есть алгоритм, который однопоточно работает за время T1. Мы хотим добавить P процессоров и решить задачу быстрее. Какое увеличение производительности S мы можем получить? «В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента»
  6. 6. Amdahl's law Ускорение ограничено той частью работы, которая не параллелизуется. Например, если сериализованная часть алгоритма составляет только 0.1%, при 2048 процессорах ускорение будет только в 672 раза.
  7. 7. Gustafson-Barsis' Law …speedup should be measured by scaling the problem to the number of processors, not by fixing the problem size. — John Gustafson В реальности, добившись нужного времени ответа системы, нас всё устраивает. И мы уже добавляем мощности под растущий размер, а не для сокращения латенси.
  8. 8. Gustafson-Barsis' Law Если объем данных увеличивается вместе с увеличением числа процессоров, а сериализовання часть растет медленно или фиксирована, ускорение растет пропорционально росту ресурсов.
  9. 9. Я НИЧЕГО НЕ ПОНЯЛ Разница в том, хотите ли вы ускорения при той же нагрузке или того же времени ответа при увеличении нагрузки. В реальной жизни больше применим закон Gustafson. Но, если вам надо добиться более быстрой работы алгоритма при тех же данных, руководствуйтесь законом Амдала.
  10. 10. ТАК КАКАЯ ЖЕ БАЗА МАСШТАБИРУЕТСЯ ЛУЧШЕ? Масштабировать надо не базу, а сервис. Бессмысленно рассматривать базу данных в отрыве от профиля нагрузки и приложения. Масштабирование это специализация. Базы данных общего назначения в общем случае не масштабируются.
  11. 11. UNIVERSAL SCALABILITY LAW Cost of sharing resources Diminishing returns from contention Negative returns from incoherency
  12. 12. ТИПИЧНЫЕ ПРОФИЛИ НАГРУЗКИ oltp short-request processing web olap/dwh
  13. 13. OLTP буква T это транзакции - забыли nosql сразу же можно набить любимую базу данных до отказа памятью и ssd, но это будет печально и неэффективно как нам сделать 500k TPS на одном сервере? никак пошардили? добро пожаловать в дивный мир алгоритмов распределенного коммита Почему всё так плохо работает? Вот redis же делает 200к на одном ядре!
  14. 14. OLTP обычная база данных
  15. 15. OLTP Прорывной ресерч H-Store http://hstore.cs.brown.edu/ Готовый продукт VoltDB main memory database -> no buffer pool management каждому cpu свой кусочек памяти и однопоточное выполнение -> нет локов вся работа в хранимых процедурах и куча ресерча -> 2pc иногда не нужен и во время ожидания можно выполнять другие транзакции Подробнее тут http://hstore.cs.brown.edu/publications/
  16. 16. OLTP Все основные сложности с распределенными транзакциями. Рецепт - детерминизм. Зная наперед в какой последовательности будут выполняться транзакции, у нас нет ожидания. База данных всегда делает полезную работу. Подробности тут http://cs.yale.edu/homes/thomson/publications/calvinsigmod12.pdf
  17. 17. SHORT-REQUEST PK/INDEX LOOKUP Такая нагрузка масштабируется чем угодно. Не надо быть семи пядей во лбу, чтобы пошардить PK Речь об эффективности и удобстве. MySQL делает 200k rps, PostgreSQL 120k rps. Невероятно, но редкая nosql система покажет такие числа. Есть Mysql Cluster (NDB, не галера), есть Postgres-xc. NoSQL, которые AP, работают медленней CP.
  18. 18. WEB short-request + joins + tons of order by + orm 95%+ чтения почти нет транзакций небольшой объем горячих данных data skew (zipfian distribution) Нам хватает одного сервера, пока у него не кончается CPU. MySQL Cluster, Postgres-xc, Pgpool и прочие шардят только по одному атрибуту.
  19. 19. WEB Представьте себе табличку с постами create table thread_posts ( post_id bigint, thread_id bigint, user_id bigint, posted_on timestamp, contents text, primary key (thread_id, post_id), key (user_id, posted_on) ); И два популярных запроса: select * from thread_posts where thread_id = 314 order by post_id; select * from thread_posts where user_id = 546 order by posted_on desc limit 10; Хочется пошардить и по thread_id, post_id и по user_id, posted_on Выбирая только одно, далеко не уехать.
  20. 20. WEB Нам надо: отправлять запросы только туда, где лежат наши данные избегать распределенных запросов балансировать нагрузку Хороший способ: отвязать логическую схему от физической, чтобы шардить по разным атрибутам использовать consistent hashing для балансирования данных это сделано в Clustrix
  21. 21. WEB Советики чтобы избежать запросов на ноды, где данных нет lookup таблица bloom filter можно шардить по двум атрибутам руками, делая две таблицы можно денормализовать, помня про update, delete аномалии можно материализовывать данные при записи (push модель) для сверхпопулярных пользователей (лента)
  22. 22. WEB Если заморочиться Проблема эффективного распределения данных по нодам это локальность данных и оверхед репликации данных. Научный подход это положить данные вместе, не по хешу, а те, которые реально запрашиваются вместе. Schism: a Workload-Driven Approach to Database Replication and Partitioning The Little Engine(s) That Could: Scaling Online Social Networks
  23. 23. OLAP огромный объем данных огромные выборки куча сортировок и джойнов однотипные репорты хорошо шардится хорошо сжимается
  24. 24. OLAP Можно: пошардить руками взять postgres-xc, mysql cluster, любой автоматический шардинг и даже можно использовать materialized view (аля push) и можно даже что-то денормализовать
  25. 25. OLAP Нужно: 1. хранить данные в колонках сжатие векторизованный процессинг эффективный доступ к данным 2. оперировать над сжатыми данными в памяти 3. делать row reconstructure только когда это необходимо 4. делать join индексы или prejoin проекции 5. хранить данные уже отсортированными (merge join бесплатный)
  26. 26. OLAP Все эти "нужно" сделаны в Vertica. Часть сделана в Cloudera Impala. Greenplum не умеет column storage. Oracle не умеет column storage. NoSQL не умеет column storage. DB2 и MSSQL умеют, но не MPP. Половина NewSQL, которые про онлайн аналитику, это просто in memory базы. Очень часто даже без dictionary компрессии и RLE.
  27. 27. SQL VS NOSQL Представьте себе nosql базу данных, которая умеет secondary indexes умеет эффективно выполнять часть запросов у себя умеет транзакции дает гарантии, когда это необходимо Боже мой, да это же RDBMS!
  28. 28. ВЫВОДЫ Используйте нужную базу данных для своей нагрузки Не масштабируйте базу в отрыве от приложения Если вы знаете, как решить свою проблему NoSQL базой, значит вы знаете, как решить проблему и в RDBMS Не ленитесь думать и читать

×