Приветствую, habr. Если кто-то эксплуатирует систему graphite-web и столкнулся с проблемой производительности хранилища whisper (IO, потребляемое дисковое пространство), то шанс того, что был брошен взгляд на ClickHouse в качестве замены, должен стремиться к единице. Данное утверждение подразумевает то, что в качестве принимающего метрики демона уже используется сторонняя реализация, например carbonwriter или go-carbon. ClickHouse хорошо решает описанные проблемы. К примеру, после переливки 2TiB данных из whisper, они уместились в 300GiB. Подробно на сравнении я останавливаться не буду, статей на эту тему хватает. К тому же, до недавнего времени с нашим ClickHouse хранилищем было не всё идеально. На первый взгляд, всё должно работать хорошо. Следуя документации, создаём конфиг для схемы хранения метрик (далее retention), затем создаём таблицу согласно рекомендации выбранного бекенда для graphite-web: carbon-clickhouse+graphite-clickhouse или graphouse, в зависимости от того, какой стек используется. И… включается бомба замедленного действия. Для того, чтобы понять, какая, надо знать, как работают вставки и дальнейший жизненный путь данных в таблицах движков семейства *MergeTree ClickHouse (диаграммы взяты из презентации Алексея Зателепина): Итак, поступают первые метрики. И они занимают некое пространство. Последующие события могут несколько варьироваться в зависимости от многих факторов: И заканчивается всегда всё одинаково. Место, занимаемое метриками в ClickHouse только растёт, если: Второй способ кажется наиболее простым в реализации и, значит, он неправильный и был опробован в первую очередь.
Я написал достаточно простой скрипт на python, который отправлял фиктивные метрики для каждого дня за прошлые 4 года и запускался каждый час кроном.
Так как вся работа ClickHouse DBMS построена на том, что эта система рано или поздно сделает всю фоновую работу, но неизвестно когда, то дождаться момента, когда старые огромные куски соизволят начать мерж с новыми маленькими, мне не удалось. Стало ясно, что надо искать способ автоматизировать принудительные оптимизации. Взглянем на структуру таблицы system.parts. Это исчерпывающая информация о каждом куске всех таблиц на сервере ClickHouse. Содержит, в том числе, следующие столбцы: Также есть таблица system.graphite_retentions, со следующими интересными полями: Итак: возвращает каждую из партиций таблиц *GraphiteMergeTree, мерж которых должен привести к освобождению дискового пространства. Осталось только дело за малым: пройтись по ним всем с запросом OPTIMIZE ... FINAL. В финальной реализации также учтён тот момент, что партиции с активной записью трогать нет необходимости. Именно это и делает проект graphite-ch-optimizer. Бывшие коллеги из Яндекс.Маркет опробовали его в проде, результат работы можно видеть ниже.   Если запустить программу на сервере с ClickHouse, то она просто начнёт работать в режиме демона. Раз в час будет выполняться запрос, проверяя, не появились ли новые партиции старше трёх суток, которые можно оптимизировать. В ближайших планах — предоставить, по крайней мере, deb пакеты, а по возможности — ещё и rpm. UPD: пакеты доступны в релизах на github, а рабочие образы можно найти на docker-hub в репозитории innogames/graphite-ch-optimizer. За прошедшие 9 с лишним месяцев я внутри своей компании InnoGames провёл много времени, варясь на стыке ClickHouse и graphite-web. Это был хороший опыт, результатом которого стал возможен скорый переход с whisper на ClickHouse в качестве хранилища метрик. Надеюсь, что эта статья — что-то вроде начала цикла о том, какие улучшения были внесены нами в различные части этого стека, и что будет сделано в будущем. На разработку запроса было потрачено несколько литров пива и админо-дней совместно с v0devil, за что я хочу выразить ему свою благодарность. А также за рецензирование этой статьи. Страничка проекта на github Системный администратор Linux, писатель на go и py