Максимальное (используемое) количество строк в таблице Postgresql

Question

Я понимаю, что в соответствии с Pg docs (http://www.postgresql.org/about/),) можно хранить неограниченное количество строк в таблице. Однако, каково «практическое правило» для пригодного для использования количества строк, если оно есть?

Справочная информация: я хочу хранить ежедневные показания в течение нескольких десятилетий для 13 миллионов ячеек, что составляет 13 M * (366 | 365) * 20 ~ 9,5e10 или 95 B строк (на самом деле, около 120B строк).

Итак, используя разбиение таблиц, я создал основную таблицу, а затем унаследовал таблицы по годам, что делит строки на ~ 5,2 млрд. Строк на таблицу.

Каждаястрока - 9 SMALLINTs и два INT, то есть 26 байт. Добавьте к этому служебную нагрузку Pg, равную 23 байтам на строку, и мы получим 49 байт на строку. Таким образом, каждая таблица, без какого-либо PK или любого другого индекса, будет веситьв ~ 0,25 ТБ.

Для начала я создал только подмножество вышеуказанных данных, то есть только для примерно 250000 ячеек. Я должен сделать кучу настроек (создать правильные индексы и т. д.).), но производительность действительно ужасна прямо сейчас. Кроме того, каждый раз, когда мне нужночтобы добавить больше данных, мне придется сбросить ключи и воссоздать их.Благодать спасения заключается в том, что после загрузки все станет базой данных только для чтения.

Есть предложения?Любая другая стратегия для разделения?

Answer 1

Это не просто «куча настроек (индексов и т. Д.)».Это очень важно и должно быть сделано.

Вы опубликовали несколько деталей, но давайте попробуем.

Правило таково: Попробуйте найти наиболее распространенный рабочий набор.Посмотрите, подходит ли оно в ОЗУ.Оптимизируйте оборудование, настройки буфера PG / OS и индексы PG / кластеризацию для него.В противном случае ищите агрегаты или, если это неприемлемо и вам нужен полностью произвольный доступ, подумайте, какое оборудование может сканировать всю таблицу за вас за разумное время.

Насколько велика ваша таблица (в гигабайтах)?Как это соотносится с общим объемом оперативной памяти?Каковы ваши настройки PG, включая shared_buffers иffective_cache_size?Это выделенный сервер?Если у вас таблица объемом 250 ГБ и около 10 ГБ ОЗУ, это означает, что вы можете разместить только 4% таблицы.

Существуют ли какие-либо столбцы, которые обычно используются для фильтрации, например, состояние или дата?Можете ли вы рабочий набор, который наиболее часто используется (как только в прошлом месяце)?Если это так, рассмотрите возможность разделения или кластеризации по этим столбцам и определенно их индексируйте.По сути, вы пытаетесь убедиться, что как можно больше рабочего набора помещается в ОЗУ.

Избегайте сканирования таблицы любой ценой, если она не помещается в ОЗУ.Если вам действительно нужен абсолютно произвольный доступ, то единственным способом, которым он может быть использован, является действительно сложное оборудование.Вам потребуется постоянная конфигурация хранилища / ОЗУ, которая может считывать 250 ГБ за разумное время.