11016
Обсуждаем ClickHouse
А что вы называете дублированием? Воспроизведите на fiddle
Читать полностью…
Кстати, реализация из документации, тоже дублирует данные
Читать полностью…
Такое поведение начинается, только если добавить TO table.
Поэтому, немного оздачен
чудес не бывает
представления у вас смотрят на разные таблицы
может быть есть между ними еще какое-то взаимодействие
после восстановления вы используете DELETE или ALTER TABLE ... DELETE / UPDATE?
такого раньше не было. как это интерпретировать и как с этим бороться?
ps: из system.replication_queue данные все те же. если это ошибка репликации, как можно почистить журнал?
Поиск по названию движка Join дает море ненужных ссылок 😞
Могли бы назвать его JoinEngine - все было бы норм
опять не понял зачем
вы же опять по сути параметр пытаетесть сделать
CTE в клике - это просто include
Вы не получаете никакого профита от запроса в WITH кроме читаемости
-- Code: 47. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: Unknown expression identifier `foo` in scope SELECT foo FROM test.ttable. (UNKNOWN_IDENTIFIER)
и однажды вы захотите a,b, sum(sc) и придется вносить правки и в представление и в клиентах
Читать полностью…
Нет, не ReplicatedMergeTree. Сайчас мотор Log, меняю на мотор S3 https://clickhouse.com/docs/en/engines/table-engines/integrations/s3
Для ReplicatedMergeTree данные очень маленькие и переписываются начисто каждый день. И старые неактуальные данные хранить не нужно
У нас куча маленьких Log таблиц, которые регулярно начисто переписываются и читаются в трех кластерах. То есть одни и те же данные нужны для чтения в трех кластерах.
S3 движок спонтанно очень удобно. Один insert в любом кластере на одной реплике и данные доступны во всех кластерах
Мне ещё важно чтобы на стороне клиентов ничего не нужно было менять (название базы и таблицы).
Можно было бы сделать view и указывать им на новую atomic базу и S3 таблицу (newdb.target-table).
В той же базе S3 таблица newdb.tmp.
В newdb.tmp truncate-insert, затем Exchange и tmp становится target
Недостаток правда дополнительная логика и exchange придется на каждом кластере выполнять
Сделайте партиционирование по дням (достаточно по дню недели, например),
никогда не удаляйте записи явно, настройте TTL,
вставляйте с указанием следующего дня недели,
выбирайте с указанием текущего дня недели (для этого можно использовать view).
Например.
Или сконвертируйте базу в Atomic ;)
https://clickhouse.com/docs/en/guides/developer/cascading-materialized-views#combining-multiple-source-tables-to-single-target-table
Повторить все шаги, и данные в 2 представлениях будут дублировать данные друг друга, даже если указаны разные таблицы
Ну без to оно у вас будет писаться в inner таблицу, и эти таблицы для двух MV будут разные
Читать полностью…
Все взаимодействие показано на запросе.
Больше никак не взаимодействуют
Нет, в этом и интерес, что, 2 представления начинают дублировать данные друг друга идентично.
Они никак не отличаются
возможно у вас дублируются записи в источниках
Читать полностью…
Я пытаюсь убрать бойлерплейт из запросов, разные способы ищу
Читать полностью…
ну и да, если вам нужны параметры для вычислений, например задаете разные коэфициенты, то да, если это нельзя вытащить наверх, то это место для параметров
Читать полностью…
Привет.Набираю людей в команду,дocтoйный еженедельный зapaбoтoк.Удалённое сотрудничесто.Отправляй мне плюс в личные и я скину всю необходимую информацию.
Читать полностью…
эх если бы view являлось подзапросом на столько, что могло захватывать наружний скоуп без проброса в параметре.............
типа
create view
select foo .......
;
with 1 as foo
select ... from view
Да, понял, пардон.
Так можно, и предостережение "с s3 таблицами не стоит так вольно играться" к такой схеме не относится, можно играться ;)
Либо вы ошибаетесь, либо я вас неправильно понимаю.
Мы говорим про ReplictedMergeTree в storage s3?
У вас есть 3 кластера CH.
Вы считаете, что поместив данные в одном из них в такую таблицу, сможете прочесть во всех кластерах?
Это не так.
Возможно, это верно для s3_plain, но я мало чего про него знаю.
И, что более существенно, s3 для этого не нужен.
Канонический способ решения такой задачи - описать дополнительный кластер, в который будут входить все узлы трех ваших "настоящих" кластеров и использовать ReplicatedMergeTree.
Да, все верно.
Но вообще-то с s3 таблицами не стоит так вольно играться.
Зачем оно вам вообще? Вы хотя бы 0copy в s3 не планируете использовать? [лучше не планируйте]
Я бы не решился так делать.
rename для реплицированной s3 таблицы в неAtomic базе ...
Фиг знает, чем это отольется.
Спасибо Илья, идея хорошая, но там база не типа Atomic.
Для Exchange требуется тип базы Atomic