Postgres SQL — большое количество разделов
Я пытаюсь понять любые ограничения (точные или практические), существующие на количество разделов для одной базы данных Postgres, а также любые проблемы с производительностью, которые возникают по мере приближения к этим ограничениям. Для этого ответьте, пожалуйста, на следующие сопутствующие вопросы:
Какое максимальное общее количество разделов может содержать база данных?
Если я планирую иметь в базе данных более 10 000 разделов, стоит ли мне о чем-то беспокоиться?
Существует ли какое-либо количество разделов, в отношении которых возникают проблемы исключительно из-за большого количества разделов, и если да, то примерно в каком количестве разделов возникают эти проблемы?
@Luuk Ваша ссылка указывает на тему, которой уже 13 лет. Это очень-очень старо и устарело. В ссылке в этом разделе упоминается версия 8.3, в которой вообще не было встроенного разделения.
Ответы 2
- О
1,431,650,303. Это предел того, сколько отношений может содержать PostgreSQL, но вам нужно вычесть встроенные. Все-таки около 1,4 миллиарда. - Ничего такого, о чем вам не пришлось бы беспокоиться при подготовке к размещению 10 000 независимых столов.
- Об этом числе только предполагают в более широком контексте того, сколько отношений — это слишком много. 10 000 - это далеко не то, что предполагалось. Вот @Laurenz Albe случайно тестирует на столе с 66'000 разделами.
Лучше всего протестировать. Вы можете использовать простой цикл PL/pgSQL для создания 10 000 разделов за секунды, а затем один generate_series() может заполнить их все за секунды. После этого проведите стресс-тест с помощью pgbench и проверьте, удовлетворительна ли его производительность.
Я только что создал пустую таблицу с 10 тысячами разделов и могу подтвердить select * занимает 0.15s на ней. Это отстой, но если я подумаю о попытке выполнить длинный и странный выбор из 10 тысяч таблиц каким-то другим способом, это на самом деле впечатляюще дешево и удобно. Кроме того, глупо и дорого, если мне не нужны все эти разделы - чтобы оправдать это, шаблон доступа должен соответствовать тому, для чего предназначено разделение:
Планировщик запросов, как правило, достаточно хорошо справляется с иерархиями секций, насчитывающими до нескольких тысяч секций, при условии, что типичные запросы позволяют планировщику запросов отсекать все секции, кроме небольшого числа.
Очевидно, что безусловный select * является прямой противоположностью этому.
Если вместо этого я сгенерирую 5% уникальных 21'000'000 случайных строк, помещу их в одну обычную таблицу и одну таблицу, разделенную по диапазонам, то select * с условием, соответствующим одному разделу
- сканирование свежего индекса на обычной таблице занимает
0.8-1.05s - секционированная таблица просто возвращает соответствующий целевой раздел в
0.3s
Не ищите точных ограничений. Самая большая проблема заключается в том, что производительность будет снижаться прямо пропорционально количеству задействованных разделов. Насколько отстойно вы можете терпеть, зависит от вашего варианта использования.
Чтобы дать вам данные: однажды я создал пустую таблицу с 10 000 разделами, и выбор всех 0 строк занял 0,2 секунды. И это был тривиальный запрос.
Вы начнете страдать задолго до того, как достигнете каких-либо жестких ограничений.
Сколько разделов в родительской таблице? Или только один родительский элемент с 10 000 разделов? Что вы заметили, когда тестировали свое решение? (вы можете использовать для этого pgbench)