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

а что значит "покрыть  mergeengine" ?=)

Подскажите пожалуйста как побороть баг. Есть таблица

Row 2:
──────
database:                   default
name:                       test_partition_drop_bug2
engine:                     ReplicatedMergeTree
is_temporary:               0
data_paths:                 ['/data/clickhouse/data/default/test_partition_drop_bug2/']
metadata_path:              /data/clickhouse/metadata/default/test_partition_drop_bug2.sql
metadata_modification_time: 2020-08-31 12:12:08
dependencies_database:      []
dependencies_table:         []
create_table_query:         CREATE TABLE default.test_partition_drop_bug2 (`d` Date, `s` String) ENGINE = ReplicatedMergeTree('/test/test_partition_drop_bug2', 'the_only_replica') PARTITION BY toYYYYMM(d) PRIMARY KEY (d, s) ORDER BY (d, s) SAMPLE BY s SETTINGS index_granularity = 8192
engine_full:                ReplicatedMergeTree('/test/test_partition_drop_bug2', 'the_only_replica') PARTITION BY toYYYYMM(d) PRIMARY KEY (d, s) ORDER BY (d, s) SAMPLE BY s SETTINGS index_granularity = 8192
partition_key:              toYYYYMM(d)
sorting_key:                d, s
primary_key:                d, s
sampling_key:               s
storage_policy:             default

Таблица содержит некоторые некорректные данные

SELECT *
FROM test_partition_drop_bug2

┌──────────d─┬─s────────────┐
│ 0000-00-00 │ sample_by_me │
└────────────┴──────────────┘
┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

Дропаем партицию с некорректными данными:

ALTER TABLE test_partition_drop_bug2
    DROP PARTITION 197001


Ok.

SELECT *
FROM test_partition_drop_bug2

┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

1 rows in set. Elapsed: 0.002 sec. 

НО с такой же таблицей созданной в старом синтаксисе это не работает!

Row 1:
──────
database:                   default
name:                       test_partition_drop_bug1
engine:                     ReplicatedMergeTree
is_temporary:               0
data_paths:                 ['/data/clickhouse/data/default/test_partition_drop_bug1/']
metadata_path:              /data/clickhouse/metadata/default/test_partition_drop_bug1.sql
metadata_modification_time: 2020-08-31 11:45:09
dependencies_database:      []
dependencies_table:         []
create_table_query:         CREATE TABLE default.test_partition_drop_bug1 (`d` Date, `s` String) ENGINE = ReplicatedMergeTree('/test/test_partition_drop_bug', 'the_only_replica', d, s, (d, s), 8192)
engine_full:                ReplicatedMergeTree('/test/test_partition_drop_bug', 'the_only_replica', d, s, (d, s), 8192)
partition_key:              toYYYYMM(d)
sorting_key:                d, s
primary_key:                d, s
sampling_key:               s
storage_policy:             default

ALTER TABLE test_partition_drop_bug1
    DROP PARTITION 197001


Ok.

SELECT *
FROM test_partition_drop_bug1

┌──────────d─┬─s────────────┐
│ 0000-00-00 │ sample_by_me │
└────────────┴──────────────┘
┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

2 rows in set. Elapsed: 0.001 sec.

Читайте https://clickhouse.tech/docs/en/engines/table-engines/special/merge/

спасибо!

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

Иначе неясно, зачем вам думать о том как кх итерирует по записям.

ну я спрашиваю, потому что думаю, срисовывать мерджтри или он не подойдет для моего таска, всего то. Но видимо мне ближе lsm всё таки

все равно неясно. МТ в КХ и ЛСМ отличаются только тем что в ЛСМ есть мемтейбл/лог чтоб вставлять мелкими строками. Т.е. МТ - урезанный ЛСМ

