А зачем нам этот ClickHouse?
Разраб: Давайте затянем в проект ClickHouse для хранения миллионов миллиардов секстиллиона событий. Техлид: У нас есть уже СУБД для хранения событий в проекте. СУБД в проекте: * PostgreSQL *
Нет, мы тут не будем рассматривать кастомные сборки PostgreSQL для аналитики.
В любом проекте рано или поздно постгря начинает грустно вздыхать при определённом типе нагрузке. Потому что зачастую исторически просто так сложилось что пихаем INSERT’им в неё что попало (а жаль). И вариантов зачастую у нас не особо много - либо создаём побольше индексов (боль), либо сидим ждём пока очередной аналитический запрос выполнится (боль x2). Но как мы помним - PostgreSQL это впервую очередь OLTP-база.
И тут появляется ClickHouse (кстати напиши в комментариях какие ещё СУБД реально используете для таких задач в своих проектах).
Главное не пытаться работать с кликачом как с постгрёй. Помни об этом.
Основные грабли при работе с ClickHouse: 1. Точечные (одиночные) INSERT. Это плохо. Лучше об это забыть. Благо в последних версиях ClickHouse есть уже встроенный механизм для этого. Так что не придётся городить свой batch/queue/bulk-insert-microservice.
2. Забываем про UPDATE и DELETE. В ClickHouse данные по умолчанию сжимаются в parts (immutable). Поэтому учимся правильно использовать ReplacingMergeTree или CollapsingMergeTree и правильно проектируем схему.
3. PRIMARY KEY - это не то же самое что PRIMARY KEY в PostgreSQL. В ClickHouse первичный ключ (ах, ну да, ещё ORDER BY) определяет физический порядок хранения данных на диске и разбивку на гранулы. Если выбрать ключ неудачно — база будет перебирать гигабайты дискового пространства вместо чтения за миллисекунды (плавали, знаем).
Итог: ClickHouse прекрасен если его правильно “готовить”. А что вы юзаете в своих проектах? Может какие-то ещё специфичные (и нестандартные!) базы данных? Позже обязательно напишу про Cassandra и её альтернативу - ScyllaDB.
