DT
смотришь ли ты только на активные парты, в общем?
Size: a a a
2020 May 27
A
ты какой запрос делаешь?
SELECT
partition,
column,
sum(rows),
formatReadableSize(sum(column_bytes_on_disk)) AS column_bytes_on_disk,
formatReadableSize(sum(column_data_uncompressed_bytes)) AS column_data_uncompressed_bytes,
type
FROM system.parts_columns
WHERE active AND (type IN ('DateTime', 'Date')) AND (table = 'my_table') AND (partition IN ('202002', '202004'))
GROUP BY
partition,
column,
type
ORDER BY
column ASC,
partition ASC
A
смотришь ли ты только на активные парты, в общем?
да, только активные
DT
Ну видимо, что то поменялось у вас в распределении данных, но вообще 20гб на 11к уникальных значений и сжатие меньше чем в 2 раза, это как то странно для дат, таймстампов
D
Ну видимо, что то поменялось у вас в распределении данных, но вообще 20гб на 11к уникальных значений и сжатие меньше чем в 2 раза, это как то странно для дат, таймстампов
если даты случайные - вполне нормально
A
Но до optimize final было лучше. Учитывая что это ReplacingMergeTree, должно же было сжать сильнее. Уж точно не увеличиться
MM
Если заводить для таблицы ещё одну реплику, но в DDL не указать пару колонок, то будет ошибка:
А можно ли создать реплику для таблицы не зная её DDL? Ну т.е. "дорогой, Clickhouse, у меня вот эта таблица имеет движок ReplicatedMergeTree, вот на этой машине сделай для неё реплику, пожалуйста".
Received exception from server (version 20.4.2):
Code: 122. DB::Exception: Received from localhost:9000. DB::Exception: Table columns structure in ZooKeeper is different from local table structure.
А можно ли создать реплику для таблицы не зная её DDL? Ну т.е. "дорогой, Clickhouse, у меня вот эта таблица имеет движок ReplicatedMergeTree, вот на этой машине сделай для неё реплику, пожалуйста".
D
Но до optimize final было лучше. Учитывая что это ReplacingMergeTree, должно же было сжать сильнее. Уж точно не увеличиться
optimize final - уменьшает количество строк... сжатие при этом может стать хуже...
D
Но до optimize final было лучше. Учитывая что это ReplacingMergeTree, должно же было сжать сильнее. Уж точно не увеличиться
у вас используется на encoding колонках? на случайных данных лучше encondingами не баловатся....
A
у вас используется на encoding колонках? на случайных данных лучше encondingами не баловатся....
неа. Это дефолтная таблица. Причем созданная еще на 19.* версии CH.
DT
у вас используется на encoding колонках? на случайных данных лучше encondingами не баловатся....
там вообще нет кодировок.
D
куда оффер высылать? )
D
неа. Это дефолтная таблица. Причем созданная еще на 19.* версии CH.
попробуйте zstd1... он на random данных в разы лучше дефолтного lz4 был у нас
D
неа. Это дефолтная таблица. Причем созданная еще на 19.* версии CH.
а количество партов в партициях тоже совпадает примерно?
A
а количество партов в партициях тоже совпадает примерно?
партов теперь по 1
DT
попробуйте zstd1... он на random данных в разы лучше дефолтного lz4 был у нас
11к уников на сколько там млрд данных, это нефига не рандом и должно нормально жатся имхо
A
Меня просто сильно беспокоит такая разница в размере до и после optimize final.
До optimize final
202004 event_datetime 14949814777 13.90 GiB 55.69 GiB
После optmize final:
202004 event_datetime 14949814777 35.42 GiB 55.69 GiB
До optimize final
202004 event_datetime 14949814777 13.90 GiB 55.69 GiB
После optmize final:
202004 event_datetime 14949814777 35.42 GiB 55.69 GiB
A
Т.е. таблица сама по себе не изменилась.
А вот сжатый объем вырос больше чем в 2 раза
А вот сжатый объем вырос больше чем в 2 раза
S
а сколько парттов до и после?