Хочу посоветоваться по поводу одного потенциального юзкейса для ClickHouse. Есть система,

Question

Хочу посоветоваться по поводу одного потенциального юзкейса для ClickHouse. Есть система,

которая делает единицы миллинов исходящих API вызовов во внешние системы статистики и сохраняет результаты в Postgres. В терминах предметной области это сколько денег потратили клиенты на свои рекламные кампании на разных платформах (Facebook, Google, Twitter, etc) с брейкдауном по дате, кампании, стране + еще несколько измерений.

Эти данные имеют свойство меняться в прошлом, поэтому каждый день мы забираем новые данные за вчера + обновленные старые за 7 дней до этого. То есть это не append only сценарий.

В Postgres мы делаем DELETE FROM ... WHERE ... (условие соответствующее кусочку данных, которые мы хотим обновить). Таких кусочков столько же сколько исходящих запросов, т.е. миллионы.
Потом вставлеяем новые через COPY FROM ...
Под транзакцией.
Это все крутится на 4 шардах с NVMe + подневное секционирование.

Это была история про запись.

На чтение мы сервим эти данные в клиентский дашборд через SELECT sum(...) FROM ... WHERE ... GROUP BY ...

Т.е. на чтение это очень ClickHouse история, на запись кажется что вообще нет 🙂

Можно ли как-то адаптировать запись под ClickHouse чтобы уйти от Postgres?

#backend #clickhouse #database #devops #programming #russian

0

10.08.2023

10 ответов

7 просмотров

Vitali Kotik Автор вопроса

ivan
можно попробовать ReplacingMergeTree + партиции по...

Тут кастит есть нюанс наверное ReplacingMergeTree заменит старые строчки на новые Но не удалит старые строчки, которые перестали существовать. Это сценарий когда внешнее API спустя время не вернуло какую-то строку. Типа во внешнем сервисе случился какой-то внутренний reconciliation и они решили что такого сегмента данных нету на самом деле.

0

9 месяцев назад

critskiy

можно попробовать манипулировать TTL у таблицы

0

9 месяцев назад

ivan

Vitali Kotik
Тут кастит есть нюанс наверное ReplacingMergeTree ...

это важный нюанс )

0

9 месяцев назад

Vitali Kotik Автор вопроса