Dit aantal is niet zo hoog als je denkt. In het huidige werk slaan we metrische gegevens op voor websites en het totale aantal rijen dat we hebben is veel hoger. En in mijn vorige baan werkte ik met een pg-database die statistieken verzamelde van het mobiele netwerk en die ongeveer 2 miljard records per dag verzamelde. Wees dus niet bang voor miljarden records.
U zult zeker gegevens moeten partitioneren - hoogstwaarschijnlijk overdag. Met deze hoeveelheid gegevens kun je indexen vrij nutteloos vinden. Hangt af van vliegtuigen die je zult zien in EXPLAIN opdracht uitvoer. Die telco-app gebruikte bijvoorbeeld helemaal geen indexen omdat ze gewoon de hele motor zouden vertragen.
Een andere vraag is hoe snel antwoorden op vragen die u nodig heeft. En welke stappen in granulariteit (sommen over uren/dagen/weken enz.) voor vragen die u toestaat voor gebruikers. Mogelijk moet u zelfs enkele aggregaties maken voor granulariteiten zoals week, maand of kwartaal.
Toevoeging:
Die ~ 2 miljard records per dag in die telco-app namen ~ 290 GB per dag in beslag. En het betekende invoegingen van ~ 23000 records per seconde met behulp van bulkinvoegingen met de opdracht COPY. Elke bulk bestond uit enkele duizenden records. Ruwe gegevens werden gepartitioneerd in minuten. Om disk waits te voorkomen had db 4 tablespaces op 4 verschillende disks/arrays en werden er partities over verdeeld. PostreSQL kon het allemaal zonder problemen aan. Dus je moet ook nadenken over de juiste HW-configuratie.
Een goed idee is ook om de map pg_xlog naar een aparte schijf of array te verplaatsen. Nee gewoon een ander bestandssysteem. Het moet allemaal gescheiden HW zijn. SSD's kan ik alleen aanbevelen in arrays met de juiste foutcontrole. De laatste tijd hadden we problemen met een beschadigde database op een enkele SSD.