Это я Денису ответить хотел.

пожалуйста используйте функцию "ответить", а то ваши сообщения кажутся немного оторванными от контекста

Да я думал, что использовал. А оказалось, что нет.

Да, там сам чёрт ногу сломит, но оказаться в лагере тех, у кого течёт, тоже не хочется. Ну и вообще, если оно не реплицированное, то увы не подойдёт :(

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

Если их выполнять по очереди, в целом жить можно нормально

а там разве спрашивали про это ? Какая разница кто там источник для словаря. У меня например http словари, я даже не знаю что там позади, монга или rocksdb. При чем тут источник словаря? Там спрашивали не про это КМК

верно, несколько колонок для сортировки, одним order by не обойтись, но он в кх только один как я понимаю

не, неправильно вы понимаете
mysql не может использовать несколько индексов для оптимизации сортировки одновременно

ну сортировка то по одному полю за запрос, мне это и надо

в смысле надо одну и туже таблицу читать разными select order by ?

да

что за задача такая да еще в КХ?

видимо да КХ этого не умеет и планов на это нет, скорее всего никогда не будет

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

ну просто я использую его чтобы изменения товаров агрегировать, графики посчитать быстро. Заметил, что он очень хорошо может и like %% по имени товара искать, так что думаю перенести с мускула и эту таблицу тоже, проблема только в сорте, остальное отлично)

Нет, КХ не может заменить mysql совсем.

эх, спасибо

Там я спросил про то, имеет ли вообще смысл использовать словарь для того, чтобы указать кликхаусу, какую версию данных надо тянуть, или есть более оптимальный подход?

Предположим, что есть вот такой утрированный запрос: SELECT something FROM table WHERE date = ? AND key = ?. В реальности там сотни тысяч строк для каждого ключа, и в запросах проводится дополнительная агрегация, что кликхаус делает очень быстро. Корректировка предполагает полную перезапись данных для пары (date, key). Вместо перезаписи мы хотим сделать дополнительную колонку с версией, а список последних версий вытягивать при помощи external dictionary. Запрос тогда приобретает вид SELECT something FROM table WHERE date = ? AND key = ? AND version = dictGet('versions_dict', 'version', (date, key)). Пишу с телефона по памяти, поэтому за ошибки в синтаксисе прошу не бить :)

При финальной чистке планируем обновлять колонку с версией таким образом, чтобы самую новую версию сбросить в ноль, тем самым получая дефолтное значение dictGet для случая, когда в словаре данных нет.

И потом уже можно эти все версии грохнуть из хранилища, на основе которого словарь строится.

>AND version = dictGet('versions_dict', 'version', (date, key))

это очень медленно и очень затратно.
пожалуй это будет медленее чем ReplacingMergeTree и +agrmax