А есть ли здесь бородатые sql-боги?У клиента данные пишутся в 4 таблицы Test, Service_test, Device_test и Device.Все они связаны между собой полем, которое представляет собой уникальную рандомную строку. Одним из требований клиента является предоставление единого источника, где все эти таблицы связаны.Я делаю join и кладу это всё в Materialized view. Обновляю этот View раз в день.То сейчас данных стало порядка 10 миллионов строк (будет гораздо больше) и теперь мне надо это всё дело оптимизировать. Подскажите что делать?
bump
>>854861 (OP)Ну индекс на этом поле есть, я так понимаю? Просто на всякий случай спросить. EXPLAIN смотрел?
>>854952Нет. Я большой нуб. Использую postgres как прокладку между DynamoDB и Tableau.Какой индекс лучше всего строить на строках?Я вот ещё чего не могу понять: поскольку данные постоянно текут и поле ID уникальное, получается что этот индекс постоянно пересчитывается. Это нормально?
>>854861 (OP)Да похуй какая у тебя СУБД, решение этих проблем всегда одинаковое — выбираешь те данные, которые уже не будут меняться, препросчитываешь по ним нужную тебе агрегацию, хранишь её отдельно в готовом виде. Часто это предполагает заведение новой таблицы с данными каждый месяц, а старые лежат мёртвым грузом для истории ну и для внепланового-нештатного пересчёта аналитики. Само по себе кол-во строк это похуй вообще в общем случае. Можно и миллиард строк хранить втупую, разумно расставив индексы, можно и на сотнях тысяч строк без кэша сдохнуть нахуй, если требуются ёбнутые выборки и нет кучи оперативки.
Какой даун додумался произносить SQL как "сиквэл"?
>>857016много лучше сикуль
