Ако разбирам правилно мислите ви, обмисляте да съхранявате времевите серии в PostgreSQL, един запис от времеви серии в един ред на базата данни. Не правете това.
От една страна проблемът е теоретичен. Релационните бази данни (и мисля, че повечето бази данни) се основават на предпоставката за независимост на редовете, докато записите на времеви серии са физически подредени. Разбира се, индексите на базата данни осигуряват някакъв ред за таблиците на базата данни, но този ред има за цел да ускори търсенето или да представи резултатите по азбучен ред или в някакъв друг ред; това не предполага никакъв естествен смисъл на този ред. Независимо как ги поръчате, всеки клиент е независим от други клиенти и покупката на всеки клиент е независима от другите му покупки, дори ако можете да ги получите изцяло хронологично, за да формирате историята на покупките на клиента. Взаимозависимостта на записите от времеви серии е много по-силна, което прави релационните бази данни неподходящи.
На практика това означава, че дисковото пространство, заето от таблицата и нейните индекси, ще бъде огромно (може би 20 пъти по-голямо от съхраняването на времеви редове във файлове), а четенето на времеви редове от базата данни ще бъде много бавно, нещо като поръчка с величина по-бавна от съхраняването във файлове. Освен това няма да ви донесе никаква важна полза. Вероятно никога няма да направите заявката „дайте ми всички записи от времеви редове, чиято стойност е по-голяма от X“. Ако някога се нуждаете от такава заявка, ще ви трябва и адски друг анализ, за който релационната база данни не е проектирана, така че така или иначе ще прочетете целия времеви ред в някакъв обект.
Така че всеки времеви ред трябва да се съхранява като файл. Може да е или файл във файловата система, или петно в базата данни. Въпреки факта, че приложих последното, смятам, че първото е по-добро; в Django бих написал нещо подобно:
class Timeseries(models.model):
name = models.CharField(max_length=50)
time_step = models.ForeignKey(...)
other_metadata = models.Whatever(...)
data = models.FileField(...)
Използване на FileField ще направи вашата база данни по-малка и ще улесни правенето на инкрементални архиви на вашата система. Също така ще бъде по-лесно да получите изрезки, като търсите във файла, нещо, което вероятно е невъзможно или трудно с петно.
Сега какъв файл? Бих ви посъветвал да погледнете панди. Това е библиотека на python за математически анализ, която поддържа времеви редове и също така трябва да има начин да съхранява времеви серии във файлове.
Направих връзка по-горе към моя библиотека, която не ви препоръчвам да използвате; от една страна не прави каквото искаш (не може да се справи с детайлността по-фина от минута и има други недостатъци), а от друга е остаряла - писал съм го преди панди и смятам да го конвертирам да използвам панди в бъдеще. Има книга „Python за анализ на данни“ от автора на pandas, която намирам за безценна.
Актуализация (2016): Има и InfluxDB. Никога не съм го използвал и затова нямам мнение, но определено е нещо, което трябва да разгледате, ако се чудите как да съхранявате времеви редове.
Актуализация (2020-02-07): Има и TimescaleDB, разширение към PostgreSQL.
Актуализация (2020-08-07): Променихме нашия софтуер (отново), така че той да съхранява данните в базата данни, използвайки TimescaleDB. Вече сме запознати с PostgreSQL и беше лесно да научим малко TimescaleDB. Най-важното конкретно предимство е, че можем да правим заявки като „намерете всички места, където е имало>50 mm дъжд в рамките на 24 часа през 2019 г.“, нещо, което би било много трудно при съхраняване на данни в плоски файлове. Друго предимство са проверките на целостта – през годините имахме няколко времеви серии с дублиращи се редове поради малки грешки тук-там. Недостатъците също са значителни. Той използва 10 пъти повече дисково пространство. Поради това може да се наложи да променим нашата политика за архивиране на PostgreSQL. По-бавно е. Отнема може би една секунда, за да се извлече времеви серии с 300 000 записи. Това беше моментално преди. Трябваше да внедрим кеширане за извличане на времеви серии, което не беше необходимо преди.
