которая делает единицы миллинов исходящих 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?
можно попробовать ReplacingMergeTree + партиции по месяцам или неделям + optimize table ... partition ... final после вставки
Тут кастит есть нюанс наверное ReplacingMergeTree заменит старые строчки на новые Но не удалит старые строчки, которые перестали существовать. Это сценарий когда внешнее API спустя время не вернуло какую-то строку. Типа во внешнем сервисе случился какой-то внутренний reconciliation и они решили что такого сегмента данных нету на самом деле.
можно попробовать манипулировать TTL у таблицы
это важный нюанс )
интересная мысль - некогда не думал про это интуитивно страшноват т.к. новые данные могут просто не придти вовремя, а старые при этом удалятся по ttl
Просто партиционируйте по дням и дропайте старые партиции
Я не понял, что, откуда и куда хотите аттачить. Но, в любом случае, мне не известны детали того, как у вас данные обновляются, вам виднее
Спасибо за идею, подумаю. На CH пока нету системы. На Postgres она описана здесь https://t.me/clickhouse_ru/336648
С постгресом-то я понял. Всё равно, нужно знать больше деталей и решать по месту. К слову, есть ещё REPLACE PARTITION
О спасибо! видимо жанглирование партициями это распространенный юзкейс раз есть такие ф-ции
Обсуждают сегодня