Тогда такой вопрос. Возникла идея на базе distirbuted tables построить materialized views, данные в которых обновляются атоматически.

Нашел статью про это https://github.com/ClickHouse/ClickHouse/issues/467

Но в данном случае надо как-то избавляться от устаревших записей в MV, чтобы показывать только актуальные / последние данные: т.е. для какого-то id брать запись с max(version). Как это лучше реализовать?

ReplacingMergeTree

и писать запросы правильным способом.
Отсутствие дубликатов не гарантируется в любой момент времени.
https://kb.altinity.com/engines/mergetree-table-engine-family/replacingmergetree

Да. PostgreSQL используется как источник данных для ClickHouse, но вот возникла проблема :(

Я к тому, что в 21.5 кликхаус должен уметь сам ходить в postgresql без odbc

Правильным это каким?

Ну я скинул ссылку, там показаны разные способы

я бы не стал использовать КХ в этом случае. КХ для иммьютабл данных.
Я бы взял timescaledb. Там можно апдейтить несжатые данные

хм странно, может места нет

наоборот, мутации это особый вид мержа. Ломаются мутации по разным причинам, и вообще кто сказал что мутация выполнится например за 8 часов? Они могут работать очень долго и это ожидаемо

но в 21.5 odbc не нужен для PG? там есть движок готовый

> Я бы взял timescaledb
он плохо жмет данные и storage получается очень дорогим. clickhouse нравится наличием конфигурируемых кодеков + сжатия, пока навскидку получается в 2.5x меньше затрат на хранение по сравнению с cassandra. timescaledb в разы больше места использует. плюс поддержка ttl с перемещением в s3 позволит сократить расходы еще сильнее.

>  и вообще кто сказал что мутация выполнится например за 8 часов
наверное может, но я наивно полагал что время выполнения есть функция от колиства и размера партиций, которые надо поменять

в любом случае спасибо большое за помощь!

Можно сначала делать апдейты с tombstone колонкой, а потом раз в день удалять все
Но это немного костыль.

https://kb.altinity.com/altinity-kb-queries-and-syntax/delete-via-tombstone-column

а как работает получение списка партиций

`SELECT * FROM system.parts
WHERE active and database = '<db>'
`,

когда есть таблицы distributed? (и кластер)  Сейчас время от времени возвращается результат

в таком случае упасть не должно?

что упасть? мерж проверяет что места * 2 есть и резервирует и потом стартует

никак. system.parts  ничего не знает про кластер.

Т е при применении кластеров нельзя получить список партиций таким способом? Или это еще Distributed не закончил процесс раскидывания данных?

Есть таблица MergeTree, есть Distributed

Так после этого запроса на партиции ответ приходит через раз

create table db.table_local on cluster clickhouse1
(
  video_id String,
  publication_ts DateTime,
  version Date
) 
Engine = MergeTree() partition by version order by tuple() SETTINGS index_granularity = 8192

create table db.table on cluster clickhouse1
(
  video_id String,
  publication_ts DateTime,
  version Date
) 
Engine = Distributed(clickhouse1, db, table_local, rand())

db тоже создана ON CLUSTER

каша, какая каша.

Если вы используете инсерт в Distributed и вам нужна гарантия вставки в реальные таблицы, то просто установите insert_distributed_sync = 1

--insert_distributed_sync arg                                    If setting is enabled, insert query into distributed waits until data will be sent to all nodes in cluster.

если вы хотите увидеть сколько еще не раскидано, испольуйте system.distribution_queue

если вы хотите сделать запрос ко всем нодам, используйте from clusterAllRelicas

есть вопрос, какие обычно причины того что высокий iowait у кликхауса