⚡️ Почему колоночная БД быстрее строковой

Когда говорят, что ClickHouse быстрый, причина не только в «хорошей оптимизации».

Одна из главных причин — колоночное хранение данных.

Представим простую таблицу:

id | date | product | city | amount

В строковой БД данные хранятся по строкам. То есть рядом лежит сразу вся запись целиком:

• id • date • product • city • amount

Это удобно для транзакционных систем, где нужно быстро:

• вставить запись • обновить запись • получить одну строку целиком

Но для аналитики такой подход часто невыгоден 🤔

Почему?

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

Например:

• посчитать sum(amount) • сгруппировать по city • посмотреть только date и amount

То есть реально нужны 2–3 столбца, а строковая БД может читать намного больше лишнего.

В колоночной БД всё устроено иначе.

Каждый столбец хранится отдельно:

• все id вместе • все date вместе • все product вместе • все city вместе • все amount вместе

Что это даёт ✅

• читаются только нужные столбцы • с диска поднимается меньше данных • данные лучше сжимаются • агрегаты считаются быстрее

Например, если тебе нужно посчитать только сумму продаж, колоночной БД достаточно читать столбец amount.

Именно поэтому колоночный формат особенно хорош для:

• BI-отчётов • аналитики продаж • логов • дашбордов • больших исторических данных

🧠 Архитектурная мысль

Строковое хранение хорошо отвечает на вопрос:

«Покажи конкретную запись»

Колоночное хранение хорошо отвечает на вопрос:

«Посчитай метрику по 500 млн строк»

Поэтому:

• OLTP чаще строковый • OLAP чаще колоночный

Вывод

Колоночная БД быстрее строковой не всегда. Она быстрее именно там, где нужно:

• читать мало столбцов • сканировать много строк • быстро считать агрегаты

И это одна из главных причин, почему ClickHouse так хорош в аналитике.