Евгений Климов. Open-source СУБД глазами обычного программиста

В докладе будет попытка рассказать про хождение по граблям в различных СУБД, с которыми докладчик работал на протяжении своей карьеры. Попробуем ответить на вопросы:
* Какие особенности работы СУБД должен знать программист, чтобы лучше ориентироваться в ситуации „ой, у нас все сломалось“?
* Как вообще выбрать базу данных для нового проекта?
* Как лучше комбинировать разные СУБД?
* Стоит ли переносить бизнес-логику в СУБД?
* ORM vs Plain SQL vs NoSQL для простых смертных

Transcript

1. Open-source СУБД глазами обычного программиста Chelyabinsk Python Meetup #2 Eugene Klimov aka Slach https://t.me/bloodjazman
2. С какими системами я работал OLTP SQL – MySQL, PostgreSQL, MSSQL, Firebird OLAP – MS OLAP (мало) Колоночные – Vertica, Clickhouse NoSQL – Redis (много), MongoDb (мало), Tarantool (очень мало)
3. По каким граблям ходят разработчики всех СУБД ;) RUM теорема R (read) U (update) M (memory) overheads
4. Что должен знать «обычный» программист про используемые СУБД Алгоритмы •Как БД «пишет», «хранит» и «читает» данные? •Под какой тип нагрузки оптимизирована БД? •Как обрабатывается конкурентный доступ к данным?
5. Что должен знать «обычный» программист про используемые СУБД Эксплуатация • Насколько легко эту БД «мониторить» и «отлаживать»? • Насколько легко эту БД «обновлять»? • Насколько легко изменять «схему данных» в данной БД? • Насколько стабильны драйверы БД в вашем языке? • Как сделать горизонтальное масштабирование?
6. Как БД «пишет», «хранит» и «читает» данные? MySQL, PostgreSQL – нагрузка OLTP • Запись mem buffer -> transaction log (innodblog, WAL) -> table space (innodbdata, base) • Хранение - «страницы» в них «строки (tuples)» (целиком) отдельные страницы для «индексов» отдельные страницы для «жирных столбцов» (BLOB, JSON, any extended storage) • Чтение - постранично в память, cache в памяти «для горячих данных» MySQL - innodb buffer pool + O_DIRECT Postgres – shared buffers + кеш средствами OS сортирует и фильтрует в одном ядре (почти всегда ;)
7. Как БД «пишет», «хранит» и «читает» данные? Clickhouse – нагрузка OLAP • Запись «пишет пачками по XXX записей» сразу на диск входные данные в «большие» (1M на столбец) буфера в памяти и потом в каждый столбец отдельно, без transaction log • Хранение каждый столбец отдельно и сжато (zstd), нет дельта-кодирования для чисел (скоро будет), данные разбиты по «партициям» и «отсортированы по первичному ключу» (легче фильтровать), «новые данные» сливаются со старыми в фоновом режиме • Чтение - большими кусками последовательно, кеширует средствами OS, сортировка и группировка много ядер (потоки)
8. Как БД «пишет», «хранит» и «читает» данные? Redis – in-memory OLTP • Запись каждая команда изменяющая данные (кроме PUBSUB) сразу в память и в AOF файл (если включен) • Чтение - Глобальная «хеш» таблица «читает» только из памяти • Хранение «хранит» AOF файл, либо > Fork -> Copy on write -> RDB файл • Есть disk based аналоги - http://ssdb.io/, https://github.com/yinqiwen/ardb
9. Как БД «пишет», «хранит» и «читает» данные? MongoDb – OLTP schema less • Запись сначала в буфер в памяти -> паралельно WAL + Document Storage (сжатие) • Хранение «страницы» в них версии документов + «вторичные индексы» • Чтение - кеш в памяти (в памяти тоже сжатие) + файловый кеш OS
10. Как обрабатывается конкурентный доступ к данным? MySQL – thread per connect (+отдельный accept thread) + storage thread pool PostgreSQL – process per connect (+ auto vacuum) ClickHouse – thread pool per connect Redis – single thread to all connection Mongodb – thread per connect
11. Насколько легко эту БД «мониторить» и «отлаживать»? «Мониторить» легко в принципе всех, инструментов много Лично мой выбор это Prometheus Mongo + MySQL https://www.percona.com/software/database-tools/percona-monitoring-and- management PostgreSQL http://dalibo.github.io/powa/ Clickhouse https://github.com/f1yegor/clickhouse_exporter Redis https://github.com/oliver006/redis_exporter «Отлаживать» уже гораздо сложнее, но инструменты тоже есть УЧИТЕ EXPLAIN!!! MySQL Performance Schema PostgreSQL pg_stat_activity, pg_stat_statement Redis https://github.com/facebookarchive/redis-faina https://github.com/gamenet/redis-memory-analyzer Больше всего не хватает возможности через драйвер вставить место в коде где идет «вызов запроса»
12. Насколько легко эту БД «обновлять»? Обновляться «сложно», но можно ;) Самое сложное обновлять все БД без «downtime» и без «dump/restore» да еще и желательно на одной машине MySQL – логическая репликация + mysql_upgrade PostgreSQL – pglogical + pg_upgrade Clickhouse – apt-get upgrade Redis – apt-get upgrade MongoDb – после 3.x версии apt-get upgrade сначала для secondary, потом primary нод, без ReplicaSet
13. Насколько легко изменять «схему данных» в БД? • MySQL – pt-online-schema-change • PostgreSQL – CREATE INDEX CONCURENTLY + ALTER TABLE бесплатен для DEFAULT NULL • Redis – схему ключей надо менять руками • Clickhouse – ALTER TABLE бесплатен, но ограничен по функционалу • Mongodb – schema less из коробки, но схему документов все равно надо «дизайнить»
14. Насколько стабильны драйверы БД в Python? Чтобы оценить обычно я иду в github для соответсвующего драйвера и смотрю issues и history В python с драйверами все хорошо ;) С багами в них тоже ;) • MySQL – MySQLdb, aiomysql • PostreSQL – psycodb2, aiopg • Clickhouse – clickhouse-driver, aioch • Redis – драйверов вагон ;) • MongoDb – pymongo
15. Как сделать горизонтальное масштабирование? На самом деле ответ 42 или k8s ;) • MySQL – http://github.com/youtube/vitess/ • PostgreSQL – https://github.com/zalando/patroni • Clickhouse https://github.com/count0ru/k8s-clickhouse • Redis - https://github.com/sobotklp/kubernetes-redis-cluster • MongoDb – http://k8smongodb.net
16. Грабли на которые наступал я - MySQL • row based репликация + mysql_upgrade + xtrabackup • Single Thread MySQL Replication – LAG • «сломанная репликация» при ротации binlog • GROUP BY упирающийся в одно ядро • Включайте innodb_file_per_table • Осторожнее с innodb_flush_log_at_trx_commit • Осторожнее с sort_buffer • Поймите что такое data cardinality и не пытайтесь мучить индекс ;)
17. Грабли на которые наступал я - PostgreSQL • Ломается Streaming Replication – max_wal_size и replication slots • Autovacuum vs JSONB размером в 1Mb • Берегите pg_xlog также как base ;) • Wal-e + swift – восстановление в один поток • pgbouncer pause – «не савсем pause» • Patroni гибче чем repmgr • «Длинный SELECT» на standby - max_standby_streaming_delay один на всех • Учитесь правильно считать размер shared_buffers • GROUP BY в один поток
18. Грабли на которые я наступал - Redis • Не допускайте ситуации когда «все ломятся в один ключ» • Не пытайтесь хранить больше 2-5kb на ключ • На 32G и выше лучше 4 ноды по 8Gb чем 1 по 32G • Пользуйтесь KEYS только в самом крайнем случае • Смотрите «сложность алгоритмов» в документации • PUBSUB – не очень эффективен по памяти, не пытайтесь через него гонять данные (чат), только id и не пиками • AOF может ломаться и это надо отдельно мониторить • Twemproxy и Codis – стоит присмотреться
19. Грабли на которые я наступал в Clickhouse • Не работает с zetcd ;) https://github.com/yandex/ClickHouse/issues/777 • «Большие буфера» на вставку https://github.com/yandex/ClickHouse/issues/868 • Репликация «асинхронная», данные до некоторых реплик могут доехать не сразу • Float32, Float64 – это не numeric с фиксированной точностью https://github.com/yandex/ClickHouse/issues/1665
20. Как выбрать СУБД? Прежде всего поймите какой у вас тип нагрузки в приложении! Могут быть разные типы нагрузки в разных частях приложения. Значит нужны РАЗНЫЕ СУБД! Ответьте на вопросы: Чего больше? Чтения или записи? При чтении данные должны быть актуальны? При чтении данные группируются? Сортируются? Фильтруются? Сколько данных читается за один запрос? Сколько данных пишется за один запрос? Как долго нам хватит диска по размеру? и т.д. и т.п.
22. ORM vs Plain SQL • за «Object Mapping» приходится платить • IMHO Raw SQL просто надо сделать “prepared” и вынести в классы моделей
23. Логика в Базе данных • В SQL сложную логику писать «не очень» и надо научиться «обновлять stored процедуры» • Но вот есть tarantool и там через Lua очень хорошо реализован hot reload lua кода • Для «чтения» есть Materialized View и Temporary Tables, но это «дорого» и может быть по Space и Write
24. Вопросы из зала? Пара ссылок на последок https://github.com/onurakpolat/awesome-bigdata https://github.com/igorbarinov/awesome-data-engineering Со мной можно связаться bloodjazman@gmail.com https://t.me/bloodjazman