В чем минусы колоночных баз данных

Что проверяют

Понимаете ли вы, откуда берутся ограничения колоночного хранения, или повторяете список «медленная запись, нет транзакций». Следом обычно просят объяснить на ClickHouse или Parquet, почему нельзя вставлять по одной строке и чем заменить UPDATE.

Как отвечать

Начните с устройства: каждая колонка хранится отдельно, отсортированной и сжатой блоками. Отсюда сильные стороны (читаем только нужные колонки, отличное сжатие, векторная обработка), и из того же вырастают минусы:

• мелкие вставки дорогие: одна строка это запись во все файлы колонок. ClickHouse на каждый INSERT создаёт новый кусок данных, и частые мелкие вставки заканчиваются ошибкой Too many parts. Лечится пачками от тысяч строк или async_insert;
• обновления и удаления тяжёлые: ALTER TABLE ... UPDATE в ClickHouse это мутация, которая асинхронно переписывает затронутые куски. Облегчённые варианты есть, но под частые точечные правки движок не рассчитан;
• *точечные запросы и `SELECT `**: собрать одну широкую строку значит прочитать все колонки. Индекс разреженный, одна метка на гранулу (по умолчанию 8192 строки), так что поиск по ключу читает минимум гранулу;
• нет уникальности и слабые транзакции: первичный ключ ClickHouse уникальность не гарантирует, дубли схлопывает ReplacingMergeTree при слиянии, не сразу, для точного результата нужен FINAL. ACID-транзакций уровня PostgreSQL нет;
• JOIN: при хеш-соединении правая таблица строится в памяти, большие соединения упираются в RAM, поэтому данные часто денормализуют;
• сжатие зависит от сортировки: неудачный ORDER BY таблицы съедает главное преимущество.

Итог: колоночная база для OLAP, витрин и логов. Под OLTP берут PostgreSQL, а в аналитику данные переносят через CDC.

Где спотыкаются

Говорят, что колоночные базы плохо поддерживают SQL. Проблема не в синтаксисе, а в цене отдельных операций.

Проектируют таблицу как в PostgreSQL: вставка из приложения по одной строке, UPDATE статусов. Через неделю получают Too many parts и очередь мутаций.

Путают колоночное хранение с wide-column NoSQL вроде Cassandra. Там данные лежат по строкам внутри партиций, это другой класс систем.