сам по себе изначально по 10-15 сек выполняется. Получается он при каждом инсерте в таблицы, откуда селект выполняется, будет выполнятся снова. Правильно я понимаю?
Запрос в MV выполняется не над всей таблицей, а только над вставляемым куском данных. Но да, каждый раз.
MV это AFTER INSERT TRIGGER который вещается на "таблицы" таблицы которые ты указываешь как SELECT ... FROM ... в SELECT для MV там будет браться не все данные всех таблиц, а только какая то одна в которую пришел INSERT и работать этот SELECT будет только с куском данных а не со всей таблицей то есть делать MV в котором JOIN и куча других тоже изменяющихся таблиц, так себе идея делать MV над 1й таблицей + dictGet из словарей, уже лучше делать MV + JOIN на неизменяемые таблицы, тоже норм. но сильно зависит от скорости JOIN
Вообще идея в том что у нас сейчас есть таблицы, куда семплы пишутся каждую минуту. Хотел просто аггрегацию семплов по суткам сделать и писать в отдельную таблицу, что бы потом оттуда данные брать по датам быстренько, а не шерстить 1440*30*N записей когда нужно за месяц данные собрать. Получается всё равно проще раз в сутки по расписанию делать чтение и запись в эту таблицу данных за последние сутки чем делать MV =\
Можете с помощью MV копировать данные в другую таблицу с движком AggregationMergeTree, где они фоном будут агрегироваться по дате, например.
Звучит как план. Если MV будет туда только новые данные докидывать, то прям супер
нет 1 в 1 нормально сделайте MV, он для даунсемлинга вполне норм подходит сделайте таблицу T2 Engine=AggregationMergeTree (читайте в доке как) сделайте CREATE MATERIALIZED VIEW MV TO T2 ... SELECT ... FROM T1 ... GROUP BY ... получите искомый даунсемлинг но запросы из таблицы T2 все равно делайте с GROUP BY
Обсуждают сегодня