Комментарии 9
Спасибо, а для повторяемости и корректировок эксперимента код тестов/отчетов опубликуете (github)?
Я конечно извиняюсь, но мерять компрессию для случайных данных - это весьма специфичная забава. Меряйте компрессию своих данных.
Если говорить о кодеках в КХ, то подход очень простой - понять что у вас за данные, и как они лежат; подобрать ключ сортировки таким образом, чтобы энтропия была минимальной (тут еще, конечно, надо учитывать то, как вы эти данные потом запрашиваете), и уже потом поиграться с кодеками (которые, кстати, можно накладывать друг на друга - сначала пожать даблдельтой, а сверху придавить LZ4, например).
Что касается баланса степени сжатия и скорости разжатия, я б сказал что почти всегда сильнее сжатые данные будут обрабатываться быстрее - меньше данных гонять с диска в память, и из памяти в процессор.
Спасибо за материал. Подскажите, какая версия ClickHouse использовалась при замерах?
Странно, что в тест не включили просто сжатие ZSTD без кодеков.
От себя могу добавить:
в первую очередь подбираем ORDER BY таблиц, потом уже тестируем кодеки, если нужно
тестируйте на своих реальных данных для каждой конкретной таблицы
для целых чисел (включая Date, DateTime, Decimal и Enum) часто хорош вариант (T64, LZ4)
для строк не ошибкой будет всегда выбирать между двумя вариантами: ZSTD или LowCardinality
LowCardinality может быть выгоден и гораздо больше чем для 10000 уникальных значений, особенно если строки длинные
для коротких строк можно по умолчанию оставлять LZ4
LZ4HC очень медленный на вставку
Clickhouse: сжимаем данные эффективно