S
Materialized view
При селекте вы все равно делаете аггрегацию и вам не важно схолпнклось или нет
Я бы отдельно хранил сырые данные в одной таблице с ttl или с ttl group by
И настроил MV
С аггрегацией для ускорения выборок
Size: a a a
2021 July 10
SK
Добрый день. Намереваемся использовать материализованные представления работающие как insert trigger на одной и единственной общей таблице (основной поток данных). Эти представления будут готовить данные для вставки в другие соответствующие таблицы. Есть ли какое-то ограничение на общее колличество таких материализованных представлений и таблиц. Что если их будет 1000 или 2000?
DT
Замедление инстертов
DT
Скорее всего вам не нужно 1000 вью
SK
нужно т.к. у каждого заказчика свои широкие денормализованные view [до 100 колонок максимум].
1. может как-то иначе это можно реализовать чтобы замедление инсертов сильно не сказывалось?
2. А что если иметь 2000 материализованных представлений или более просто как статиские снапшоты данных созданные через POPULATE (без использования insert triggers). На колличество таких тоже есть ограничения?
1. может как-то иначе это можно реализовать чтобы замедление инсертов сильно не сказывалось?
2. А что если иметь 2000 материализованных представлений или более просто как статиские снапшоты данных созданные через POPULATE (без использования insert triggers). На колличество таких тоже есть ограничения?
VC
Я бы такие специфичные для клиентов вещи не на уровне таблиц в кликхаусе моделировал. Такого типа настройки можно положить в обычную базу данных, и потом уже генерировать запросы на основе выбранных пользователем колонок.
DC
А что если кол-во заказчиков вырастет в 10раз? А если в 100 раз?
SK
Да. Пожалуй плохой путь :)