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

строковом формате? Запросы к String'ам очень медленно идут. LowCardinality, как я понял, подходит, если уникальных значений столбца не более 10к, у меня же этих уникальных значений может быть неограниченное множество.

Zstd кодек А вообще по low cardinality все сложнее читайте тред https://github.com/ClickHouse/ClickHouse/issues/36428

Видимо, идея класть в CH данные в максимально подходящем формате, используя строки только действительно для строк, приходила вам в голову ;) , но ее реализации что-то помешало?

похоже, попросить пример данных, узнать какой ключик у таблички, есть ли вторичные индексы, посмотреть пример запроса пользуется ли он всем этим, вам это всё очевидно, только что-то помешало предложить помощь )

Что вы имеете ввиду? У меня String тип данных используется сугубо для строк, например, для названий объектов; как пользователь назвал объект, такая строка и прилетела, таких объектов могут быть сотни тысяч, какие-то создаются, какие-то удаляются.

КХ у меня используется как хранилище данных. Туда льются временные ряды, за 1 час сейчас прилетают сотни тысяч строк, а будут прителать миллионы. На основе данных из хранилища будут строиться аналитические дашборды, на которых будет отражаться динамика изменения этих временных рядов (что-то вроде того, что можно в прометеусе получить, только больше графиков на одной странице). Похоже, что всё таки КХ я использую правильно. Согласно расчетам, максимальный объем данных, который может может запросить пользователь - это 100к строк. Моя задача следать так, чтобы эти данные долетели максимально быстро. Поэтому т. к. отличить данные одного объекта от другого можно только по наименованию (стрингу), нужно каким-то образом упростить чтение этого столбца. Раньше я спокойно обходился без оптимизации, но теперь она нужна, а знаний у меня не хватает. Поэтому я и прошу совета у более опытных коллег, в том числе у вас.

А эти названия, введённые пользователем, отображаются на дашбордах? Ввод не контролируется? Если да, боюсь, будет интересно, когда какой-нибудь шутник выведет на дашборде данные с "говнодатчика" )))

я вижу в вашем первом вопросе и в этом тексте противоречие Сначала вы пишите про запросы к строкам, что звучит как поиск неких значений внутри строк. А теперь вы пишите про аналитический запросы, что подразумевает группировки и агрегации. если вам нужно делать группировки и агрегации по строкам содержащим что-то, то это пример плохой архитектуры данных, такие значения должны быть атомарны, а не где-то внутри строк. Наконец, пользователям аналитики на фиг не нужны сотни тысяч строчек )))

Вот это и имею ввиду. Прежде чем оптимизировать работу со строками, хочется убедиться, что от строк нельзя избавиться. Судя по вашим словам, избавиться нельзя, и закономерности в строках нет. Остаются возможности, которые уже были упомянуты: сжатие, вторичные индексы. Если строчки прямо реально длинные, в CH недавно появились обратные индексы, можно попробовать https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/invertedindexes Ну и какой-нибудь особенно печалящий вас запрос можно сюда принести показать. Лучше с помощью https://pastila.nl/

Подскажите пожалуйста, а в какой версии появился обратный индекс?

Спасибо за помощь!

Первый PR https://github.com/ClickHouse/ClickHouse/pull/38667 замерджили в начале 2022-го года, т.е. первый lts 22.3 . Но этот функционал до сих пор experimental, там постоянно что-то допиливается. С какого момента его можно реально использовать на production (и наступил ли этот момент сейчас), я не знаю.