Row 2:
──────
database:                   default
name:                       test_partition_drop_bug2
engine:                     ReplicatedMergeTree
is_temporary:               0
data_paths:                 ['/data/clickhouse/data/default/test_partition_drop_bug2/']
metadata_path:              /data/clickhouse/metadata/default/test_partition_drop_bug2.sql
metadata_modification_time: 2020-08-31 12:12:08
dependencies_database:      []
dependencies_table:         []
create_table_query:         CREATE TABLE default.test_partition_drop_bug2 (`d` Date, `s` String) ENGINE = ReplicatedMergeTree('/test/test_partition_drop_bug2', 'the_only_replica') PARTITION BY toYYYYMM(d) PRIMARY KEY (d, s) ORDER BY (d, s) SAMPLE BY s SETTINGS index_granularity = 8192
engine_full:                ReplicatedMergeTree('/test/test_partition_drop_bug2', 'the_only_replica') PARTITION BY toYYYYMM(d) PRIMARY KEY (d, s) ORDER BY (d, s) SAMPLE BY s SETTINGS index_granularity = 8192
partition_key:              toYYYYMM(d)
sorting_key:                d, s
primary_key:                d, s
sampling_key:               s
storage_policy:             default

SELECT *
FROM test_partition_drop_bug2

┌──────────d─┬─s────────────┐
│ 0000-00-00 │ sample_by_me │
└────────────┴──────────────┘
┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

ALTER TABLE test_partition_drop_bug2
    DROP PARTITION 197001


Ok.

SELECT *
FROM test_partition_drop_bug2

┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

1 rows in set. Elapsed: 0.002 sec. 

Row 1:
──────
database:                   default
name:                       test_partition_drop_bug1
engine:                     ReplicatedMergeTree
is_temporary:               0
data_paths:                 ['/data/clickhouse/data/default/test_partition_drop_bug1/']
metadata_path:              /data/clickhouse/metadata/default/test_partition_drop_bug1.sql
metadata_modification_time: 2020-08-31 11:45:09
dependencies_database:      []
dependencies_table:         []
create_table_query:         CREATE TABLE default.test_partition_drop_bug1 (`d` Date, `s` String) ENGINE = ReplicatedMergeTree('/test/test_partition_drop_bug', 'the_only_replica', d, s, (d, s), 8192)
engine_full:                ReplicatedMergeTree('/test/test_partition_drop_bug', 'the_only_replica', d, s, (d, s), 8192)
partition_key:              toYYYYMM(d)
sorting_key:                d, s
primary_key:                d, s
sampling_key:               s
storage_policy:             default

ALTER TABLE test_partition_drop_bug1
    DROP PARTITION 197001


Ok.

SELECT *
FROM test_partition_drop_bug1

┌──────────d─┬─s────────────┐
│ 0000-00-00 │ sample_by_me │
└────────────┴──────────────┘
┌──────────d─┬─s────────────┐
│ 2020-08-31 │ sample_by_me │
└────────────┴──────────────┘

2 rows in set. Elapsed: 0.001 sec.

DROP PARTITION работает в фоне. вы ждали? если да, надо сравнивать логи/открывать баг. У нас вон было, что DROP PARTITION совсем ничего не делал пока детач-аттач таблицы не сделали

Привет. Можно ли одну таблицу физически хранить на двух block-storage средствами КХ? Или лучше так не делать?

так я же объясняю. Мы смотрим с разных позиций. Я не про результат запроса, а про работу внутреннего экзекьютера. Экзекьютер в MT не может по идее ходить по полностью отсортированному датасету, тк он раскидан на партициям и частям. Для этого ему нужно сортировать датасет в риалтайме, что очень дорого (и не нужно для 99% кейсов!). А LSM это делает как раз, сортирует вообще весь сет сразу же по PK.

это не имеет отношение к МТ или ЛСМ. То что КХ после определенного размера перестает мерджить - это дизайн решение и оптимизация. Вам никто не мешает мерджить до того пока останется один файл и ходить по нему одним потоком.
будет тоже самое.

можно и иногда нужно
https://altinity.com/blog/2019/11/27/amplifying-clickhouse-capacity-with-multi-volume-storage-part-1

Логично, но я предположил, что такой мердж либо невозможен, либо будет очень и очень дорогим. И будет всё дороже с учеличением данных, ведь парт каждый раз полностью копируется, а тут на каждую вставку будет перелопачивается, например, 1B строк. Так как данных для мерджа будет всё больше и больше. И я первым вопросом как раз спрашивал про лимиты на parts.

Видимо, это трейдоф такой

точно так же будет в ЛСМ при compaction.
и там и там все это перелопатиться и перезапишеться.

МТ = ЛСМ - оптимизация мелких вставок + "электрификация всей страны"

бейте на партиции по группам юзеров и все

но в рекомендациях стоит лимит на 1к партиций 😉

группам юзеров

будет странно, если со врееменем насоздаётся 100млн партиций