причем зависимые МВ смотрят вообще говоря не на саму таблицу, а только на вставку в нее, если ты их не создаешь с использованием POPULATE, то грубо говоря плевать на те данные. что там лежат
да но мне саму таблицу, надо подменить чтоб там было правильно, и вопрос если rename не влияет на mv подписанные на неё, то тогда если я свапну ренэймам на новую и мне mv сами переделывать не надо будет?
А вот тоже вопрос в тему МВ. У меня МВ смотрит на табличку, теперь в табличку мне надо добавить ещё одно поле, ну и в МВ конечно. Это можно сделать "на горячую", пока данные валятся в табличку? Я ж правильно понимаю, что пока я буду пересоздавать МВ, часть вставленных записей в табличку не попадут в МВ?
да но мне саму таблицу, надо подменить чтоб там было правильно, и вопрос если rename не влияет на mv подписанные на неё, то тогда если я свапну ренэймам на новую и мне mv сами переделывать не надо будет?
А вот тоже вопрос в тему МВ. У меня МВ смотрит на табличку, теперь в табличку мне надо добавить ещё одно поле, ну и в МВ конечно. Это можно сделать "на горячую", пока данные валятся в табличку? Я ж правильно понимаю, что пока я буду пересоздавать МВ, часть вставленных записей в табличку не попадут в МВ?
Добрый день, бытует мнение что Join в кликхаусе лучше не использовать, так ли это? Есть ли статья/дока/видел где можно больше узнать про это - почему, как обходить, etc.
хотя наверное ерунду сказал, там же поля строго должны быть написаны
тогда у тебя данные будут вставляться, но как будто этого поля и не было.
я через clickhouse-client делал alter'ы в таблицу и таблицу m, а потом drop/create mv. Ошибок никаких не ловил. Записи, которые вставлял между drop и create mv не попадали в mv.
Добрый день, бытует мнение что Join в кликхаусе лучше не использовать, так ли это? Есть ли статья/дока/видел где можно больше узнать про это - почему, как обходить, etc.
потому что правая таблица будет сортироваться в памяти (merge join), что учитывая тенденцию к тому, что в кликхаусе таблицы могут быть миллиарды-десятки миллиардов очень больно
я через clickhouse-client делал alter'ы в таблицу и таблицу m, а потом drop/create mv. Ошибок никаких не ловил. Записи, которые вставлял между drop и create mv не попадали в mv.
потому что правая таблица будет сортироваться в памяти (merge join), что учитывая тенденцию к тому, что в кликхаусе таблицы могут быть миллиарды-десятки миллиардов очень больно
Добрый день, бытует мнение что Join в кликхаусе лучше не использовать, так ли это? Есть ли статья/дока/видел где можно больше узнать про это - почему, как обходить, etc.
Join мне кажется лучше впринцыпе избегать, при построении хранилищ данных, зачем тратить время на доп. операции...
Join мне кажется лучше впринцыпе избегать, при построении хранилищ данных, зачем тратить время на доп. операции...
Тут ситуация когда писатели в КХ разные, и в одну таблицу писать проблематично (только воротить Summing или Aggregating MergeTree) а читателю интересен репорт из >2 сущностей писателей