Questo numero non è alto come pensi. Nel lavoro corrente memorizziamo i dati delle metriche per i siti Web e la quantità totale di righe che abbiamo è molto più alta. E nel lavoro precedente ho lavorato con il database pg che raccoglieva le metriche dalla rete mobile e raccoglieva circa 2 miliardi di record al giorno. Quindi non aver paura dei miliardi di record.
Avrai sicuramente bisogno di partizionare i dati, molto probabilmente di giorno. Con questa quantità di dati puoi trovare indici abbastanza inutili. Dipende dagli aerei che vedrai in EXPLAIN uscita del comando. Ad esempio, quell'app di telecomunicazioni non utilizzava alcun indice perché rallenterebbe l'intero motore.
Un'altra domanda è la rapidità delle risposte alle domande di cui avrai bisogno. E quali passaggi in termini di granularità (somme su ore/giorni/settimane ecc.) Per le query consentirai agli utenti. Potrebbe anche essere necessario creare alcune aggregazioni per granularità come settimana, mese o trimestre.
Aggiunta:
Quei ~ 2 miliardi di record al giorno in quell'app di telecomunicazioni impiegavano ~ 290 GB al giorno. E significava inserimenti di ~ 23000 record al secondo utilizzando inserimenti in blocco con il comando COPY. Ogni massa conteneva diverse migliaia di record. I dati grezzi sono stati partizionati per minuti. Per evitare le attese del disco, db aveva 4 tablespace su 4 diversi dischi/array e su di essi erano distribuite partizioni. PostreSQL è stato in grado di gestire tutto senza problemi. Quindi dovresti pensare anche alla corretta configurazione dell'HW.
Una buona idea è anche spostare la directory pg_xlog su disco o array separati. Non solo filesystem diverso. Tutto deve essere HW separato. SSD che posso consigliare solo in array con un corretto controllo degli errori. Ultimamente abbiamo avuto problemi con database danneggiato su singolo SSD.
