ReplacingMergeTree

[rasmus]

Добрый день.

Вопрос по поводу движка ReplacingMergeTree
Хотелось бы узнать возможно ли добавление некой опции для движка ReplacingMergeTree, что при вставке - если некоторые значения не были проставлены, то для них используются значения из старых данных.
А если таких нет, то дефолтные. Например:

Таблица: CREATE TABLE test ( id Int64,  value1 Int64, value2 Int64, partitionDate Date) ENGINE = ReplacingMergeTree(partitionDate, id, 8192)

Сначало вставили такие данные:
INSERT INTO test VALUES (1, 10, 20, '0000-00-00')
А потом:
INSERT INTO test (id, value) VALUES (1, 42)

Так хочется чтобы на выходе было (1, 42, 20, '0000-00-00'), а не как сейчас (1, 42, 0, '0000-00-00') после вставки.
Возможна ли реализация такой опции?
Спасибо!

[man...@gmail.com]

К сожалению, это противоречит особенностям работы MergeTree.

MergeTree сделана таким образом, что:
- вставлять данные очень легко;
- но только если во время вставки не нужно смотреть (искать по индексу, читать) существующие данные;

То есть, это делает гораздо более сложной реализацию некоторой функциональности: проверка уникальности ключа, REPLACE, upsert*.
Это связано со схемой хранения данных и устройством индекса.

Данные хранятся почти упорядоченными по первичному ключу и переупорядочиваются в фоне.
Когда данные вставляются, ключи их строк могут быть распределены совершенно нелокально среди множества существующих в таблице значений первичного ключа.
Поэтому, эффективно прочитать из таблицы множество ключей, соответствующих вставляемым строкам, при вставке невозможно - так как придётся читать много случайных мест из таблицы.

Также индекс в таблице сделан разреженным и не позволяет адресовать или проверить существование отдельных ключей в таблице.
Вместо этого он адресует лишь некоторые диапазоны данных. Это подходит для более-менее крупных диапазонных чтений и позволяет сделать индекс очень компактным.

* это общие замечания для систем на основе LSM-tree.
Есть всякие компромиссные способы решить эту проблему, по крайней мере:
- делать обновления данных ленивыми: через запись инструкций на обновление и их мердж при чтении, что замедляет работу чтения;
- побольше буферизовать обновляемые данные в оперативке.
В ClickHouse эти способы не используются.

[man...@gmail.com]

понедельник, 19 сентября 2016 г., 21:24:23 UTC+3 пользователь Ivan Ladelschikov написал:

Тот же вопрос можно задать и про CollapsingMergeTree:

CollapsingMergeTree довольно сложна для использования. Смотрите здесь:
https://groups.google.com/d/msg/clickhouse/VixyOUD-K68/Km8EpkCyAQAJ

Смысл в том, что для нормального использования, при обновлении данных, вы должны каким-то образом самостоятельно знать старые значения обновляемых строк
- не вычитывать их из ClickHouse, а иметь в рамках какой-то другой программы, которая эти обновления готовит.

[Владислав Денисов]

Можете подсказать, как работают обновления для ReplacingMergeTree?

Есть тестовая таблица, которая последний раз обновлялась несколько дней назад:

:) select count(*) from table

┌─count()─┐

│ 2514189 │

└─────────┘

:) select count(*) from table FINAL

┌─count()─┐

│ 2110581 │

└─────────┘

:) optimize table analytics.apps_users

:) select count(*) from table

┌─count()─┐

│ 2514189 │

└─────────┘

Возможно ли настроить автоматическое схлопывание данных, чтобы получать их без добавления FINAL в запрос?

среда, 21 сентября 2016 г., 0:16:05 UTC+3 пользователь man...@gmail.com написал:

[man...@gmail.com]

Такой настройки нет.