Postgres для аналитиков

PostgreSQL – пожалуй, лучшая СУБД с открытым кодом. Можно ли эту классическую OLTP базу использовать для аналитики? Как прикинуть – хватит ее или не хватит?
Давайте обсудим.

При использовании Postgres и любой СУБД со строчным хранением под OLAP запросы мы попадаем на все минусы такого подхода. Нам нужно для запроса прочитать одно поле из одной строки в 100 байт, для чего нам приходится вычитать блок данных в 32кбайт с диска, где хранятся вся целевая строка, соседние строки, а также разные версии этих строк. И еще СУБД оставляет пустое пространство, чтобы быстро проапдейтить строку. Общая эффективность легко может быть 100/32768=0.3%.

Можно ли использовать Postgres для аналитики? Конечно, сам так делал!

На входе в российский EdTech проект в команде было 3 аналитика и порядка 500ГБ данных. Можно было быстро получить от команды DevOps БД Postgres на ВМ в облаке. В нашем случае это была 16 vCPU машинка. Этого вполне хватало на ETL, на BI и ад-хоки.

А потом случился «аналитический взрыв». Как только команда строит приличный аналитический стек с нуля, мгновенно материализуется отложенный спрос от многих отделов компании. В нашем случае мы сделали простой BI, систему АБ-тестирования и закрыли несколько хороших гипотез с хорошим результатом на выручку. Сразу же пришли соседи и попросили дать им аналитиков и подключить их процессы к нашей системе.
(Практически карго-культ 😄)

И вот спустя полгода у нас уже 7 аналитиков и 1,5 ТБ данных. Также заметно выросло разнообразие данных, и команда прибавила в сложности задач, которые она может брать и успешно закрывать. БД пришлось переносить на выделенный сервер, так как переподписанные ядра и облачные диски уже не тянули нагрузку. С ростом команды до 15 человек и данных до 4 ТБ потребовался еще один переезд на мощный выделенный сервер.