Не имеет ли смысл несколько десятков разделов? - PullRequest
Новая
       14

Не имеет ли смысл несколько десятков разделов?

1 голос
/ 18 августа 2010

Я храню результаты моделирования временных рядов в PostgreSQL.Схема БД выглядит следующим образом. 

table SimulationInfo (
    simulation_id integer primary key,
    simulation_property1, 
    simulation_property2, 
    ....
)
table SimulationResult (  // The size of one row would be around 100 bytes
    simulation_id integer,
    res_date Date,
    res_value1,
    res_value2,
    ...
    res_value9,
    primary key (simulation_id, res_date)

)

Я обычно запрашиваю данные на основе Simulation_id и res_date.

Я разделил таблицу SimulationResult на 200 подстолейпо значению диапазона от simulation_id.Полностью заполненная таблица содержит 10 ~ 15 миллионов строк.В настоящее время около 70 вложенных таблиц полностью заполнены, а размер базы данных составляет более 100 ГБ.Вскоре будут заполнены все 200 под-таблиц, и когда это произойдет, мне нужно добавить больше под-таблиц.

Но я прочитал это answers , в котором говорится, что несколько десятков разделов делаютне имеет смысла.Так что мои вопросы, как показано ниже.

  1. более нескольких десятков разделов не имеет смысла?Зачем?Я проверил план выполнения на моих 200 вложенных таблицах, и он сканировал только соответствующие вложенные таблицы.Таким образом, я предположил, что больше разделов с меньшими размерами каждой вложенной таблицы должно быть лучше.

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

1 Ответ

3 голосов
/ 18 августа 2010

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

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

Проблема со слишком большим количеством разделов заключается в том, что система, например, не готова к блокировке слишком большого количества объектов. Может быть, 200 работает нормально, но не достигнет хороших результатов, когда вы достигнете тысячи и более (что звучит маловероятно, учитывая ваше описание).

Нет проблем с наличием миллиардов строк на раздел.

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

...