अगर मैं आपके विचारों को सही ढंग से समझता हूं, तो आप PostgreSQL में समय श्रृंखला को संग्रहीत करने पर विचार कर रहे हैं, एक डेटाबेस पंक्ति में एक बार श्रृंखला रिकॉर्ड। ऐसा मत करो।
एक ओर, समस्या सैद्धांतिक है। संबंधपरक डेटाबेस (और मुझे लगता है कि अधिकांश डेटाबेस) पंक्ति स्वतंत्रता के आधार पर आधारित होते हैं, जबकि एक समय श्रृंखला के रिकॉर्ड भौतिक रूप से क्रमबद्ध होते हैं। बेशक, डेटाबेस इंडेक्स डेटाबेस टेबल के लिए कुछ ऑर्डर प्रदान करते हैं, लेकिन वह ऑर्डर खोज को गति देने या वर्णानुक्रम में या किसी अन्य क्रम में परिणाम प्रस्तुत करने के लिए है; यह उस आदेश के लिए कोई प्राकृतिक अर्थ नहीं दर्शाता है। चाहे आप उन्हें कैसे भी ऑर्डर करें, प्रत्येक ग्राहक अन्य ग्राहकों से स्वतंत्र होता है, और प्रत्येक ग्राहक की खरीदारी उसकी अन्य खरीदारी से स्वतंत्र होती है, भले ही आप ग्राहक के खरीदारी इतिहास को बनाने के लिए उन्हें पूरी तरह से कालानुक्रमिक रूप से प्राप्त कर सकते हैं। समय श्रृंखला रिकॉर्ड की अन्योन्याश्रयता अधिक मजबूत होती है, जो संबंधपरक डेटाबेस को अनुपयुक्त बनाती है।
व्यवहार में, इसका मतलब है कि टेबल और उसके इंडेक्स द्वारा लिया गया डिस्क स्थान बहुत बड़ा होगा (शायद फाइलों में समय श्रृंखला को संग्रहीत करने से 20 गुना बड़ा), और डेटाबेस से पढ़ने की समय श्रृंखला बहुत धीमी होगी, एक आदेश जैसा कुछ फाइलों में भंडारण की तुलना में धीमी परिमाण की। इससे आपको कोई महत्वपूर्ण लाभ भी नहीं होगा। आप शायद कभी भी यह प्रश्न नहीं करने जा रहे हैं "मुझे हर समय श्रृंखला रिकॉर्ड दें जिसका मूल्य एक्स से बड़ा है"। यदि आपको कभी भी इस तरह की क्वेरी की आवश्यकता होती है, तो आपको अन्य विश्लेषणों की भी आवश्यकता होगी, जो संबंधपरक डेटाबेस को निष्पादित करने के लिए डिज़ाइन नहीं किया गया है, इसलिए आप पूरी समय श्रृंखला को किसी वस्तु में वैसे भी पढ़ेंगे।
इसलिए हर बार सीरीज को फाइल के रूप में स्टोर किया जाना चाहिए। यह या तो फाइल सिस्टम पर एक फाइल हो सकती है, या डेटाबेस में एक ब्लॉब हो सकती है। इस तथ्य के बावजूद कि मैंने बाद वाले को लागू किया है, मेरा मानना है कि पूर्व बेहतर है; Django में, मैं कुछ इस तरह लिखूंगा:
class Timeseries(models.model):
name = models.CharField(max_length=50)
time_step = models.ForeignKey(...)
other_metadata = models.Whatever(...)
data = models.FileField(...)
FileField का उपयोग करना आपके डेटाबेस को छोटा बना देगा और आपके सिस्टम का इंक्रीमेंटल बैकअप बनाना आसान बना देगा। फ़ाइल में खोज कर स्लाइस प्राप्त करना भी आसान हो जाएगा, कुछ ऐसा जो शायद असंभव है या ब्लॉब के साथ मुश्किल है।
अब, किस तरह की फाइल? मैं आपको पांडा पर एक नज़र डालने की सलाह दूंगा। यह गणितीय विश्लेषण के लिए एक अजगर पुस्तकालय है जिसमें समय श्रृंखला के लिए समर्थन है, और इसमें समय श्रृंखला को फाइलों में संग्रहीत करने का एक तरीका भी होना चाहिए।
मैंने ऊपर अपने एक पुस्तकालय से लिंक किया है जिसका मैं आपको उपयोग करने की अनुशंसा नहीं करता; एक तरफ यह वह नहीं करता जो आप चाहते हैं (यह एक मिनट से अधिक बारीक नहीं कर सकता है, और इसमें अन्य कमियां हैं), और दूसरी तरफ यह पुराना है - मैंने इसे पांडा से पहले लिखा था, और मैं इसे परिवर्तित करने का इरादा रखता हूं भविष्य में पांडा का उपयोग करने के लिए। पांडा के लेखक की एक किताब है, "पायथन फॉर डेटा एनालिसिस", जिसे मैंने अमूल्य पाया है।
अपडेट (2016): इन्फ्लक्सडीबी भी है। कभी इसका इस्तेमाल नहीं किया और इसलिए मेरी कोई राय नहीं है, लेकिन यह निश्चित रूप से ऐसा कुछ है जिसे आपको जांचने की ज़रूरत है कि क्या आप सोच रहे हैं कि समय श्रृंखला को कैसे स्टोर किया जाए।
अपडेट (2020-02-07): TimescaleDB भी है, जो PostgreSQL का एक्सटेंशन है।
अपडेट (2020-08-07): हमने अपने सॉफ़्टवेयर को (फिर से) बदल दिया ताकि यह TimescaleDB का उपयोग करके डेटा को डेटाबेस में संग्रहीत कर सके। हम पहले से ही PostgreSQL में पारंगत हैं और कुछ TimescaleDB सीखना आसान था। सबसे महत्वपूर्ण ठोस लाभ यह है कि हम "सभी स्थानों का पता लगाएं जहां 2019 में 24 घंटों के भीतर> 50 मिमी बारिश हुई थी" जैसे प्रश्न पूछ सकते हैं, कुछ ऐसा जो फ्लैट फाइलों में डेटा संग्रहीत करते समय बहुत मुश्किल होगा। एक और फायदा अखंडता जांच है- पिछले कुछ वर्षों में हमारे पास यहां और वहां छोटी बग की वजह से डुप्लिकेट पंक्तियों के साथ कुछ समय श्रृंखला थी। कमियां भी महत्वपूर्ण हैं। यह 10 गुना अधिक डिस्क स्थान का उपयोग करता है। इसके कारण हमें अपनी PostgreSQL बैकअप नीति को बदलने की आवश्यकता हो सकती है। यह धीमा है। 300k रिकॉर्ड के साथ एक समय श्रृंखला को पुनः प्राप्त करने में शायद एक सेकंड का समय लगता है। यह तुरंत पहले था। हमें समय श्रृंखला प्राप्त करने के लिए कैशिंग लागू करने की आवश्यकता थी, जिसकी पहले आवश्यकता नहीं थी।
