Коллеги, подскажите, насколько здравая идея использовать CH как Cassandra, делать

точечные запросы по полям с дико высокой кардинальностью (SELECT * FROM table WHERE uuid = '')

Догадываюсь что ключ сортировки - только это uuid, партиции по хэшу от ID, но всё же - не будет ли это выстрелом в ногу? или нормальная история?

а сколько запросов в секунду вы ожидаете? в целом очень плохая идея, время ответа будет в сотнях милисекунд

10-20, в переспективе до 50+ (насколько я понимаю Cassandra такое будет тянуть вообще без проблем)

ну 50 ещё по божески, это в любой БД должно работать, уж лучше в PG чтоли)

"партиции по хэшу от id" это , кстати, вообще не сработает здесь. клик считает хэш при вставке, при чтении "where id = ..." он использует min max индекс партиции, то есть при рандомно раскинутых по партициям айдишках, он скипнуть партиции не сможет и только на sorting key будет опираться. а sorting key из uuid, да еще и с минимальной гранулярностью, чтобы read overhead снизить, это всё выльется в потребление оперативки (метки primary key лежат в памяти) в общем, одни проблемы )

Понял принял, спасибо за разъяснение. Пользуясь случаем спрошу - есть ли какие-то альтерантивы Кассандре? SkyllaDB не в счет, а с DynamoDB получится vendor-lock

Очень плохая идея для CH и если используется Кассандра, предполагаю что данных много и в затюненый postgres они не поместились, решение классическое - как у Яндекс почты, быстрая бд с высокой кардинальностью и холодное хранилище с низкой

может, скипает, уже года два

где можно почитать / посмотреть?

хм, уже три года https://github.com/ClickHouse/ClickHouse/pull/16253 там правда работает id%100=5 но не работает id%100 in (5,6)

а, вот в чем подвох да, в fiddle вопроизвел с "=", прикольно

https://github.com/ClickHouse/ClickHouse/issues/28800 https://github.com/ClickHouse/ClickHouse/issues/55205

а то что в ORDER BY это не работает это ожидаемо? Недавно заметил это, пришлось на IN переписывать много запросов https://fiddle.clickhouse.com/85bb7165-cd78-47dc-b465-c1c2d754c264

сегодня прямо день not sargable предикатов, уже второй за сегодня )

в голове заиграла музыка: фарш невозможно провернуть назад ну этот как раз понятно почему не работает, это уже совсем невозможно

я понимаю что по minmax в целом такое скорее не должно работать, но если в одной грануле только одно значение и таких гранул много то можно в теории отсеивать

чтобы понять, что в грануле всё это время было только одно значение x % N, это значение надо подсчитать, а это происходит уже после отсеивания

так если min == max это разве не значит что только одно значение, применяем к этому значению % 30 и узнаём надо ли читать гранулу

так а если гранул 1000000 то что тогда?

сделайте skip min/max index id%30

ок, вроде понял, то есть ваша идея, что если 1. x на первой позиции в индексе 2. в where используется f(x) 3. то надо сначала подсчитать f(x) для всех меток и отбросить гранулы, у которых с обеих сторон x_start = x_end и f(x) false

кстати как узнать что в грануле есть id%30 ? надо проверить что в следующей грануле id равен id в текущей грануле, ну т.е. это все будет работать очень иногда и только для первого поля в индексе