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