Правильная замена UPDATE'ам

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

Привет! Столкнулся с проблемой обновления некоторых записей. Читал про CollapsingMergeTree, но не могу понять следующее: возможно ли обновить только один столбец, а остальные данные оставить старыми?

Например, есть таблица, которая выгружается из аппметрики:

update_date, device_id, os_name, app_name, user_property_1, user_property_2, user_property_3

первые три строки постоянны и являются ключом, остальные изменяются (и поскольку данные собираются за день, то могут измениться как 1 поле, так и все 3).  Возможно как-то обновить поля именно с такой структурой?

Пока есть идея с добавлением промежуточной таблицы со следующими полями и движком ReplacedMergeTree:

update_date, device_id, os_name, app_name, user_property_name, user_property_value

из которой в дальнейшем будет собираться первая таблица.

Еще один момент не понял: у CollapsingMergeTree есть поле sign, его необходимо вручную изменять перед новым insert'ом на -1 или это происходит автоматически?

[man...@gmail.com]

CollapsingMergeTree довольно сложно использовать и он подходит лишь для специфических случаев.
Он подходит тогда, когда при обновлении данных, вы каким-либо образом, знаете одновременно старое и новое состояние.
Например, если для вычисления обновлений данных, используется какая-то структура данных, внешняя по отношению к ClickHouse:
- из неё "приходят" обновления и вставляются в таблицу типа CollapsingMergeTree в ClickHouse.

С ReplacingMergeTree думаю, будет проще работать в вашем случае. Но следует иметь ввиду, что он всё-равно не даёт честных апдейтов. Посмотрите ответы в темах, поискав по слову "ReplacingMergeTree".

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

Спасибо!

пятница, 21 октября 2016 г., 2:46:13 UTC+3 пользователь man...@gmail.com написал:

[Андрей Хубутия]

Но следует иметь ввиду, что он всё-равно не даёт честных апдейтов. 

Интересно, что понимается под "честными апдейтами"? Это когда изменения вносятся без задержки неизбежной для columnar-баз? Если да, верно ли, что эти задержки - главная причина по которой Яндекс не советует применять ClickHouse для OLTP?

Вопрос продиктован желанием выяснить где грань за которой ClickHouse совершенно невозможно применять для оперативного учета. Есть мысль, что в сферах OLTP где скорость и оперативность не столь критичны (допустим, для обеспечения всяких пользовательских калькуляций на сайтах) колоночные таблицы (с типом MergeTree) вполне могут заменить стандартные реляционные базы. Это заблуждение?

...А так хочется, хотя бы в ряде случаев, избавиться от двух СУБД. Не зря ведь в этом направлении капают создатели HANA и Vertica.

[Андрей Хубутия]

Владислав, вероятно вы слыхали про графовые базы (тема semantic-web). Они реализуются с помощью кучи троек субъект-предикат-объект. Вот у вас в способе с промежуточной ReplacedMergeTree-таблицей сама по себе получилась эмуляция таких triplstor-ов:

• комбинация device_id, os_name, app_name - субъект
  
• user_property_name - предикат
  
• user_property_value - объект
  

И, в итоге, c учетом генерации первой таблицы, получился способ построения OLAP для графовых баз. Круто.

Но есть вопрос по поводу того как предполагается работать с этой первой таблицей: понятно, как ее сгенерировать в первый раз, но как потом обновлять? Перманентно пересобирать "сбоку" и подменять?

среда, 19 октября 2016 г., 17:11:08 UTC+3 пользователь Vladislav Denisov написал: