Quanto è grande per una tabella PostgreSQL?


127

Sto lavorando alla progettazione di un progetto RoR per la mia azienda e il nostro team di sviluppo ha già avuto un piccolo dibattito sul design, in particolare sul database.

Abbiamo un modello chiamato Messageche deve essere mantenuto. È un modello molto, molto piccolo con solo tre colonne db oltre all'id, tuttavia probabilmente ci saranno MOLTI di questi modelli quando andremo in produzione. Stiamo osservando fino a 1.000.000 di inserimenti al giorno. I modelli verranno ricercati solo da due chiavi esterne che possono essere indicizzate. Inoltre, i modelli non devono mai essere eliminati, ma non dobbiamo nemmeno conservarli una volta che hanno circa tre mesi.

Quindi, quello che ci chiediamo è se l'implementazione di questa tabella in Postgres presenterà un problema di prestazioni significativo? Qualcuno ha esperienza con database SQL molto grandi per dirci se questo sarà o meno un problema? E se è così, con quale alternativa dovremmo andare?


3
con un buon livello di cache e qualche piccola configurazione in PG dovresti stare bene. Dovresti affrontare i problemi di prestazioni caso per caso ed evitare la preottimizzazione. Detto questo, il partizionamento e la replica sono sempre ottime opzioni che puoi sfruttare una volta che hai raggiunto i colli di bottiglia.
Sam

1
Domanda correlata qui e qui .
Erwin Brandstetter

5
Elaboriamo circa 30 milioni di messaggi al giorno in un database PostgreSQL da 5+ TB, funziona bene.
Frank Heikens


1
Cordiali saluti, mi è capitato di leggere postgresql.org/about oggi e ho notato che dice che (in linea di principio) il numero di righe in una tabella è illimitato.
Al Chou

Risposte:


115

Le righe per una tabella non saranno un problema di per sé.

Quindi, approssimativamente, 1 milione di righe al giorno per 90 giorni è 90 milioni di righe. Non vedo motivo per cui Postgres non possa occuparsene, senza conoscere tutti i dettagli di ciò che stai facendo.

A seconda della distribuzione dei dati, è possibile utilizzare una combinazione di indici, indici filtrati e partizionamento delle tabelle di qualche tipo per accelerare le cose una volta che si vedono quali problemi di prestazioni si possono avere o meno. Il tuo problema sarà lo stesso su qualsiasi altro RDMS che io conosca. Se hai solo bisogno di 3 mesi di progettazione dei dati in un processo per eliminare i dati, non ti servono più. In questo modo avrai un volume consistente di dati sulla tabella. Sei fortunato a sapere quanti dati esisteranno, provali per il tuo volume e vedi cosa ottieni. Testare una tabella con 90 milioni di righe può essere facile come:

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

19
Sono d'accordo che 90 milioni di righe non saranno un problema per PostgreSQL. Ma potrebbe essere un problema per un ORM con PostgreSQL. (Un ORM con qualsiasi dbms, in realtà.)
Mike Sherrill 'Cat Recall'

@ MikeSherrill'Catcall 'Buon punto, ero solo concentrato su "Quanto è grande troppo grande per una tabella PostgreSQL?"
Kuberchaun

2
@yeyo: perché gli ORM di solito utilizzano molte query per ottenere dati che potrebbero essere restituiti solo con uno o due. L'OP sta usando Ruby on Rails.
Mike Sherrill 'Cat Recall'

39
Questo è un po 'tardi ma penso che in molti casi (specialmente con rails / record attivo) sia comune rimuovere completamente l'ORM dall'equazione e scrivere una stringa sql non elaborata da interrogare per motivi di prestazioni. Non lasciare che il tuo ORM prenda decisioni sui dati per te! È un accessorio non essenziale.
Stefan Theard

2
L'URL about citato nell'URL non mostra questi limiti al momento - qualcuno sa dove è stato spostato?
Shorn

58

Un altro modo per velocizzare notevolmente le query su una tabella con> 100 milioni di righe è nel cluster fuori orario la tabella sull'indice che viene utilizzata più spesso nelle query. Abbiamo una tabella con> 218 milioni di righe e abbiamo trovato miglioramenti 30 volte superiori.

Inoltre, per una tabella molto grande, è una buona idea creare un indice sulle chiavi esterne.


> nelle ore di riposo raggruppa la tabella sull'indice che viene più spesso utilizzata nelle tue query .... puoi spiegare come si fa?
spia il

6
Sì, ecco un ESEMPIO passo passo: 1) La tabella a cui mi riferisco si chiama investimento in questo esempio. 2) L'indice più utilizzato nelle query è (bankid, record_date) Quindi ecco il tuo passo dopo passo: 1) psql -c "drop index investment_bankid_rec_dt_idx;" dbname 2) psql -c "crea indice investment_bankid_rec_dt_idx sull'investimento (bankid, record_date);" 3) psql -c "cluster investment_bankid_rec_dt_idx on investment;" 4) vacuumdb -d ccbank -z -v -t investment Quindi nei passaggi uno e due rilasciamo l'indice e lo ricreamo.
James Doherty

3
Passo 3 creiamo il cluster, questo fondamentalmente inserisce la tabella DB nell'ordine fisico dell'indice, quindi quando postgresql esegue una query memorizza nella cache le righe successive più probabili. Passaggio 4: svuotare il database per reimpostare le statistiche per il pianificatore di query
James Doherty
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.