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

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

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

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

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

Во-первых, я создал только подмножество вышеуказанных данных, то есть только около 250 000 ячеек. Я должен сделать кучу настройки (создать надлежащие индексы и т.д.), Но производительность действительно ужасная прямо сейчас. Кроме того, каждый раз, когда мне нужно добавить больше данных, мне придется отказаться от ключей и их воссоздать. Благодатная экономия заключается в том, что как только все будет загружено, это будет база данных только для чтения.

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

Ответы

Ответ 1

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

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

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

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

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

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