Size: a a a

ClickHouse не тормозит

2020 May 27

D

Dj in ClickHouse не тормозит
Andrey
Это старый(до optimize final):

# clickhouse-compressor --stat < stock_datetime.bin | head
65536   13595
65536   13632
65536   13655
65536   14059
65536   13609
65536   13638
65536   13661
65536   14155
65536   13611
65536   13660



А это новый:

# clickhouse-compressor --stat < stock_datetime.bin | head
65536   25871
65536   30385
65536   27053
65536   30297
65536   31478
65536   29336
65536   27066
65536   28165
65536   27064
65536   25916
я вот до сих пор не верю что данные могут быть такими, но походу у вас так и есть =) проверим zstd...
источник

A

Andrey in ClickHouse не тормозит
Maxim Bogdanov
Плюс мне нужно делать запросы в обе стороны. Скажем, выгрести все ивенты всех пользователей мужского пола - я же буду начинать выборку с таблицы профилей и далее уже джойнить ивенты. Или же наоборот - хочу выгрести всех пользователей, которые совершили действие AddToCart. Тут уже наоборот джойн пойдёт. А ещё круче - сделать запрос всех пользователей мужского пола, сделавших действие AddToCart. Такие дела 🙂
В CH есть много потрясающих фич.
Внешние словари, remote, odbc.
А еще его можно подключить через fdw к Postgres.
источник

M

Munir in ClickHouse не тормозит
Я использовал, вроде ок. Самое главное для чего вам надо. Для ответа на вопрос держите в уме, что при джойне правый селект поднимается в память (вам же груп бай сделать надо будет над replacemt). Если это учитывать, то можно использовать. Профилей сущностей у меня было несколько миллионов, если не с десяток. Но сейчас вспомнил, что все таки первым шагом pipeline я таки их во временную таблицу заливал, чтобы с последним срезом работать.
источник

D

Dj in ClickHouse не тормозит
Andrey
Это старый(до optimize final):

# clickhouse-compressor --stat < stock_datetime.bin | head
65536   13595
65536   13632
65536   13655
65536   14059
65536   13609
65536   13638
65536   13661
65536   14155
65536   13611
65536   13660



А это новый:

# clickhouse-compressor --stat < stock_datetime.bin | head
65536   25871
65536   30385
65536   27053
65536   30297
65536   31478
65536   29336
65536   27066
65536   28165
65536   27064
65536   25916
drop table if exists test;
create table test (pk1 Int32, val UInt64 ) ENGINE = MergeTree()  order by (pk1);
insert into test select arr, cityHash64(number) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+2000) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+4000) from numbers(2000) array join range(8192) as arr;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬─────────────compratio─┐
│ test  │ all_1_1_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_1_1_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_2_2_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_2_2_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_3_3_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_3_3_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴───────────────────────┘

optimize table test final;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬────────────compratio─┐
│ test  │ all_1_3_1 │ pk1    │                       924725 │                      196608000 │ 0.004703394571940104 │
│ test  │ all_1_3_1 │ val    │                    289752000 │                      393216000 │     0.73687744140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴──────────────────────┘

@den_crane @rheinx
я насимулировал =))) 24% в одном парте, после мерджа трех партов ломается до 73%...
вот... короче, у вас данные такие...
если у вас  рандомность колонки увеличивается посли мерджа (т.е. рандом данные внутри 64кб блоков), вам ничего не поможет...
не будет он сжимать.
а данные у вас именно такие, Андрей, живите с ними... или zstd вешайте, или упрощайте ключ сортировки
источник

A

Andrey in ClickHouse не тормозит
Dj
drop table if exists test;
create table test (pk1 Int32, val UInt64 ) ENGINE = MergeTree()  order by (pk1);
insert into test select arr, cityHash64(number) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+2000) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+4000) from numbers(2000) array join range(8192) as arr;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬─────────────compratio─┐
│ test  │ all_1_1_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_1_1_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_2_2_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_2_2_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_3_3_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_3_3_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴───────────────────────┘

optimize table test final;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬────────────compratio─┐
│ test  │ all_1_3_1 │ pk1    │                       924725 │                      196608000 │ 0.004703394571940104 │
│ test  │ all_1_3_1 │ val    │                    289752000 │                      393216000 │     0.73687744140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴──────────────────────┘

@den_crane @rheinx
я насимулировал =))) 24% в одном парте, после мерджа трех партов ломается до 73%...
вот... короче, у вас данные такие...
если у вас  рандомность колонки увеличивается посли мерджа (т.е. рандом данные внутри 64кб блоков), вам ничего не поможет...
не будет он сжимать.
а данные у вас именно такие, Андрей, живите с ними... или zstd вешайте, или упрощайте ключ сортировки
😭😭😭
источник

