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

1. МАСШТАБИРОВАНИЕ
БАЗ ДАННЫХ
common sense

2. Евгений Шишкин
DBA, wargaming.net
eshishki@gmail.com

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. SCALABILITY IS A FUNCTION
Мы хотим добавить ресурсов и работать быстрее
или обрабатывать больше.
Amdahl's law
Gustafson-Barsis' Law
Neil J. Gunther's Universal Scalability Law

5. Amdahl's law
У нас есть алгоритм, который однопоточно
работает за время T1.
Мы хотим добавить P процессоров и решить задачу
быстрее.
Какое увеличение производительности S мы можем
получить?
«В случае, когда задача разделяется на несколько
частей, суммарное время её выполнения на
параллельной системе не может быть меньше
времени выполнения самого длинного фрагмента»

6. Amdahl's law
Ускорение ограничено той частью работы, которая
не параллелизуется.
Например, если сериализованная часть алгоритма
составляет только 0.1%, при 2048 процессорах
ускорение будет только в 672 раза.

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. Gustafson-Barsis' Law
Если объем данных увеличивается вместе с
увеличением числа процессоров, а сериализовання
часть растет медленно или фиксирована,
ускорение растет пропорционально росту
ресурсов.

9. Я НИЧЕГО НЕ ПОНЯЛ
Разница в том, хотите ли вы ускорения при той же
нагрузке или того же времени ответа при
увеличении нагрузки.
В реальной жизни больше применим закон
Gustafson.
Но, если вам надо добиться более быстрой работы
алгоритма при тех же данных, руководствуйтесь
законом Амдала.

10. ТАК КАКАЯ ЖЕ БАЗА
МАСШТАБИРУЕТСЯ
ЛУЧШЕ?
Масштабировать надо не базу, а сервис.
Бессмысленно рассматривать базу данных в
отрыве от профиля нагрузки и приложения.
Масштабирование это специализация.
Базы данных общего назначения в общем случае не
масштабируются.

11. UNIVERSAL SCALABILITY LAW
Cost of sharing resources
Diminishing returns from contention
Negative returns from incoherency

12. ТИПИЧНЫЕ ПРОФИЛИ
НАГРУЗКИ
oltp
short-request processing
web
olap/dwh

13. OLTP
буква T это транзакции - забыли nosql сразу же
можно набить любимую базу данных до отказа
памятью и ssd, но это будет печально и
неэффективно
как нам сделать 500k TPS на одном сервере? никак
пошардили? добро пожаловать в дивный мир
алгоритмов распределенного коммита
Почему всё так плохо работает? Вот redis же делает
200к на одном ядре!

14. OLTP
обычная база данных

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. OLTP
Все основные сложности с распределенными
транзакциями.
Рецепт - детерминизм.
Зная наперед в какой последовательности будут
выполняться транзакции, у нас нет ожидания. База
данных всегда делает полезную работу.
Подробности тут
http://cs.yale.edu/homes/thomson/publications/calvinsigmod12.pdf

17. SHORT-REQUEST
PK/INDEX LOOKUP
Такая нагрузка масштабируется чем угодно.
Не надо быть семи пядей во лбу, чтобы пошардить
PK
Речь об эффективности и удобстве.
MySQL делает 200k rps, PostgreSQL 120k rps.
Невероятно, но редкая nosql система покажет
такие числа.
Есть Mysql Cluster (NDB, не галера), есть Postgres-xc.
NoSQL, которые AP, работают медленней CP.

18. WEB
short-request + joins + tons of order by + orm
95%+ чтения
почти нет транзакций
небольшой объем горячих данных
data skew (zipfian distribution)
Нам хватает одного сервера, пока у него не
кончается CPU.
MySQL Cluster, Postgres-xc, Pgpool и прочие шардят
только по одному атрибуту.

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. WEB
Нам надо:
отправлять запросы только туда, где лежат наши
данные
избегать распределенных запросов
балансировать нагрузку
Хороший способ:
отвязать логическую схему от физической, чтобы
шардить по разным атрибутам
использовать consistent hashing для
балансирования данных
это сделано в Clustrix

21. WEB
Советики
чтобы избежать запросов на ноды, где данных нет
lookup таблица
bloom filter
можно шардить по двум атрибутам руками,
делая две таблицы
можно денормализовать, помня про update, delete
аномалии
можно материализовывать данные при записи
(push модель) для сверхпопулярных
пользователей (лента)

22. WEB
Если заморочиться
Проблема эффективного распределения данных по
нодам это локальность данных и оверхед
репликации данных.
Научный подход это положить данные вместе, не
по хешу, а те, которые реально запрашиваются
вместе.
Schism: a Workload-Driven Approach to Database
Replication and Partitioning
The Little Engine(s) That Could: Scaling Online Social
Networks

23. OLAP
огромный объем данных
огромные выборки
куча сортировок и джойнов
однотипные репорты
хорошо шардится
хорошо сжимается

24. OLAP
Можно:
пошардить руками
взять postgres-xc, mysql cluster, любой
автоматический шардинг
и даже можно использовать materialized view (аля
push)
и можно даже что-то денормализовать

25. OLAP
Нужно:
1. хранить данные в колонках
сжатие
векторизованный процессинг
эффективный доступ к данным
2. оперировать над сжатыми данными в памяти
3. делать row reconstructure только когда это
необходимо
4. делать join индексы или prejoin проекции
5. хранить данные уже отсортированными (merge
join бесплатный)

26. OLAP
Все эти "нужно" сделаны в Vertica.
Часть сделана в Cloudera Impala.
Greenplum не умеет column storage.
Oracle не умеет column storage.
NoSQL не умеет column storage.
DB2 и MSSQL умеют, но не MPP.
Половина NewSQL, которые про онлайн аналитику,
это просто in memory базы. Очень часто даже без
dictionary компрессии и RLE.

27. SQL VS NOSQL
Представьте себе nosql базу данных, которая
умеет secondary indexes
умеет эффективно выполнять часть запросов у
себя
умеет транзакции
дает гарантии, когда это необходимо
Боже мой, да это же RDBMS!

28. ВЫВОДЫ
Используйте нужную базу данных для своей
нагрузки
Не масштабируйте базу в отрыве от приложения
Если вы знаете, как решить свою проблему NoSQL
базой, значит вы знаете, как решить проблему и в
RDBMS
Не ленитесь думать и читать