Привет, Хабр!

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

Статья в основном для тех, кто только начинает свой путь работы с кликхаусом: мы посмотрим, как делать не надо, и как можно сделать лучше.

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

Всем привет, меня зовут Пётр. В первой части этого цикла статей мы взглянули на некоторые базовые концепции ClickHouse. В этой же статье продолжим изучать тонкости работы с этой колоночной базой данных и подробно рассмотрим такой аспект как репликация. А ещё разберёмся с сервисами координации Zookeeper и ClickHouse Keeper.

Тестировать монолитное приложение может быть непросто — особенно, когда сервис активно развивается. На проверку каждой фичи уходит всё больше ресурсов, а времени на оптимизацию мало. Как поступить?