DT

Dmitry Titov in ClickHouse не тормозит
Dj
drop table if exists test;
create table test (pk1 Int32, val UInt64 ) ENGINE = MergeTree()  order by (pk1);
insert into test select arr, cityHash64(number) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+2000) from numbers(2000) array join range(8192) as arr;
insert into test select arr, cityHash64(number+4000) from numbers(2000) array join range(8192) as arr;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬─────────────compratio─┐
│ test  │ all_1_1_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_1_1_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_2_2_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_2_2_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
│ test  │ all_3_3_0 │ pk1    │                       333029 │                       65536000 │ 0.0050816192626953124 │
│ test  │ all_3_3_0 │ val    │                     32584000 │                      131072000 │      0.24859619140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴───────────────────────┘

optimize table test final;

SELECT
   table,
   name,
   column,
   column_data_compressed_bytes,
   column_data_uncompressed_bytes,
   column_data_compressed_bytes / column_data_uncompressed_bytes AS compratio
FROM system.parts_columns AS pc
WHERE (table = 'test') AND active

┌─table─┬─name──────┬─column─┬─column_data_compressed_bytes─┬─column_data_uncompressed_bytes─┬────────────compratio─┐
│ test  │ all_1_3_1 │ pk1    │                       924725 │                      196608000 │ 0.004703394571940104 │
│ test  │ all_1_3_1 │ val    │                    289752000 │                      393216000 │     0.73687744140625 │
└───────┴───────────┴────────┴──────────────────────────────┴────────────────────────────────┴──────────────────────┘

@den_crane @rheinx
я насимулировал =))) 24% в одном парте, после мерджа трех партов ломается до 73%...
вот... короче, у вас данные такие...
если у вас  рандомность колонки увеличивается посли мерджа (т.е. рандом данные внутри 64кб блоков), вам ничего не поможет...
не будет он сжимать.
а данные у вас именно такие, Андрей, живите с ними... или zstd вешайте, или упрощайте ключ сортировки
просто натравить нормальный кодек и все станет хорошо
источник

DT

Dmitry Titov in ClickHouse не тормозит
кмк
источник

D

Dj in ClickHouse не тормозит
Andrey
😭😭😭
ORDER BY (shop_id, plu, stock_datetime)

выброситу plu - жить станет легче
источник

D

Dj in ClickHouse не тормозит
Dmitry Titov
просто натравить нормальный кодек и все станет хорошо
ну да, но там рандом, мы у себя игрались всем чем можно... +/-3%
источник

DT

Dmitry Titov in ClickHouse не тормозит
Dj
ну да, но там рандом, мы у себя игрались всем чем можно... +/-3%
ну дата, и даже таймштампы совсем не рандомны
источник

D

Dj in ClickHouse не тормозит
попробуйте Т64, @rheinx
источник

DT

Dmitry Titov in ClickHouse не тормозит
всякие DELTA T64
источник

A

Andrey in ClickHouse не тормозит
Dj
попробуйте Т64, @rheinx
ща, ZSTD жду пока мерж пройдет
источник

D

Dj in ClickHouse не тормозит
в комбинации с ZSTD - кодеки не особо помогали, он там сам походу умеет частично группировать по умному
источник

A

Andrey in ClickHouse не тормозит
Dj
ORDER BY (shop_id, plu, stock_datetime)

выброситу plu - жить станет легче
низя, там большинство запросов идет по shop_id/plu.
Внутри 1 shop_id может быть потенциально 1 млн plu
источник

D

Dj in ClickHouse не тормозит
Andrey
низя, там большинство запросов идет по shop_id/plu.
Внутри 1 shop_id может быть потенциально 1 млн plu
тогда возьмите кусок данных, только с одинаковыми shop_id и plu из финальной таблицы побольше размером, и попробуйте все варианты кодеков
источник

D

Dj in ClickHouse не тормозит
Andrey
низя, там большинство запросов идет по shop_id/plu.
Внутри 1 shop_id может быть потенциально 1 млн plu
stock_datetime в сортировке - Delta/DoubleDelta могут помочь
источник

A

Andrey in ClickHouse не тормозит
Dj
тогда возьмите кусок данных, только с одинаковыми shop_id и plu из финальной таблицы побольше размером, и попробуйте все варианты кодеков
угу, похоже придется.
источник

D

Dj in ClickHouse не тормозит
а вот другое поле changed - там надо играть
источник

A

Andrey in ClickHouse не тормозит
Вот только я пока не понял. Что меняется после мержа.
Ведь OPTIMIZE FINAL меняет эти куски не впервые. Они и до этого же проходили мержи.
Там раз в час идет несколько заливок происходит.
Т.е. если я верно понимаю, куски должны всегда содержать столько рандома.
источник