тогда в продолжении обсуждения, уточню следующии моменты:
id у нас строковый. Даже более того, это будет hex. Т.е. если разбивать по substr(id,1,1), то получается 16 партиций, по множеству [0-9,a-f]. Разбиении при этом получается равномерное, проверенно.
> если у них вообще есть запросы по конкретным айди, что вопрос на самом деле
Да, это один их основных кейсов. Выглядит это примерно так. Есть условный список id на 10M элементов. И вот по нему нужно строить различную аналитику. Т.е. нам реально важна быстрая выборка по id.
Собственно по id у нас строиться primary key. Остальные поля в order by, но не для ускорения анализа, а именно для схлопывания записей в ReplacingMergeTree.
> у них похоже каждый айдишник будет присутствовать в почти каждом месяце, а нужен только последний, те умножение данных минимум в 12 раз, что неприятно
Именно так. При этом, держать x12 копий данных на дисках накладно по деньгам. И, часто нужно анализировать данные по id за всю его историю, а не только за условный месяц.
> ещё можно вставлять в новый и все старые месяцы с минусом в Collapsing
@dj_mixer Спасибо, итересное предложение. Если я правильно понял, то получается в данном случае, нам на каждую запись в бд, потребуется делать 12 записей (по одной в каждую из партиций)?
> Ну тогда это все упирается в вопрос, насколько они готовы пожертвовать местом
Думаю для нас, выгоднее раз в пару недель запустить на несколько часов optimize final по всем данным, нежели чем платить за x12 дискового пространства.
