11238
Обсуждаем ClickHouse
ClickHouse/ClickHouse tagged: v25.8.12.129-lts
Link: https://github.com/ClickHouse/ClickHouse/releases/tag/v25.8.12.129-lts
Release notes:
Release v25.8.12.129-ltsЧитать полностью…
плюс стоит учесть ретраи, если они у вас есть
Читать полностью…
• Если internal_replication = true, при вставке в Distributed выбирается одна живая реплика шарда, туда пишутся данные, а дальше уже репликация делает Replicated*MergeTree.
• Если internal_replication = false (значение по умолчанию), Distributed сам пишет данные на все реплики шарда, и согласованность между ними не проверяется.
еще может быть async_insert без включённой дедупликации
Читать полностью…
еще дубликация у вас может быть на ретраях
смотрите
deduplicate_blocks_in_dependent_materialized_views
например
internal_replication = false (по умолчанию) — Distributed сам дублирует вставку на все реплики шарда, и их согласованность никем не контролируется, что как раз может приводить к расхождениям и дубликатам
https://clickhouse.com/docs/engines/table-engines/special/distributed#distributed-writing-data
Да, я его скинул. Вы про целевую таблицу куда вьюха вставляет, или дистрибьютед откуда читает?
Читать полностью…
ENGINE = Distributed(cluster, database, table[, sharding_key[, policy_name]])
вот тут есть ключ шардирования
то есть все же шарды?
и какой ключ шардирования?
по идее дистриб должен вставлять на одну реплику. Так что в теории вьюха должна срабатывать один раз на вставку. там точно не две вьюхи случайно повесились на одну таблицу или на дистриб и таблицу?
Читать полностью…
Есть у кого-то мысль что я делаю не так?
Читать полностью…
CREATE MATERIALIZED VIEW db.my_view ON CLUSTER 'my_cluster'Читать полностью…
TO db.my_agg_table
AS SELECT
a,
b,
c
FROM db.my_other_table -- if here use my_other_table_all (_all is Distributed, everything works fine)
GROUP BY ALL;
Когда вьюха смотрит на Distributed Table, то переносит данные без дублей. Когда вьюха смотрит на физическую (хотел, чтобы данные по сети не гуляли), получаю 2 строки (итого х2 данных) в своей ReplicatedAggregatingMergeTree таблице.
Читать полностью…
Да, я уже почитал, к счастью на проде стояло true, я уже подумал что мы данные дублируем.
Читать полностью…
соответственно если сам пишет = вставляет во все реплики = срабатывает MV на всех репликах и задваивает
Читать полностью…
internal_replication у меня не прописано, на проде у нас стоит true. подозреваю что дело в этом
да, есть данные, они вставляются в 4 таблицы, по итогу я хочу собрать из тех 4 в одну аггрегацию по дням.
Читать полностью…
это как? вы пишите в одну дистрибуционную а читаете из другой?
Читать полностью…
Вставляет в rand(), читает из intHash64(some_field)
Я вставляю всего одну строку, но в табличке с Aggregate вижу две записи (которые в конце концов схлопываются в одну строку с х2 данных)
Читать полностью…
вопроса не понял, конфиг такой
<shard>
<replica>
<host>clickhouse01</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse02</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>clickhouse03</host>
<port>9000</port>
</replica>
<replica>
<host>clickhouse04</host>
<port>9000</port>
</replica>
</shard>
intHash64(some_field)
Читать полностью…
а как связана Дистрибьютед с репликами?
Дистрибуцию обычно делают поверх шардов.
Можно и поверх нод являющихся репликами, но так вы просто дублируете операции вставки
Вставляю я всегда на одну (через Distributed), только вот результат разный, как будто вьюха вешается на обе реплики, и срабатывает дважды, на каждом сервере, у меня как раз 2 реплики в шарде.
Читать полностью…
Флоу с проблемой такой:
-> Insert into distributed -> Distributed Inserts to physical -> View reads from physical, inserts to physical -> Read from distributed, got x2 rows and x2 data
Читать полностью…
-> (Insert into distributed -> Distributed Inserts to physical) -> View reads from distributed, inserts to physical -> Read from distributed, got correct rows count and data
вообщем где был инсерт, на той реплике и MV сработает
Читать полностью…