l
тестировали. хуже + к тому же медленнее после определенного уровня
Ну медленнее на сжатии, это правда
Size: a a a
2020 August 30
l
ещё можете увеличить размер блока компрессии... так zstd будет более эффективен
Он вроде в профиле пользователя задаётся, не очень удобно на самом деле
l
вообще сжатие надо тестировать именно на ваших данных... ордербай решит компрессию на колонках ключа, а на остальных не поможет
Не совсем, ведь зависимость распределения данных на колонках вне ордер бай может соответствовать распределению в колонках в order by
DC
вообще сжатие надо тестировать именно на ваших данных... ордербай решит компрессию на колонках ключа, а на остальных не поможет
ну как не поможет на остальных, у меня например 400 полей в таблице и в ключе 4 колонки, при этом в 100 атрибутах ивентов могут быть повторяющиеся данные, типа пользователь буквально бродит по сайту и у него в сессии содержимое корзины, и того что он смотрел и всякие атрибуты браузера будут повторятся и сожмутся потому что эти строки будут подряд.
D
Не совсем, ведь зависимость распределения данных на колонках вне ордер бай может соответствовать распределению в колонках в order by
ну да, ну да, это кроме как ID, Name очень редко бывает =)
D
ну как не поможет на остальных, у меня например 400 полей в таблице и в ключе 4 колонки, при этом в 100 атрибутах ивентов могут быть повторяющиеся данные, типа пользователь буквально бродит по сайту и у него в сессии содержимое корзины, и того что он смотрел и всякие атрибуты браузера будут повторятся и сожмутся потому что эти строки будут подряд.
в целом верно, но колонки с низкой кардинальностью внутри блока (например браузер, версии ) сжиматся и так нормально должны кстати...
D
Ну медленнее на сжатии, это правда
zstd тоже тормозит на сжатии относительно lz4... с этим имхо только жить... или быстро грузим (lz4), или мало грузим (zstd)...
D
Он вроде в профиле пользователя задаётся, не очень удобно на самом деле
я думаю это надо задавать в дефолт, иначе работать на мерджах не будет
min_compress_block_size 65536
max_compress_block_size 1048576
на больших объемах не пробовали, но вот когда дистинкт в среднем пробивает 10к из 65к, оно помогает, хотя там конечно порядок тоже решает
min_compress_block_size 65536
max_compress_block_size 1048576
на больших объемах не пробовали, но вот когда дистинкт в среднем пробивает 10к из 65к, оно помогает, хотя там конечно порядок тоже решает
l
я думаю это надо задавать в дефолт, иначе работать на мерджах не будет
min_compress_block_size 65536
max_compress_block_size 1048576
на больших объемах не пробовали, но вот когда дистинкт в среднем пробивает 10к из 65к, оно помогает, хотя там конечно порядок тоже решает
min_compress_block_size 65536
max_compress_block_size 1048576
на больших объемах не пробовали, но вот когда дистинкт в среднем пробивает 10к из 65к, оно помогает, хотя там конечно порядок тоже решает
Вот это меня и смущает, казалось бы логичнее этой настройке быть у каждой таблицы
D
да, я тоже ожидал это как merge-tree-setting
D
но, как говорил Андрей Сергеич, "ваши ожидания ваши проблемы"
A
По дефолту лз4 вроде, а насколько лз4хс хуже чес зстд на больших уровнях сжатия?
У меня от 2-3 раз до 1000 раз сильнее жмет.
A
Движок как бы один: MergeTree выбирать не из чего.
1. Главное это Order by -- положить похожие значения рядом, тогда сработает компрессия.
все остальные пункты просто жалкие полумеры, мертвому припарки.
2. Не использовать Nullable
3. Все кодировать числами по максимуму (LowCardinality если строки не удалось закодировать в числа)
4. Использовать минимальные типы, влезает в UInt8 - значит UInt8
5. Огрублять значения DateTime, Float, Decimal насколько возможно.
6. Компресия ZSTD по дефолту в конфиге
7. Ни в коем случае не использовать UUID потому что каким-то баранам показалось что в UInt64 коллизии будут якобы влиять на результат
8. Тестировать Codec-и, да Delta помогает, т.е. смотрим на самую жирную колонку и думаем а что если вот так, фигачим тестовую таблицу, переливаем туда миллиард строк, фигачим другую таблицу переливаем туда тот же миллиард из первой и сравниваем и т.д.
ZSTD(2) (3) умеет примерно все теже кодеки сам, но жрет cpu.
1. Главное это Order by -- положить похожие значения рядом, тогда сработает компрессия.
все остальные пункты просто жалкие полумеры, мертвому припарки.
2. Не использовать Nullable
3. Все кодировать числами по максимуму (LowCardinality если строки не удалось закодировать в числа)
4. Использовать минимальные типы, влезает в UInt8 - значит UInt8
5. Огрублять значения DateTime, Float, Decimal насколько возможно.
6. Компресия ZSTD по дефолту в конфиге
7. Ни в коем случае не использовать UUID потому что каким-то баранам показалось что в UInt64 коллизии будут якобы влиять на результат
8. Тестировать Codec-и, да Delta помогает, т.е. смотрим на самую жирную колонку и думаем а что если вот так, фигачим тестовую таблицу, переливаем туда миллиард строк, фигачим другую таблицу переливаем туда тот же миллиард из первой и сравниваем и т.д.
ZSTD(2) (3) умеет примерно все теже кодеки сам, но жрет cpu.
Почему не использовать Nullable?
A
ещё можете увеличить размер блока компрессии... так zstd будет более эффективен
А это идея. Чем чревато?
l
Почему не использовать Nullable?
Потому что Null не Null флаг хранится в отдельном файле словаре рядом с колонкой, что отрицательно сказывается на производительности
D
Почему не использовать Nullable?
он почему-то плохо сжимает файлик с нулями и данными...
со спец значением лучше работает
со спец значением лучше работает
D
А это идея. Чем чревато?
ну, будет больше читаться с диска когда фильтруете по индексу... т.е. блок компрессии это минимальный размер того, что считается
A
Движок как бы один: MergeTree выбирать не из чего.
1. Главное это Order by -- положить похожие значения рядом, тогда сработает компрессия.
все остальные пункты просто жалкие полумеры, мертвому припарки.
2. Не использовать Nullable
3. Все кодировать числами по максимуму (LowCardinality если строки не удалось закодировать в числа)
4. Использовать минимальные типы, влезает в UInt8 - значит UInt8
5. Огрублять значения DateTime, Float, Decimal насколько возможно.
6. Компресия ZSTD по дефолту в конфиге
7. Ни в коем случае не использовать UUID потому что каким-то баранам показалось что в UInt64 коллизии будут якобы влиять на результат
8. Тестировать Codec-и, да Delta помогает, т.е. смотрим на самую жирную колонку и думаем а что если вот так, фигачим тестовую таблицу, переливаем туда миллиард строк, фигачим другую таблицу переливаем туда тот же миллиард из первой и сравниваем и т.д.
ZSTD(2) (3) умеет примерно все теже кодеки сам, но жрет cpu.
1. Главное это Order by -- положить похожие значения рядом, тогда сработает компрессия.
все остальные пункты просто жалкие полумеры, мертвому припарки.
2. Не использовать Nullable
3. Все кодировать числами по максимуму (LowCardinality если строки не удалось закодировать в числа)
4. Использовать минимальные типы, влезает в UInt8 - значит UInt8
5. Огрублять значения DateTime, Float, Decimal насколько возможно.
6. Компресия ZSTD по дефолту в конфиге
7. Ни в коем случае не использовать UUID потому что каким-то баранам показалось что в UInt64 коллизии будут якобы влиять на результат
8. Тестировать Codec-и, да Delta помогает, т.е. смотрим на самую жирную колонку и думаем а что если вот так, фигачим тестовую таблицу, переливаем туда миллиард строк, фигачим другую таблицу переливаем туда тот же миллиард из первой и сравниваем и т.д.
ZSTD(2) (3) умеет примерно все теже кодеки сам, но жрет cpu.
Спасибо, отличные рекомендации. Надо бы вообще нечто-подобное прикрепить вверху чата, как шпаргалку.
PL
тестировали. хуже + к тому же медленнее после определенного уровня
У нас обратный результат: используем lz4hc для json, почти в два раза лучше сжимает, чем lz4 с двойным падением скорости сжатия. Зато скорость разжатия такая же, как в lz4.
А zstd это не только сжатие повторений, но ещё и энтропийное, так что там дороже и сжатие и разжатие.
Но все зависит от данных, конечно, и требований
А zstd это не только сжатие повторений, но ещё и энтропийное, так что там дороже и сжатие и разжатие.
Но все зависит от данных, конечно, и требований
D
У нас обратный результат: используем lz4hc для json, почти в два раза лучше сжимает, чем lz4 с двойным падением скорости сжатия. Зато скорость разжатия такая же, как в lz4.
А zstd это не только сжатие повторений, но ещё и энтропийное, так что там дороже и сжатие и разжатие.
Но все зависит от данных, конечно, и требований
А zstd это не только сжатие повторений, но ещё и энтропийное, так что там дороже и сжатие и разжатие.
Но все зависит от данных, конечно, и требований
zstd хуже сжимал json чем lz4hc?
Есть примерные цифры чтобы порядок оценить?
Есть примерные цифры чтобы порядок оценить?