Dette tal er ikke så højt, som du tror. I det nuværende arbejde gemmer vi metriske data for websteder, og det samlede antal rækker, vi har, er meget højere. Og i tidligere job arbejdede jeg med pg-database, som indsamlede metrics fra mobilnetværk, og den indsamlede ~2 milliarder poster om dagen. Så vær ikke bange for milliarder i antal poster.
Du bliver helt sikkert nødt til at partitionere data - sandsynligvis om dagen. Med denne mængde data kan du finde indekser ret ubrugelige. Afhænger af fly du vil se i EXPLAIN kommando output. For eksempel brugte den telco-app slet ikke nogen indekser, fordi de bare ville bremse hele motoren.
Et andet spørgsmål er, hvor hurtige svar på forespørgsler du har brug for. Og hvilke trin i granularitet (summer over timer/dage/uger osv.) for forespørgsler du vil tillade brugere. Du skal måske endda lave nogle sammenlægninger for granulariteter som uge eller måned eller kvartal.
Tilføjelse:
Disse ~2 milliarder poster om dagen i den teleselskabsapp tog ~290GB om dagen. Og det betød indsættelser af ~23000 poster pr. sekund ved hjælp af bulk-indsættelser med COPY-kommando. Hver bulk var flere tusinde poster. Rådata blev opdelt efter minutter. For at undgå disk waits havde db 4 tablespaces på 4 forskellige diske/arrays og partitioner var fordelt over dem. PostreSQL var i stand til at håndtere det hele uden problemer. Så du bør også tænke på korrekt HW-konfiguration.
En god idé er også at flytte mappen pg_xlog til separat disk eller array. Nej bare anderledes filsystem. Det hele skal være adskilt HW. SSD'er kan jeg kun anbefale i arrays med korrekt fejltjek. På det seneste har vi haft problemer med beskadiget database på enkelt SSD.