Numero massimo (utilizzabile) di righe in una tabella Postgresql

Question

Mi rendo conto che, per i documenti Pg (http://www.postgresql.org/about/), è possibile memorizzare un numero illimitato di righe in una tabella. Tuttavia, qual è la "regola generale" per il numero di righe utilizzabili, se ce ne sono?

Contesto: Voglio memorizzare le letture giornaliere per un paio di decenni per 13 milioni di celle. Funziona su 13 M * (366 | 365) * 20 ~ 9.5e10 o 95 righe B (in realtà, circa 120 righe B).

Quindi, utilizzando il partizionamento delle tabelle, ho impostato una tabella principale e ho ereditato le tabelle per anno. Questo divide le righe in ~ 5,2 righe B per tabella.

Ogni riga è composta da 9 SMALLINT e due INT, quindi 26 byte. Aggiungi a questo, l'overhead Pg di 23 byte per riga, e otteniamo 49 byte per riga. Quindi, ogni tabella, senza alcun PK o qualsiasi altro indice, peserà in ~ 0,25 TB.

Per gli utenti iniziali, ho creato solo un sottoinsieme dei dati precedenti, ovvero solo per circa 250.000 celle. Devo fare un po 'di tuning (creare indici appropriati, ecc.), Ma le prestazioni sono davvero terribili in questo momento. Inoltre, ogni volta che ho bisogno di aggiungere più dati, dovrò rilasciare le chiavi e ricrearle. Il vantaggio è che una volta caricato tutto, sarà un database di sola lettura.

Qualche suggerimento? Qualche altra strategia per il partizionamento?

Answer 1

Non è solo "un po 'di sintonizzazione (indici, ecc.)". Questo è fondamentale e assolutamente da fare.

Hai postato pochi dettagli, ma proviamo.

La regola è: provare e trovare il set di lavoro più comune. Guarda se rientra nella RAM. Ottimizza hardware, impostazioni del buffer PG/OS e indici/clustering PG per questo. Altrimenti cerca aggregati, o se non è accettabile e hai bisogno di un accesso completamente casuale, pensa a quale hardware è in grado di eseguire la scansione dell'intero tavolo per te in tempi ragionevoli.

Quanto è grande la tabella (in gigabyte)? Come si confronta alla RAM totale? Quali sono le tue impostazioni PG, compresi shared_buffers e effective_cache_size? È un server dedicato? Se disponi di una tabella da 250 gig e di circa 10 GB di RAM, significa che puoi occupare solo il 4% della tabella.

Esistono colonne utilizzate comunemente per il filtro, quali stato o data? Puoi il set di lavoro che è più comunemente usato (come solo il mese scorso)? In questo caso, considera il partizionamento o il clustering su queste colonne e indicizza decisamente. Fondamentalmente, stai cercando di assicurarti che il maggior numero possibile di working set si adatti alla RAM.

Evitare la scansione del tavolo a tutti i costi se non si adatta alla RAM. Se hai davvero bisogno di un accesso assolutamente casuale, l'unico modo in cui potrebbe essere utilizzabile è l'hardware davvero sofisticato. Avresti bisogno di una memoria persistente/configurazione RAM in grado di leggere 250 GB in tempi ragionevoli.