Хочу уменьшить кол-во данных на диске. Сейчас в базу пишем

"время, событие, название товара"... где название товара - длинная строка.
Логично заменить на ID. В качестве ID можно использовать хеш функцию (колизий нет). Вопрос как правильно средствами кликхауса хранить инфу о соответствии ID=товар?
Проблема в том что постоянно появляются новые товары о которых мы не знали. На данный момент всего 25 миллиона уникальных товаров. И в базу прилетает больше миллиона записей в минуту. Хотелось бы чтобы при вставке данных в кликхаус эта информация писалась в отдельную таблицу.

насколько я понял вам нужно просто лоукардиналити заюзать и всё

На 25лямов я бы не стал

почему 25?

а точно не заметил этот момент

лоукардиналити эффективен примерно при 64к уникальных объектов. дальше чем больше тем хуже...

Вы потом как то джойнить хотите хеш = строка?

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

этой задачей сжатие занимается, колоночная БД же

А методы сжатия для колонки пробовали разные?

лучшие результаты zstd(1) дает. но кажется что сжатие это неправильное направление. Так как к примеру надо часто считать кол-во уникальных товаров. С хешами это работает быстрее. Хранить и то и другое — неправильно. Плюс хеши на диске занимают в 4 раза меньше места (с учетом сжатия).

Ну если дальше у вас джоин (или его аналог) не смущает - то решение отличное

Да, join устраивает. Вопрос как данные записывать? Если хочется чтоб в кликхаус прилетал только один запрос на вставку в основную таблицу?

Лучше lowcardinality, а не джойн. Союытий же мало уникальных? Тогда order by (событие, название товара). Еще дату, а не время в order by добавить перед или после события. Партиции по месяцам или дням. Вообще такой order by и сам по себе строки эти сильно сожмет даже без lowcardinality, а если мало будет, то zstd еще навесить.

А как ордер бай сжимает строки?

ну в основном он и сжимает. Одно дело сжать a, d, e, a, x, e... другое дело a, a, a, b, b, b...

ага понял. это внутри гранулы индекса одной получается происходит

Не совсем так, LowCardinality вместо 'aaa', 'bbb', 'aa', 'bb', 'aaa', 'bbb', 'aa,', 'bb' сожмет 1,2,3,4,1,2,3,4

при селектах LowCardinality не даст снижения получаемого объёма данных, рассматривать жор памяти сервером в данном случае некорректно

а почему некорректно? не понял

оно в строку преобразуется

ну вот у меня есть замеры когда именно преобразование в lowcardinality сокращает в 2.5х оперативу. некоторые запросы которые по памяти падали начинают проходить

Ну, теоретически, можно было бы сравнивать подноготную, что там за строкой лежит, но...

Вставка в Null таблицу, на ней два MV: 1. считает хеш и пишет все колонки + хеш, но без названия в основую таблицу хранения 2. считает хеш по тому-же самому алгоритму, пишет хеш и название товара в таблицу с engine = Join/ANY (any - на всякий случай, если таки коллизия, а может и all - надо смотреть). Аналитический запрос, требующий название делает joinGet Чтобы не считать хеш повторно можно это сделать в прикладной программе, которая грузит данные. Пока в КХ нет транзакций, при ошибках может случиться, что в одну таблицу инсерт пройдет, а во вторую - нет (обещали сделать в этом году).