> ## Content Index
> Fetch the complete content index at: https://www.rozhkov.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# ClickHouse. Нюансы
- URL: https://www.rozhkov.me/clickhouse-nuances/
- Published: 2021-06-16T06:00:00.000Z
- Updated: 2021-06-16T09:14:42.000Z
- Author: Vova Rozhkov
- Tags: інструменти

Вообще это очень трендовая база. На хайлоад++ и других конференциях вы можете посмотреть множество докладов посвященных ClickHouse. На хабре куча статей. [Материалов очень много](https://github.com/ClickHouse/clickhouse-presentations). Вся эта движуха прошла мимо меня потому что я предпочитаю использовать проверенные инструменты до последнего. Ну и хайлоад++ не посещаю.

После PoC я прикинул, что нужно сделать для синхронизации основного хранилища в ClickHouse, и приступил к доработке продакшн-решения.

Неожиданность подстерегала меня в самом начале. Сущности которые хранятся у меня в основной таблице могут меняться. Соответственно, мне нужно было обновлять их и в ClickHouse. Первая задача—растыкать везде, где меняется эта сущность, вызов синхронизации. Вторая—собственно обновлять данные. Оказалось, что ClickHouse очень хорошо умеет записывать данные. Но не очень хорошо умеет [изменять](https://clickhouse.tech/docs/en/sql-reference/statements/alter/update/) и [удалять](https://clickhouse.tech/docs/en/sql-reference/statements/alter/delete/) 😅. 

Пришлось засесть за документацию и разобраться как это работает. Оказывается для каждой таблицы можно выбирать свой "движок", они есть разные и для каждой задачи можно подобрать самый подходящий вариант. Конкретно для дедупликации данных есть [ReplacingMergeTree](https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replacingmergetree/), это структура которая в фоне удаляет записи с одинаковым первичным ключом. То есть вы просто два раза инсертите одну и ту же запись и когда таблица будет оптимизироваться, то она уберет старые записи. Проблема в том, что непонятно когда это произойдет, а это значит, что в отчетах могут выводиться неверные данные. Для того чтобы попросить ClickHouse брать во внимание только нужные строки, используется ключевое слово `final`. Естественно это замедляет выполнение запросов, потому что базе нужно на ходу выбросить из результата все лишнее. Пока что все работает достаточно быстро, посмотрим как оно будет дальше. Данных у меня не терабайты, поэтому думаю что все будет ок.

Вторая штука была уже приятной неожиданностью—ClickHouse [умеет на ходу проксировать запросы](https://clickhouse.tech/docs/en/engines/table-engines/integrations/) к куче источников данных, в том числе `mysql`. То есть ему можно сказать: сделай мне таблицу из вот этого конекшена к `mysql`. Таким образом, для части таблиц с небольшим объемом (десятки тысяч строк) мне не нужно было писать код синхронизации а достаточно просто запроксировать. Не знаю как это работает внутри, для т.н. "словарей" там точно есть кеш, а вот такие запросы будут ходить скорее всего каждый раз напрямую. Посмотрим как оно будет.

Третий прикол это типа OOM на запросах. Если ваш запрос по какой-то причине возвращает слишком много данных, то сервер может поднять лапки и сказать "сорян на этот запрос памяти нет". Такая ошибка вываливалась в стандартном просмотре таблицы Metabase потому что он делает `select * from table`, а если данных много и сервер слишком мал, то запрос просто не выполнится. Нужно или делать группировки или ограничивать колонки.

Несмотря на кажущуюся простоту решения, я превысил изначальный временной бюджет в два с хвостиком раза. Будет мне наука.

Решение работает в продакшене пару недель, пока все ок. Будем смотреть. ClickHouse мне очень понравился, я уже вижу еще несколько мест куда его можно применить. Очень легковесная и быстрая штука. Советую попробовать всем.