Hvis jeg forstår dine tanker korrekt, overvejer du at gemme tidsserien i PostgreSQL, en tidsseriepost i en databaserække. Gør det ikke.
På den ene side er problemet teoretisk. Relationelle databaser (og jeg tror, de fleste databaser) er baseret på forudsætningen om rækkeuafhængighed, hvorimod registreringerne af en tidsserie er fysisk ordnet. Naturligvis giver databaseindekser en vis rækkefølge for databasetabeller, men den rækkefølge er beregnet til at fremskynde søgningen eller til at præsentere resultater alfabetisk eller i en anden rækkefølge; det indebærer ikke nogen naturlig betydning for den rækkefølge. Uanset hvordan du bestiller dem, er hver kunde uafhængig af andre kunder, og hver kundes køb er uafhængig af hans øvrige køb, selvom du kan få dem helt kronologisk for at danne kundens købshistorik. Den indbyrdes afhængighed af tidsserieregistreringer er meget stærkere, hvilket gør relationelle databaser upassende.
I praksis betyder det, at den diskplads, der optages af tabellen og dens indekser, vil være enorm (måske 20 gange større end at gemme tidsserierne i filer), og at læse tidsserier fra databasen vil være meget langsom, noget som en ordre af størrelse langsommere end lagring i filer. Det vil heller ikke give dig nogen vigtig fordel. Du kommer sandsynligvis aldrig til at lave forespørgslen "giv mig alle tidsserieposter, hvis værdi er større end X". Hvis du nogensinde har brug for sådan en forespørgsel, får du også brug for en helvedes anden analyse, som relationsdatabasen ikke er designet til at udføre, så du vil alligevel læse hele tidsserien ind i et eller andet objekt.
Så hver tidsserie skal gemmes som en fil. Det kan enten være en fil på filsystemet eller en klat i databasen. På trods af, at jeg har implementeret sidstnævnte, tror jeg, at førstnævnte er bedre; i Django ville jeg skrive noget som dette:
class Timeseries(models.model):
name = models.CharField(max_length=50)
time_step = models.ForeignKey(...)
other_metadata = models.Whatever(...)
data = models.FileField(...)
Brug af et FileField vil gøre din database mindre og gøre det nemmere at lave trinvise sikkerhedskopier af dit system. Det vil også være nemmere at få udsnit ved at søge i filen, noget der sandsynligvis er umuligt eller svært med en klat.
Hvad er det for en fil? Jeg vil råde dig til at tage et kig på pandaer. Det er et pythonbibliotek til matematisk analyse, der understøtter tidsserier, og det burde også have en måde at gemme tidsserier i filer.
Jeg linkede ovenfor til mit bibliotek, som jeg ikke anbefaler dig at bruge; på den ene side gør den ikke, hvad du vil (den kan ikke håndtere granularitet finere end et minut, og den har andre mangler), og på den anden side er den forældet - jeg skrev den før pandaer, og jeg agter at konvertere den at bruge pandaer i fremtiden. Der er en bog, "Python til dataanalyse", af forfatteren til pandas, som jeg har fundet uvurderlig.
Opdatering (2016): Der er også InfluxDB. Har aldrig brugt det, og derfor har jeg ingen mening, men det er bestemt noget, du skal undersøge, hvis du undrer dig over, hvordan du gemmer tidsserier.
Opdatering (2020-02-07): Der er også TimescaleDB, en udvidelse til PostgreSQL.
Opdatering (2020-08-07): Vi ændrede vores software (igen), så den gemmer dataene i databasen ved hjælp af TimescaleDB. Vi er allerede fortrolige med PostgreSQL, og det var nemt at lære noget TimescaleDB. Den vigtigste konkrete fordel er, at vi kan lave forespørgsler som "find alle steder, hvor der var>50 mm regn inden for 24 timer i 2019", noget der ville være meget vanskeligt, når man gemmer data i flade filer. En anden fordel er integritetstjekket - i årenes løb har vi haft et par tidsserier med duplikerede rækker på grund af små fejl her og der. Ulemperne er også betydelige. Det bruger 10 gange mere diskplads. Vi skal muligvis ændre vores PostgreSQL-sikkerhedskopipolitik på grund af det. Det er langsommere. Det tager måske et sekund at hente en tidsserie med 300.000 poster. Dette var øjeblikkeligt før. Vi var nødt til at implementere caching for at hente tidsserier, hvilket ikke var nødvendigt før.