Этот день настал, и я наконец-то поняла, что происходит с разными движками в кх 🕺
Возьмем такую конфигурацию кластера: 2 шарда по 2 реплики. И для примера 3 движка: MergeTree, ReplicatedMergeTree, Distributed
Подключаемся к 1му хосту, создаем 6 таблиц на кластере. Чтобы результаты не мешали друг другу, под Distributed создаем отдельные свежие чистые таблички:
1) MergeTree
ENGINE MergeTree()
2) ReplicatedMergeTree
ENGINE ReplicatedMergeTree()
3) Distributed поверх MergeTree
ENGINE = Distributed(local_cluster, default, mt_table, rand())
4) Distributed поверх ReplicatedMergeTree
ENGINE = Distributed(local_cluster, default, rmt_table, rand())
Каждая таблица теперь существует на каждом хосте, потому что мы создали на всем кластере. Инсертим 10к строк данных и сравним
Что получается?
🎈MergeTree
Данные хранятся только на том хосте, на котором мы заинсертили. На остальных 0
🎈ReplicatedMergeTree
Данные хранятся на всех репликах одного шарда. На остальных шардах 0
🎈Distributed
Данные вообще не хранит, они лежат в исходной таблице. В каком-то смысле это как view
Если в основе MergeTree - то данные будут на одной из реплик в шарде. В нашем случае это replica1 для shard1 и replica2 для shard2
Когда мы делаем count(), рандомно выбирается одна реплика из каждого шарда. Т.е. на нашем кластере возможны 4 комбинации:
1 + 3 = 5030 + 0 = 5030
1 + 4 = 5030 + 4970 = 10000
2 + 3 = 0 + 0 = 0
2 + 4 = 0 + 4970 = 4970
Это значит, что при каждом новом запросе, например, для хоста 3 мы можем получить либо 5030 строк, либо 0
Если в основе ReplicatedMergeTree - то между репликами будет одинаковое количество строк, но между шардами разное. А при запросе к distributed всегда будет участвовать одинаковое количество строк
🌷Поэтому если нужно получать консистентные данные, обеспечивать отказоустойчивость - используем Distributed на базе ReplicatedMergeTree и селектим из Distributed