автовакуум не справляется с блоатингом. Что делать ?
Гуглить
Вручную чистить за автовакуум
Хммм... Выставить old_snaphot_threshold в конфиге поменьше, это первое, что в голову приходит (на ноль!😁) Можно еще сделать псевдоапдейт, чтобы строки стали доступны vacuum, но как делать не помню
создать тикет в соответствующий отдел?
Первый ответ, который в голову пришёл - нанять нового архитектора вместо того, кто спроектировал такой OLTP)))
да что значит спроектировал такой олтп. Было оно и было, пришла нагрузка
Ну просто нафига в 2к23 делать апдейты и делиты вообще Писать всё аппенд-онли, старые строки сливать в холодное хранилище раз в неделю И если возникает жёсткий блоат, надо смотреть почему HOT-update не работает, фиксить индексацию Да и вообще автовакуум и не должен с блоатом бороться, у него совсем другая задача (обновление карт, фриз xid). Он может только крайние страницы обрезать, если они будут полностью пустыми. От bloat только vacuum full/cluster спасают, а не vacuum/autovacuum
ну вот стоит задача - последний статус у заказа выявлять. вводные - исторических данных 10 мильярдов в день, уникальных заказов 100 мильёнов в день. всего за год заказов - 30 лярдов. и нужно отчёт в котором за 5 лет по номеру пачки заказов (1000 штук) вывести в эксельку последний статус. будешь поднимать из холодного хранения 15 триллиарда записей и по ним выяснять оконками последнюю запись по 1000 заказов? или же возьмёшь подготовленную витринку на 150 лярдов, которая делит/инсертом каждый день обрабатывалась и уже хранит последнюю запись?
Ну если выбор стоит между расчётом тяжёлой агрегации / оконки и костылями вокруг вакуума продовой БД, то я бы выбрал первое)) Надо оценить сколько таких сценариев для витрин есть и как часто аналитики выдумывают новые формы отчётов. Может вместе со сливом данных в холодное хранилище стоит оставлять в БД какие-то кубы с агрегированной статистикой. Или реплицировать в Clickhouse, чтобы аналитики там сами считали нужные агргегации на миллиарды строк на лету.
это и делается. но главное - что эта витринка - всего лишь одна из 10 джоин витринок, которые используются для отчёта. Потому клик - как промежуточное решение последнего статуса, всё равно эти последние статусы нужны на транзакционной БД в которой джоины не занимают всю свободную оперативную память (или не носилуют в усмерть диск)
Обсуждают сегодня