Als ik uw gedachten goed begrijp, overweegt u de tijdreeksen op te slaan in PostgreSQL, één tijdreeksrecord in één databaserij. Doe dat niet.
Enerzijds is het probleem theoretisch. Relationele databases (en ik denk dat de meeste databases) zijn gebaseerd op het uitgangspunt van rijonafhankelijkheid, terwijl de records van een tijdreeks fysiek zijn geordend. Natuurlijk bieden database-indexen enige volgorde voor databasetabellen, maar die volgorde is bedoeld om het zoeken te versnellen of om de resultaten alfabetisch of in een andere volgorde weer te geven; het heeft geen enkele natuurlijke betekenis voor die volgorde. Ongeacht hoe u ze bestelt, elke klant is onafhankelijk van andere klanten en de aankoop van elke klant is onafhankelijk van zijn andere aankopen, zelfs als u ze allemaal chronologisch kunt krijgen om de aankoopgeschiedenis van de klant te vormen. De onderlinge afhankelijkheid van tijdreeksrecords is veel sterker, wat relationele databases ongepast maakt.
In de praktijk betekent dit dat de schijfruimte die door de tabel en zijn indexen wordt ingenomen enorm zal zijn (misschien 20 keer groter dan het opslaan van de tijdreeksen in bestanden), en dat het lezen van tijdreeksen uit de database erg traag zal zijn, zoiets als een bestelling van grootte langzamer dan opslaan in bestanden. Het levert u ook geen belangrijk voordeel op. U zult waarschijnlijk nooit de vraag stellen "geef me alle tijdreeksrecords waarvan de waarde groter is dan X". Als je ooit zo'n query nodig hebt, heb je ook nog een hele andere analyse nodig waar de relationele database niet voor is ontworpen, dus je leest de hele tijdreeks toch in een of ander object.
Elke tijdreeks moet dus als een bestand worden opgeslagen. Het kan een bestand op het bestandssysteem zijn, of een blob in de database. Ondanks het feit dat ik het laatste heb geïmplementeerd, geloof ik dat het eerste beter is; in Django zou ik zoiets als dit schrijven:
class Timeseries(models.model):
name = models.CharField(max_length=50)
time_step = models.ForeignKey(...)
other_metadata = models.Whatever(...)
data = models.FileField(...)
Een FileField gebruiken zal uw database kleiner maken en het gemakkelijker maken om incrementele back-ups van uw systeem te maken. Het zal ook gemakkelijker zijn om plakjes te krijgen door in het bestand te zoeken, iets dat waarschijnlijk onmogelijk of moeilijk is met een klodder.
Wat voor bestand? Ik zou je aanraden om eens naar panda's te kijken. Het is een Python-bibliotheek voor wiskundige analyse die tijdreeksen ondersteunt, en het zou ook een manier moeten hebben om tijdreeksen in bestanden op te slaan.
Ik heb hierboven gelinkt naar een bibliotheek van mij die ik je niet aanraad om te gebruiken; aan de ene kant doet het niet wat je wilt (het kan de fijnheid van minder dan een minuut niet aan, en het heeft andere tekortkomingen), en aan de andere kant is het verouderd - ik schreef het voor panda's, en ik ben van plan het te converteren om in de toekomst panda's te gebruiken. Er is een boek, "Python voor data-analyse", van de auteur van panda's, die ik van onschatbare waarde heb gevonden.
Update (2016): Er is ook InfluxDB. Nooit gebruikt en daarom heb ik geen mening, maar het is zeker iets dat je moet onderzoeken als je je afvraagt hoe je tijdreeksen opslaat.
Update (2020-02-07): Er is ook TimescaleDB, een uitbreiding op PostgreSQL.
Update (2020-08-07): We hebben onze software (opnieuw) aangepast zodat deze de gegevens in de database opslaat met behulp van TimescaleDB. We zijn al thuis in PostgreSQL en het was gemakkelijk om wat TimescaleDB te leren. Het belangrijkste concrete voordeel is dat we query's kunnen maken als "vind alle locaties waar er in 2019>50 mm regen was binnen 24 uur", iets wat heel moeilijk zou zijn bij het opslaan van gegevens in platte bestanden. Een ander voordeel zijn de integriteitscontroles:in de loop der jaren hadden we een paar tijdreeksen met dubbele rijen vanwege kleine bugs hier en daar. De nadelen zijn ook aanzienlijk. Het gebruikt 10 keer meer schijfruimte. Daarom moeten we mogelijk ons PostgreSQL-back-upbeleid wijzigen. Het is langzamer. Het duurt misschien een seconde om een tijdreeks met 300k records op te halen. Dit was direct eerder. We moesten caching implementeren voor het ophalen van tijdreeksen, wat voorheen niet nodig was.