Что такое колоночные базы данных и почему они лучше для аналитики
Что проверяют
Понимаете ли вы, где заканчивается зона ответственности сервиса на Node.js и начинается зона хранилища. Бэкенд на ноде редко пишет аналитический движок, но почти всегда стоит перед ним: отдаёт дашборду агрегаты и должен не превратить это в перекачку строк через процесс.
Как отвечать
Механика: строковое хранилище держит поля одной записи рядом, поэтому дёшево читать и менять запись целиком; колоночное держит рядом значения одного поля всех записей, поэтому агрегат по двум полям из пятидесяти читает с диска только эти два.
Отсюда выигрыш: меньше ввода-вывода, сильное сжатие однородной колонки, счёт блоками значений одного типа вместо построчного обхода. Примеры: ClickHouse, Vertica, DuckDB, Redshift, BigQuery, форматы Parquet и ORC.
Для ноды важна вторая половина ответа. Агрегация выполняется запросом в хранилище, наружу уходит уже свёрнутый результат: процесс однопоточный, и попытка свести сто тысяч строк в JavaScript блокирует цикл событий для всех остальных запросов. Крупные выгрузки отдаются потоком, а не собираются в память. Ответы дашборда кешируются, потому что одна и та же витрина запрашивается всеми открытыми вкладками сразу.
Где спотыкаются
Называют колоночной любую нереляционную базу и приводят Cassandra. Это хранилище с широкими колонками и точечной нагрузкой, к аналитическому сканированию оно отношения не имеет; путаница в термине читается как поверхностное знание.
Тянут сырые строки в процесс и считают сумму и группировку на JavaScript. Память растёт, цикл событий встаёт, а хранилище, ради которого всё затевалось, не сделало ни одной операции, ради которой оно колоночное.
Дёргают витрину на каждое движение фильтра в интерфейсе, без кеша и без ограничения периода. Колоночный движок отвечает быстро на разумном диапазоне, но открытый запрос за всю историю он честно посчитает, и платить за это будет время ответа сервиса.