Насколько велика таблица PostgreSQL?

127

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

У нас есть модель, Messageкоторую необходимо сохранить. Это очень, очень маленькая модель с тремя столбцами db, кроме id, однако, когда мы перейдем к производству, вероятно, будет МНОГО этих моделей. Мы смотрим на 1000000 вставок в день. Поиск моделей будет осуществляться только по двум внешним ключам, которые можно индексировать. Кроме того, модели никогда не нужно удалять, но нам также не нужно сохранять их, когда им около трех месяцев.

Итак, нас интересует, не вызовет ли реализация этой таблицы в Postgres значительных проблем с производительностью? Есть ли у кого-нибудь опыт работы с очень большими базами данных SQL, чтобы сказать нам, будет ли это проблемой? И если да, то какую альтернативу нам выбрать?

sql ruby-on-rails performance postgresql database-design Дилан Карр
источник

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

Сэм

Связанный вопрос здесь и здесь .

Эрвин Брандштеттер

Мы обрабатываем около 30 миллионов сообщений в день в одной базе данных PostgreSQL объемом 5+ ТБ, работает нормально.

Фрэнк Хейкенс

см. также stackoverflow.com/questions/3132444/…

rogerdpack

К вашему сведению, сегодня я читал postgresql.org/about и заметил, что там написано, что (в принципе) количество строк в таблице неограничено.

Al Chou

Ответы:

115

Количество строк в таблице само по себе не будет проблемой.

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

В зависимости от распределения данных вы можете использовать сочетание индексов, отфильтрованных индексов и какого-либо вида секционирования таблиц, чтобы ускорить процесс, как только вы увидите, какие проблемы с производительностью у вас могут быть, а какие нет. Ваша проблема будет такой же в любой другой СУБД, о которой я знаю. Если вам нужно всего 3 месяца на проектирование данных в процессе, чтобы удалить данные, вам больше не нужно. Таким образом у вас будет постоянный объем данных в таблице. Вам повезло, что вы знаете, сколько данных будет существовать, проверьте его на свой объем и посмотрите, что вы получите. Тестирование одной таблицы с 90 миллионами строк может быть очень простым:

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

Kuberchaun
источник

Я согласен, что 90 миллионов строк не будут проблемой для PostgreSQL. Но это может быть проблемой для ORM с PostgreSQL. (На самом деле ORM с любыми dbms.)

Майк

@ MikeSherrill'Catcall 'Хороший замечание, я просто сосредоточился на том, "Насколько велика таблица PostgreSQL?"

Kuberchaun

@yeyo: Потому что ORM обычно используют множество запросов для получения данных, которые можно вернуть с помощью одного или двух. OP использует Ruby on Rails.

Майк Шерилл 'Cat Recall'

Это немного поздно, но я думаю, что во многих случаях (особенно с рельсами / активной записью) обычно полностью удаляют ORM из уравнения и записывают необработанную строку sql для запроса по соображениям производительности. Не позволяйте ORM принимать решения о данных за вас! Это несущественный аксессуар.

Стефан

URL-адрес about, указанный в URL-адресе, в настоящее время не показывает эти ограничения - кто-нибудь знает, куда он перемещен?

Shorn

Другой способ значительно ускорить выполнение запросов к таблице с> 100 миллионами строк - кластеризация таблицы в нерабочее время по индексу, который чаще всего используется в ваших запросах. У нас есть таблица с> 218 миллионами строк, и мы обнаружили 30-кратное улучшение.

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

Джеймс Доэрти
источник

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

шпион

Да, вот пошаговый ПРИМЕР: 1) Таблица, о которой я говорю, в этом примере называется инвестициями. 2) В запросах чаще всего используется индекс (bankid, record_date). Итак, шаг за шагом: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "создать индекс investment_bankid_rec_dt_idx для инвестиций (bankid, record_date);" 3) psql -c «кластер investment_bankid_rec_dt_idx по инвестициям»; 4) Vacuumdb -d ccbank -z -v -t investment Итак, на первом и втором шаге мы отбрасываем индекс и воссоздаем его.

Джеймс Доэрти

Шаг 3: мы создаем кластер, это в основном помещает таблицу БД в физический порядок индекса, поэтому, когда postgresql выполняет запрос, он кэширует наиболее вероятные следующие строки. Шаг 4: мы очищаем базу данных, чтобы сбросить статистику для планировщика запросов

Джеймс Доэрти