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

@nyoroon очень сомневаюсь я насчёт того, что данные в колонке анализируются и собираются в кастомные словари. Иначе, у меня бы compress ratio был в 2 раза больше, чем 2.27

Dictionary gains are mostly effective in the first few KB. Then, the compression algorithm will gradually use previously decoded content to better compress the rest of the file.

Привет!
можно ли в кх сделать insert if exists?

Привет!
Клиент/сервер клика 20.3.8.53. Запросы типа  ALTER TABLE xxx DROP/MODIFY COLUMN yyy выполняются по факту моментально, но висят как невыполненные часами. Не убиваются, не мешают работать. Исчезают после рестарта запустившей их реплики.
Никто с таким не сталкивался?

Вообще так сжатие работает

Нельзя, в кх primary key не обеспечивает уникальность, проверять очень дорого

не достаточно точно выразился. Хочу проверять сущетсвует ли таблица перед инсертом

@nyoroon  Это работает только на каких-то монотонно-возрастающих последовательностях. Когда данные идут вразнобой, то сжатие около 2 раз всего. Хотя, я вот сделал GROUP BY моей слабосжимаемой колонке на 60 млн. данных, просуммировал первые 65536 и получил цифру в 75% от всех моих данных. То есть в словарь с 65536 элементами влезает 75% моих 64-битных Decimal, которые идут почти рандомном порядке. Мне кажется, это дало бы большой буст, как по сжатию, так и по скорости, если бы была возможность свои словари подключать для ZSTD

Есть какой-нибудь способ различить реальную 500 в ответе и 400, которые тоже отдаются как 500, но проблемы с запросом? Просто непонятно, как перезапросы делать правильно в таком случае

А ты пробовал для начала это сделать с zstd вне кликхауса?

@nyoroon  Нет, но уже 4 дня медитирую на сжатие в кликхаусе для разных типов данных и разных алгоритмов. Перепробовал все доступные варианты. Получил результат от 1.5 раз до 780 в зависимости от характера данных. Я понимаю о чем ты говоришь, приводя цитаты из документации. И там же дальше говорится, почему нужно пробовать кастомные словари и какой это даёт буст. Из моих наблюдений получается, если данные совсем рандомные и распределены равномерно, то ничего не поможет, если есть хоть какая монотонно-измеряющаяся последовательность даже рывками, то можно добиться 6 кратного сжатия, например для price в валютных парах. А вот quantity для этого price сжимается всего в 2 раза, хотя можно больше, если были бы кастомные словари.

Но надо попробовать поэкспериментировать с ZSTD вне кликхауса.

Подскажите пожалуйста, решается вопрос с загрузкой данных в Клик (выбор вариантов), коллеги говорят (я проверить не могу) что его драйвер JDBC не поддерживает поля - массивы. Это неужели реально так? Средства работы с массивами в клике весьма развиты и удобны, откуда же они тогда в нем появляются, если все их (да и остальных данных) формирование я должен делать за пределами Клика и вгружать их в него готовыми? (((

У офф драйвера поддержка массивов есть https://github.com/ClickHouse/clickhouse-jdbc/blob/8481c1323f5de09bb9dbbf67085e5e1b2585756a/src/test/java/ru/yandex/clickhouse/integration/ArrayTest.java#L107

Спасибо!!! буду копать....

У меня были проблемы с Apache Spark с записью в КХ через офф-драйвер, но это имено спарк выделывался

через spark-jdbc , скорее всего, и не получится. Диалект КЛикхауса спарк не распознает, кажется

нужно руками на воркерах создавать jdbc-коннекшн