Postgres - один гигантский стол против 10k + отдельные столы - разбиение на разделы

Question

За последние 2 года мы опробовали множество различных механизмов и стилей баз данных, чтобы решить конкретную проблему, которая требует как функций пакетов NoSQL, так и RDBMS. Мы остановились на RDBMS и Postgres.

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

One Giant против множества малых - это аргумент, который проторенный, но мой вопрос касается эффективности на скромном аппаратном обеспечении в масштабе (скромное аппаратное обеспечение, начинающееся на маленьком Linux-VPS, становится все больше и больше по мере роста спроса).

У нас есть одна таблица (5 столбцов, 2 индекса (1 трехсторонний индекс)), которая легко превысит 1 млрд строк. Если вместо этого мы скажем, что 10 (или даже 100 тыс.) Таблиц приведут к размыванию ресурсов сервера, то есть не все ли индексы будут в состоянии удерживаться в оперативной памяти из-за количества таблиц сдвига? Если данные разделены, то почти все 10k-таблицы будут считываться / записываться, поэтому конкретной активной таблицы как таковой нет.

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

Итак, мой вопрос: «При ограниченных ресурсах Postgres становится неэффективным, когда данные разбиты на одну таблицу или разбиты на несколько таблиц. Есть ли эффективность, которую можно получить, имея только один индекс таблицы и почти все деятельность сосредоточена вокруг конца таблицы. "

Answer 1

Не похоже, что вы получите много пользы от разбиения. Если вы идете за борт и делаете 10k разделов, вы можете ожидать много накладных расходов. Даже если вы сделаете что-то более разумное, например, 100 разделов, если вы используете триггеры для направления кортежей на правильный раздел, это все равно будет сопряжено с большими затратами. Но разделение индекса не должно быть большой проблемой с точки зрения размещения данных в оперативной памяти. Совокупный объем данных будет практически одинаковым независимо от того, разделен он или нет.

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

• Вы (или работники автоочистки) можете пылесосить каждую перегородку отдельно. В отличие от одной гигантской таблицы, это может происходить параллельно на перегородках. И если в сериале, у вас все еще есть преимущество, что есть отдельные куски, в которых прогресс может быть достигнут окончательно. Если вакуум таблицы прерывается до завершения, например, из-за технического обслуживания системы, он теряет большую часть выполненной работы и нуждается в повторении; это может быть серьезной проблемой для гигантских таблиц.
• Если вам нужно добавить индекс, вы можете добавить его в разные разделы параллельно. Или вы можете добавить их серийно, но с большим количеством небольших окон обслуживания, а не с одним огромным окном обслуживания.
• Если вам нужно переиндексировать (например, для устранения раздувания индекса) то же преимущество, что и при добавлении индексов.
• Вы можете переносить разделы в разные табличные пространства, если вам нужно добавить хранилище, но вы не можете выполнить онлайн-расширение своего RAID. Хотя вы, вероятно, могли бы также добавить раздел в другом табличном пространстве к ранее неразделенной таблице, так что это может быть не таким уж большим преимуществом.