Производительность postgresql с большим количеством таблиц (EG: 1 миллион таблиц)?

Question

Каково максимальное количество таблиц, которые могут находиться в одной базе данных pgsql, сохраняя при этом хорошую производительность, учитывая, что pgsql хранит 1 файл в таблице в файловой системе и ищет pg_catalog для каждого запроса для планирования запросов?

EG: Может ли pgsql иметь дело с 1 миллионом таблиц в одной базе данных? Предположим, что используемая файловая система - ext4, и каждая таблица содержит очень мало данных, поэтому размер хранилища избыточного диска не является проблемой. Проблема действительно возникает из (1) влияния наличия 1 миллиона файлов в файловой системе и (2) влияния наличия 1 миллиона записей в pg_catalog.

Из этой нити (2005), http://postgresql.1045698.n5.nabble.com/GENERAL-Maximum-number-of-tables-per-database-and-slowness-td1853836.html - сказано ниже (но я не знаю, как много это все еще применяется в эти дни):

Benjamin Arai писал:

Что такое текущее максимальное количество таблиц на базу данных? Кроме того, имеет ли больше таблиц, замедляющих производительность?

Для большинства случаев ответ отрицательный. Однако, как только вы приближаетесь к 6 цифрам , pg_catalog заканчивается довольно массивным. Проблема заключается в том, что планировщик запросов должен проверить pg_catalog для каждого запроса, чтобы узнать, какие индексы доступны для , каковы статистические данные &, и т. Д., Чтобы построить оптимальный план. В какой-то момент действительно большой pg_catalog может начать болеть вашу систему.

...

Уильям Ю. < [скрытый адрес электронной почты]> пишет:

Benjamin Arai писал:

Каково текущее максимальное количество таблиц в базе данных? Кроме того, имеет ли больше таблиц, замедляющих производительность?

Для большинства случаев ответ отрицательный. Однако, как только вы приближаетесь к 6 цифрам , pg_catalog заканчивается довольно массивным.

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

Answer 1

Вам не нужно хранить миллион файлов в одном каталоге. Вы можете использовать CREATE TABLESPACE для размещения места в другом каталоге или на другом диске. Я ничего не знаю о внутренних элементах pg_catalog, но могу представить, как это может сузить поиск по табличному пространству, что может значительно сократить время поиска.

Но это отличается от возможных проблем с наличием миллиона файлов в файловой системе в целом или с фактическими (не предполагаемыми) проблемами с pg_catalog.

Должно быть легко сделать простой (возможно, вводящий в заблуждение) тест. Используйте свой любимый язык сценариев для создания миллиона таблиц, каждый из которых имеет пять или шесть столбцов.

Answer 2

Этот номер и этот номер question, включая комментарии, проливают свет на эту проблему.

Чтобы ответить на ваш вопрос: это зависит от части «в то же время сохраняя хорошую производительность». Что вы ровно считают «все еще хорошей работой»? А с ровно какая рабочая нагрузка?

Позвольте мне перефразировать ваш вопрос: Сколько зубной боли может выдержать человек? Тот же ответ!

Но в обоих случаях вопрос действительный вопрос: Почему вы действительно заботитесь? Лучшим решением в обоих случаях является принятие мер по устранению причины и переход в безболезненное состояние как можно скорее.

Answer 3

В целом, по словам тех, кого я знаю о том, кто использовал очень большое количество таблиц (в тысячах), накладные расходы на планирование растут по мере увеличения количества таблиц в db. Те, кого я знаю, у кого было это как проблема, должны были найти решения для этой проблемы, но не указали мне, что это за решения. Что происходит, так это планировщик базы данных, чтобы решить, как наилучшим образом выполнить запрос, нужно искать информацию на основе таблиц и столбцов, поэтому для этого требуется поиск данных в системных каталогах, которые становятся все более и более раздутыми с течением времени. Это влияет на каждый запрос во время планирования.

Основная проблема заключается в том, что при планировании вы должны учитывать данные о таблицах (требующие поиска предметов на таблицах) и столбцы и столбцы. Интересно, что pg_class имеет индекс на oid и один в relnamespace, но не один на relname, и вы не можете легко создать его. Единственными индексами в системных таблицах являются ограничения UNIQUE, поэтому я не вижу, как, кроме изменения системных каталогов (на уровне источника или предоставления вам разрешения на это), вы можете решить эту проблему.

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

Если у вас есть много таблиц, я бы посмотрел, как многие из них могут быть разбиты на другие базы данных.

tl; dr: Ожидайте проблем с производительностью с большим количеством таблиц. Ожидайте, что вы должны быть творческими, чтобы их разрешить.