Блог

Я разбиваю очень большую таблицу, содержащую временные данные, и рассматриваю, с какой степенью детализации я должен создавать разделы. В документации по разделам Postgres утверждается, что «большое количество разделов, вероятно, значительно увеличит время планирования запроса», и рекомендуется использовать разделение с разделами «возможно, до сотни».

Предполагая, что моя таблица содержит данные за десять лет, если я разделю по неделям, у меня получится более 500 разделов. Прежде чем я исключу это, я хотел бы лучше понять, какое влияние оказывает количество разделов на время планирования запроса. Кто-нибудь проводил сравнительный анализ этого, или у кого-нибудь есть понимание того, как это работает внутри?

Планировщик запросов должен выполнить линейный поиск информации об ограничениях для каждого раздела таблиц, используемых в запросе, чтобы выяснить, какие из них действительно задействованы — те, в которых могут быть строки, необходимые для запрашиваемых данных. Количество планов запросов, учитываемых планировщиком, растет экспоненциально по мере объединения большего количества таблиц. Таким образом, точное место, где линейный поиск занимает достаточно времени, чтобы вызвать беспокойство, действительно зависит от сложности запроса. Чем больше объединений, тем хуже вы пострадаете от этого. Цифра «до ста» была получена из-за того, что время планирования запроса составляло нетривиальное количество времени даже для более простых запросов на этом этапе. В частности, в веб-приложениях, где важна задержка времени отклика, это проблема; отсюда и предупреждение.

Можете ли вы поддерживать 500? Конечно. Но вам придется выполнять поиск по каждому из 500 контрольных ограничений для каждого плана запроса, включающего эту таблицу, рассмотренную оптимизатором. Если время планирования запроса вас не беспокоит, то, возможно, вам все равно. Но большинству сайтов в конечном итоге не нравится доля времени, затрачиваемая на планирование запросов с таким количеством разделов, что является одной из причин, по которой ежемесячное разделение является стандартом для большинства наборов данных. Вы можете легко хранить данные за 10 лет, разделяя их ежемесячно, прежде чем начнете переходить к тому, что накладные расходы на планирование начинают быть заметными.

«большое количество разделов, вероятно, значительно увеличит время планирования запроса» и рекомендует использовать разделение «возможно, до сотни» разделов.

Потому что каждый дополнительный раздел обычно будет привязан к контрольным ограничениям, и это заставит планировщика задуматься, к какому из разделов нужно выполнить запрос. В лучшем случае планировщик определяет, что вы обращаетесь только к одному разделу, и полностью удаляет append шаг.

Что касается строк, и, как указали DNS и Seth, ваш пробег будет зависеть от оборудования. Однако, вообще говоря, нет существенной разницы между запросами к таблице размером 1 МЛН строк и к таблице размером 10 МЛН строк — особенно если ваши жесткие диски обеспечивают быстрый произвольный доступ и если они кластеризованы (см. cluster Инструкцию) с использованием индекса, который вы чаще всего посещаете.

Каждый раздел таблицы занимает индекс в файловой системе. «Очень большой» — это относительный термин, который зависит от характеристик производительности выбранной вами файловой системы. Если вам нужны четкие тесты производительности, вы, вероятно, могли бы посмотреть различные тесты производительности почтовых систем из выбранной вами ОС и FS. Вообще говоря, я бы не беспокоился об этом, пока вы не доберетесь до десятков тысяч или сотен тысяч табличных пространств (использование dirhash в UFS2 от FreeBSD было бы выигрышным). Также обратите внимание, что это же ограничение применяется к БАЗАМ ДАННЫХ, ТАБЛИЦАМ или любому другому объекту базы данных, поддерживаемому файловой системой в PostgreSQL.

Если вы не хотите доверять разработчикам PostgreSQL, которые написали код, то я рекомендую вам просто попробовать это самостоятельно и выполнить несколько примеров запросов с объяснением, анализом и временем их выполнения с использованием разных схем разделения. Ваша конкретная конфигурация аппаратного и программного обеспечения, вероятно, будет доминировать в любом ответе в любом случае.

Я предполагаю, что кэш оптимизации строк, который оптимизатор запросов использует для определения того, какие объединения и ограничения использовать, хранится в каждом разделе, поэтому ему, вероятно, необходимо загружать и считывать части каждого раздела для планирования запроса.