Обновление данных в ClickHouse

[BugM]

Clickhouse way это написать код без апдейтов с учетом eventual consistency.

Получить значения с самым свежим временем воон в той колонке? Конечно. Даже без магии с массивами можно.

select 
UserID,
max(ClientEventTime),
argMax(Duration, ClientEventTime) as lastDuration,
argMax(PageViews, ClientEventTime) as lastPageViews,
argMax(VisitID, ClientEventTime) as lastVisitID
from visits_v1
GROUP BY UserID
limit 100

И пусть движок ReplacingMergeTree спокойно чистит данные оставляя только самые свежие по ClientEventTime. Мы всегда вытащим только то что нужно.

Пример с данными отсюда https://play.clickhouse.com

[kataus]

Мутации не стоит рассматривать как усложненный аналог update. Они ни разу не транзакционные, есть риск что мерж в процессе мутации пойдёт с ошибками и тогда станет уже не весело

[pavelsc]

Чтобы это обработать, нам бы пришлось добавлять лишнюю агрегацию для каждого запроса SELECT, даже если нам не нужна информация о комментариях.

А чего не

Limit 1 By some_unique_key

Все равно ReplacingMergeTree будет быстрее чем мутация ночью.

Решение номер два. Можно же подключить внешний словарь с source, допустим, postgres и layout, например, ssd_cache. Тут конечно есть ограничение по размеру словаря, комменты или ещё какие связанные старше какого-то периода уже не отредактировать. Но опять же нам никто не мешает купить SSD дисков, 400$ за терабайт очень дёшево. Сильно дешевле чем мариновать пару сеньеров месяц на супер решение для микросервиса который будет делать селекты из кликхауса в какой-то промежуточный сторадж, программно имитировать локи для этих записей и потом делать массовую вставку записей в кликхаус обратно.

[kirillyarulin]

По поводу limit by. Когда экспериментировал с ReplacingMergeTree, честно говоря, limit 1 by в голову не пришел, но все равно есть сомнения что это поможет.

1. При этой конструкции как я понимаю агрегация все равно выполняется, только неявно. Думаю это может значительно повлиять на производительность, но это конечно бы надо проверять.

2. Не уверен, что гарантируется необходимая сортировка внутри группы. Скорее всего нужно добавлять order by, чтобы мы не отсекли нужную запись.

3. Представим, что мы просто хотим посчитать количество сообщений. В случае с ReplacingMergeTree мы не сможем написать просто select count(*) from message, нам придется написать что-то типа select count(distinct message_id) from message, что значительно медленнее первого варианта.

   Этот кейс можно протестировать на https://play.clickhouse.com/ с их тестовой таблицей. Запрос select count(*) from hits_100m_obfuscated выполняется несколько миллисекунд. select count(distinct WatchID) from hits_100m_obfuscated почти 10 секунд

По поводу словарей. С ними много не работал и, возможно, не до конца разобрался, но мне показалось что они не совсем подходят для нашей задачи.

• смутило, что хранятся в памяти

• кажется не совсем предназначены для частого обновления

• усложняется логика и поддержка с добавлением отдельной бд для словаря

Возможно, в итоге этот вариант оказался бы проще и быстрее.

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

Вот это не до конца понял:)

[AIring]

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