Вообще это очень трендовая база. На хайлоад++ и других конференциях вы можете посмотреть множество докладов посвященных ClickHouse. На хабре куча статей. Материалов очень много. Вся эта движуха прошла мимо меня потому что я предпочитаю использовать проверенные инструменты до последнего. Ну и хайлоад++ не посещаю.
После PoC я прикинул, что нужно сделать для синхронизации основного хранилища в ClickHouse, и приступил к доработке продакшн-решения.
Неожиданность подстерегала меня в самом начале. Сущности которые хранятся у меня в основной таблице могут меняться. Соответственно, мне нужно было обновлять их и в ClickHouse. Первая задача—растыкать везде, где меняется эта сущность, вызов синхронизации. Вторая—собственно обновлять данные. Оказалось, что ClickHouse очень хорошо умеет записывать данные. Но не очень хорошо умеет изменять и удалять 😅.
Пришлось засесть за документацию и разобраться как это работает. Оказывается для каждой таблицы можно выбирать свой "движок", они есть разные и для каждой задачи можно подобрать самый подходящий вариант. Конкретно для дедупликации данных есть ReplacingMergeTree, это структура которая в фоне удаляет записи с одинаковым первичным ключом. То есть вы просто два раза инсертите одну и ту же запись и когда таблица будет оптимизироваться, то она уберет старые записи. Проблема в том, что непонятно когда это произойдет, а это значит, что в отчетах могут выводиться неверные данные. Для того чтобы попросить ClickHouse брать во внимание только нужные строки, используется ключевое слово final
. Естественно это замедляет выполнение запросов, потому что базе нужно на ходу выбросить из результата все лишнее. Пока что все работает достаточно быстро, посмотрим как оно будет дальше. Данных у меня не терабайты, поэтому думаю что все будет ок.
Вторая штука была уже приятной неожиданностью—ClickHouse умеет на ходу проксировать запросы к куче источников данных, в том числе mysql
. То есть ему можно сказать: сделай мне таблицу из вот этого конекшена к mysql
. Таким образом, для части таблиц с небольшим объемом (десятки тысяч строк) мне не нужно было писать код синхронизации а достаточно просто запроксировать. Не знаю как это работает внутри, для т.н. "словарей" там точно есть кеш, а вот такие запросы будут ходить скорее всего каждый раз напрямую. Посмотрим как оно будет.
Третий прикол это типа OOM на запросах. Если ваш запрос по какой-то причине возвращает слишком много данных, то сервер может поднять лапки и сказать "сорян на этот запрос памяти нет". Такая ошибка вываливалась в стандартном просмотре таблицы Metabase потому что он делает select * from table
, а если данных много и сервер слишком мал, то запрос просто не выполнится. Нужно или делать группировки или ограничивать колонки.
Несмотря на кажущуюся простоту решения, я превысил изначальный временной бюджет в два с хвостиком раза. Будет мне наука.
Решение работает в продакшене пару недель, пока все ок. Будем смотреть. ClickHouse мне очень понравился, я уже вижу еще несколько мест куда его можно применить. Очень легковесная и быстрая штука. Советую попробовать всем.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred