समय-श्रृंखला डेटा संग्रहीत करना, रिलेशनल या नॉन?

Question

मैं एक ऐसी प्रणाली बना रहा हूं जो एसएनएमपी का उपयोग करके (शायद) 5 मिनट के अंतराल पर सीपीयू उपयोग, डिस्क उपयोग, तापमान आदि जैसे अलग-अलग मैट्रिक्स पर डेटा के लिए उपकरणों को प्रदूषित करता है। अंतिम लक्ष्य समय-श्रृंखला ग्राफ़ के रूप में सिस्टम के एक उपयोगकर्ता को विज़ुअलाइज़ेशन प्रदान करना है।

मैंने अतीत में RRDTool का उपयोग किया है, लेकिन इसे अस्वीकार कर दिया क्योंकि कैप्चर किए गए डेटा को अनिश्चित काल तक संग्रहीत करना मेरे प्रोजेक्ट के लिए महत्वपूर्ण है, और मैं कैप्चर किए गए डेटा के लिए उच्च स्तर और अधिक लचीली पहुंच चाहता हूं। तो मेरा प्रश्न वास्तव में है:

बेहतर क्या है, एक संबंधपरक डेटाबेस (जैसे MySQL या PostgreSQL) या एक गैर-संबंधपरक या NoSQL डेटाबेस (जैसे MongoDB या Redis) प्रदर्शन के संबंध में जब ग्राफिंग के लिए डेटा क्वेरी करता है।

संबंधपरक

एक संबंधपरक डेटाबेस को देखते हुए, मैं एक data_instancesतालिका का उपयोग करूंगा , जिसमें निम्नलिखित क्षेत्रों के साथ, सभी उपकरणों के लिए मापी जा रही प्रत्येक मीट्रिक के लिए कैप्चर किए गए डेटा का हर उदाहरण संग्रहीत किया जाएगा:

खेत: id fk_to_device fk_to_metric metric_value timestamp

जब मैं किसी विशेष डिवाइस पर किसी विशेष मीट्रिक के लिए एक ग्राफ खींचना चाहता हूं, तो मुझे इस विलक्षण तालिका को अन्य उपकरणों को फ़िल्टर करने की क्वेरी करनी होगी , और इस उपकरण के लिए अन्य मैट्रिक्स का विश्लेषण किया जा रहा है:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

इस तालिका में पंक्तियों की संख्या होगी:

d * m_d * f * t

जहां dकी संख्या है उपकरणों , m_dसंचयी है मैट्रिक्स की संख्या , सभी उपकरणों के लिए रिकॉर्ड किया जा रहा fहै आवृत्ति , जिस पर डेटा के लिए सर्वेक्षण में शामिल किया जाता है और tकी कुल राशि है समय प्रणाली डेटा इकट्ठा करने गया है।

एक उपयोगकर्ता के लिए एक वर्ष के लिए हर 5 मिनट में 3 उपकरणों के लिए 10 मीट्रिक रिकॉर्ड करने के लिए, हमारे पास केवल 5 मिलियन रिकॉर्ड होंगे।

इंडेक्स

अनुक्रमित किए बिना fk_to_deviceऔर fk_to_metricइस लगातार विस्तार तालिका को स्कैन करने में बहुत अधिक समय लगेगा। अतः उपर्युक्त क्षेत्रों को और भी timestamp(स्थानीयकृत अवधियों के साथ रेखांकन बनाने के लिए) एक आवश्यकता है।

गैर-संबंधपरक (NoSQL)

MongoDB में एक संग्रह की अवधारणा है , तालिकाओं के बिना इन्हें सेटअप के बिना प्रोग्रामेटिक रूप से बनाया जा सकता है। इनके साथ मैं प्रत्येक डिवाइस के लिए डेटा के भंडारण को विभाजित कर सकता हूं, या यहां तक ​​कि प्रत्येक डिवाइस के लिए दर्ज प्रत्येक मीट्रिक भी।

मुझे NoSQL के साथ कोई अनुभव नहीं है और पता नहीं है कि क्या वे किसी भी क्वेरी प्रदर्शन को बढ़ाने वाले फीचर जैसे कि इंडेक्सिंग प्रदान करते हैं, हालांकि पिछले पैराग्राफ में संरचना में अधिकांश पारंपरिक संबंधपरक क्वेरी काम करने का प्रस्ताव है जिसके द्वारा डेटा NoSQL के तहत संग्रहीत किया जाता है।

दुविधा में पड़ा हुआ

सही अनुक्रमण के साथ एक संबंधपरक समाधान वर्ष के भीतर क्रॉल को कम करेगा? या NoSQL दृष्टिकोण के संग्रह आधारित संरचना (जो संग्रहीत डेटा के मेरे मानसिक मॉडल से मेल खाती है) एक ध्यान देने योग्य लाभ प्रदान करती है?

Comments

बहुत मान्य प्रश्न, मैंने खुद इस पर विचार किया है कि क्या संबंधपरक डीबी एक डेटा संरचना को संग्रहीत करने का सही तरीका है जो वास्तव में श्रेणीबद्ध (एसएनएमपी संरचना) है। कभी-कभी जब मैं तुच्छ डेटा भी प्राप्त करने के लिए एक प्रश्न लिखता हूं, तो क्वेरी अति-जटिल होती है, मुझे लगा कि डेटा को एक ऐसे रूप में मंगवाना पड़ा जो उसका अपना नहीं है। उदाहरण के लिए, यदि किसी समान माता-पिता की संतान होने के नाते, इफनेम और उनकी अनुक्रमणिका को एक तुच्छ कार्य माना जाता है। लेकिन जिस तरह से यह रिलेशनल डीबी में संग्रहीत होता है, इसकी मूल संरचना से संबंधित नहीं होता है और मुझे लगता है कि इसे पदानुक्रमित फैशन में संग्रहीत करना अधिक कुशल है।

— Benny

"एक उपयोगकर्ता के लिए एक वर्ष के लिए हर 5 मिनट में 3 उपकरणों के लिए 10 मीट्रिक रिकॉर्ड करना, हमारे पास केवल 5 मिलियन रिकॉर्ड होंगे।" क्या 10 * 3 * 365 * 24 * 12 लगभग 3 मिलियन के बराबर नहीं है जो सिर्फ 5 मिलियन से कम नहीं है ?

— मैथ्यू बॉर्डर

Answer 1

निश्चित रूप से संबंधपरक। असीमित लचीलापन और विस्तार।

दो सुधार, अवधारणा और अनुप्रयोग दोनों में, एक उन्नयन के बाद।

भूल सुधार

1. यह "गैर-आवश्यक डेटा को फ़िल्टर करना" नहीं है; यह केवल आवश्यक डेटा का चयन कर रहा है । हां, निश्चित रूप से, यदि आपके पास WHERE क्लॉज में पहचाने गए कॉलम का समर्थन करने के लिए एक इंडेक्स है, तो यह बहुत तेज़ है, और क्वेरी तालिका के आकार पर निर्भर नहीं करती है (16 बिलियन पंक्ति तालिका से 1,000 पंक्तियों को पकड़ना तात्कालिक है) ।

2. आपकी तालिका में एक गंभीर बाधा है। आपके विवरण को देखते हुए, वास्तविक PK है (डिवाइस, मीट्रिक, दिनांक समय)। (कृपया इसे टाइमस्टैम्प न कहें, इसका मतलब कुछ और है, लेकिन यह एक मामूली समस्या है।) पंक्ति की विशिष्टता की पहचान की जाती है:

      (Device, Metric, DateTime)
   

   • Idस्तंभ, कुछ नहीं करता है यह पूरी तरह से और पूरी तरह से अनावश्यक है।

     • एक Idकॉलम कभी भी कुंजी नहीं है (डुप्लिकेट पंक्तियाँ, जो एक संबंधपरक डेटाबेस में निषिद्ध हैं, अन्य तरीकों से रोका जाना चाहिए)।

     • Idस्तंभ एक अतिरिक्त सूचकांक है, जो स्पष्ट रूप से की गति में बाधा उत्पन्न की आवश्यकता है INSERT/DELETE, और डिस्क इस्तेमाल किया अंतरिक्ष के लिए कहते हैं।

     • आप इससे छुटकारा पा सकते हैं। कृप्या।

ऊंचाई

1. अब जब आपने बाधा को हटा दिया है, तो आप इसे पहचान नहीं सकते हैं, लेकिन आपकी तालिका छठे सामान्य रूप में है। बहुत उच्च गति, पीके पर सिर्फ एक सूचकांक के साथ। समझ के लिए, पढ़ने के इस जवाब से छठी सामान्य रूप क्या है? आगे की ओर।

   • (मेरे पास केवल एक सूचकांक है, तीन नहीं; गैर-एसक्यूएल पर आपको तीन सूचकांकों की आवश्यकता हो सकती है)।

   • मेरे पास सटीक एक ही तालिका है ( Id"कुंजी" के बिना , बिल्कुल)। मेरे पास एक अतिरिक्त कॉलम है Server। मैं दूरस्थ रूप से कई ग्राहकों का समर्थन करता हूं।

     (Server, Device, Metric, DateTime)

   तालिका का उपयोग डेटा को पिवट करने के लिए किया जा सकता है (अर्थात Devicesऊपर और Metricsनीचे की तरफ, या pivoted) बिल्कुल उसी SQL कोड (हाँ, कोशिकाओं को स्विच करें) का उपयोग करके। मैं ग्राहकों के लिए अपने सर्वर के प्रदर्शन को फिर से दिखाने के लिए कई प्रकार के ग्राफ और चार्ट बनाने के लिए तालिका का उपयोग करता हूं।

   • सांख्यिकी डेटा मॉडल की निगरानी करें ।
     (इनलाइन के लिए बहुत बड़ा; कुछ ब्राउज़र इनलाइन लोड नहीं कर सकते; लिंक पर क्लिक करें। इसके अलावा अप्रचलित डेमो संस्करण है, स्पष्ट कारणों के लिए, मैं आपको वाणिज्यिक उत्पाद डीएम नहीं दिखा सकता हूं।)

   • यह मुझे एक एकल चयन आदेश का उपयोग करके ग्राहक से एक कच्ची निगरानी आँकड़े फ़ाइल प्राप्त करने के बाद, इस तरह चार्ट का उत्पादन करने की अनुमति देता है । मिक्स-एंड-मैच पर ध्यान दें; ओएस और एक ही चार्ट पर सर्वर; पिवोट्स की एक किस्म। बेशक, आँकड़े मैट्रिक्स की संख्या और इस प्रकार चार्ट की कोई सीमा नहीं है। (ग्राहक की तरह की अनुमति के साथ उपयोग किया जाता है।)

   • मानक के साथ अपरिचित हैं जो पाठक मॉडलिंग संबंधी रिलेशनल डेटाबेस के लिए मानक से अपरिचित हैं, उन्हें IDEF1X नोटेशन मददगार मिल सकता है ।

एक और चीज़

अंतिम लेकिन कम से कम, SQL एक IEC / ISO / ANSI मानक नहीं है। फ्रीवेयर वास्तव में गैर-एसक्यूएल है; यदि वे मानक प्रदान नहीं करते हैं तो एसक्यूएल शब्द का उपयोग करना धोखाधड़ी है। वे "एक्स्ट्रा" प्रदान कर सकते हैं, लेकिन वे मूल बातें अनुपस्थित हैं।

Comments

@PerformanceDBA क्या आप एक सेटअप के लिए सुझाए गए स्कीमा का उपयोग करेंगे जिसे 1 मिनट की आवृत्ति के साथ ~ 3 मिलियन उपायों को संभालना है? आप ऐसी तालिका के लिए पीके को कैसे ऑर्डर करेंगे? डिवाइस, मीट्रिक, डेटटाइम विखंडन नहीं बनाएगा और RDBMS को बहुत सारे पृष्ठ विभाजन के लिए बाध्य करेगा? इसके बजाय डेटटाइम डालने से पहले विखंडन कम हो जाता है (मैं मान रहा हूं कि आवेषण का समय दिया गया है) लेकिन रीड को सबसे खराब बनाते हैं।

— marcob

@Buchi। मैं Sybase ASE का उपयोग करता हूं। लेकिन यह एक प्लेटफ़ॉर्म मुद्दा नहीं है (निश्चित रूप से, उच्च प्लेटफ़ॉर्म प्रदर्शन प्रदान करते हैं जो कम अंत की तुलना में बेहतर परिमाण के आदेश हैं; ओरेकल की तुलना में बेहतर परिमाण के तीन आदेश, लेकिन वह बिंदु नहीं है), तालिका से चार्ट का निर्माण " किसी भी मंच पर काम करता है। इस काम के लिए सही उपकरण का उपयोग करें। RDBMS एक डेटाबेस उपकरण है, न कि कोई रेखांकन उपकरण। gnuplot, Apple नंबर (या यदि आप दस गुना अधिक भुगतान करना पसंद करते हैं, तो आधे से ज्यादा, एमएस एक्सेल) चार्टिंग टूल हैं, डेटाबेस टूल नहीं। इन दिनों हम परिणाम उत्पन्न करने के लिए उपकरणों की परतों का उपयोग करते हैं, मोनोलिथ एक डायनासोर है।

— प्रदर्शन

@marcob। आपका प्रश्न एक अच्छा है, लेकिन टिप्पणियों में इसका ठीक से उत्तर नहीं दिया जा सकता है। यदि आप एक नया प्रश्न खोलते हैं, और मुझे ईमेल करते हैं (प्रोफ़ाइल पर जाएं), तो मैं इसका उत्तर दूंगा। यहां त्वरित जवाब के लिए। (१) ~ ३ मिलियन मेट्रिक्स। महान, जितना अधिक विलय, यह INSERT बिंदुओं को खूबसूरती से फैलाता है, आपका अंतिम पृष्ठ पर संघर्षों की गारंटी देगा। सर्वर बहु-थ्रेडेड है, हाँ? विभाजन तालिका। फ़िलीचर का उपयोग करें और आवेषण के लिए जगह छोड़ दें, और इस प्रकार पृष्ठ विभाजन से बचें। (२) ~ ३ मिल इंगित करता है कि मेट्रिक्स सामान्यीकृत नहीं हैं, यदि आप इसे सही करते हैं, तो यह और भी तेज होगा।

— प्रदर्शन

@marcob। (३) मैं दिए गए सूचकांक का उपयोग ठीक से लोड के तहत आवेषण को फैलाने के लिए करता हूं , जो बिना किसी विरोध के सुनिश्चित करता है। (४) इसलिए, मेरा तरीका चयनों पर कोई विरोध और उच्च प्रदर्शन के साथ दोनों आवेषण प्राप्त करता है ।

— प्रदर्शन

@Loic। पृथ्वी पर कोई भी व्यक्ति, जिसके पास SQL ​​प्लेटफॉर्म में एक निवेश (डेटा; कोड) है, जो आसानी से और बहुत उच्च प्रदर्शन के साथ समय श्रृंखला डेटा को संभालता है (जैसा कि उत्तर में विस्तृत है), कोई SQL के साथ TSDB पर जाएं; समय श्रृंखला डेटा को छोड़कर किसी भी चीज़ के लिए अज्ञात गति? किसी ऐसे व्यक्ति की आवश्यकता क्यों है जो केवल समय-श्रृंखला-डेटा-डेटा से अधिक है, SQL मंच का उपयोग नहीं करता है? मन चकरा जाता है। टीएसडीबी केवल दुखद उदाहरण में रिलेशनल की तुलना में तेज है जब डेटा को डीबी में संग्रहीत किया जाता है लेकिन रिलेशनलली सामान्य नहीं किया जाता है । उदाहरण के लिए। जब Idकॉलम का उपयोग किया जाता है, तो "की"। जैसा कि "सिद्धांतकारों" ने सलाह दी है।

— प्रदर्शन

Answer 2

उपर्युक्त उत्तरों को बहुत दिलचस्प पाया। यहाँ कुछ और विचार जोड़ने की कोशिश की जा रही है।

1) डेटा उम्र बढ़ने

समय-श्रृंखला प्रबंधन को आमतौर पर उम्र बढ़ने की नीतियां बनाने की आवश्यकता होती है। एक विशिष्ट परिदृश्य (जैसे सर्वर सीपीयू की निगरानी) को स्टोर करने की आवश्यकता होती है:

• छोटी अवधि के लिए 1 सेकंड के कच्चे नमूने (उदाहरण के लिए 24 घंटे)

• मध्यम अवधि के लिए 5-मिनट का विवरण समग्र नमूने (उदाहरण 1 सप्ताह)

• उस पर 1-घंटे का विवरण (जैसे 1 वर्ष तक)

यद्यपि संबंधपरक मॉडल यह सुनिश्चित करने के लिए संभव बनाते हैं (मेरी कंपनी ने कुछ बड़े ग्राहकों के लिए बड़े पैमाने पर केंद्रीकृत डेटाबेस लागू किए हैं जो दसियों हज़ारों डेटा श्रृंखलाओं के साथ हैं) इसे उचित रूप से प्रबंधित करने के लिए, डेटा स्टोर की नई नस्ल में दिलचस्प कार्यशीलता को जोड़ा जाता है:

• स्वचालित डेटा शुद्ध करना (Redis 'EXPIRE कमांड देखें)

• बहुआयामी एकत्रीकरण (उदाहरण के लिए, नक्शा-कम करने वाली नौकरियां ए-ला-स्पंक)

2) वास्तविक समय संग्रह

इससे भी महत्वपूर्ण बात यह है कि कुछ गैर-संबंधपरक डेटा स्टोर स्वाभाविक रूप से वितरित किए जाते हैं और अधिक कुशल वास्तविक समय (या निकट-वास्तविक समय) डेटा संग्रह के लिए अनुमति देते हैं जो हॉटस्पॉट्स के निर्माण के कारण RDBMS के साथ एक समस्या हो सकती है (सम्मिलित करते समय अनुक्रमण को प्रबंधित करना) एक एकल तालिका)। RDBMS स्पेस में यह समस्या आम तौर पर बैच आयात प्रक्रियाओं (हम अतीत में इस तरह से प्रबंधित) को हल करने के लिए हल की जाती है, जबकि कोई भी sql प्रौद्योगिकियां बड़े पैमाने पर वास्तविक समय संग्रह और एकत्रीकरण में सफल नहीं हुई हैं (उदाहरण के लिए स्प्लंक देखें, पिछले उत्तरों में उल्लेख किया गया है) ।

Answer 3

आप तालिका में एकल तालिका में डेटा है। इसलिए रिलेशनल बनाम नॉन रिलेशनल सवाल नहीं है। मूल रूप से आपको बहुत सारे अनुक्रमिक डेटा पढ़ने की आवश्यकता होती है। अब अगर आपके पास साल भर के डेटा को स्टोर करने के लिए पर्याप्त रैम है तो Redis / MongoDB आदि का उपयोग करने जैसा कुछ भी नहीं है।

अधिकतर NoSQL डेटाबेस आपके डेटा को डिस्क पर एक ही स्थान पर और कई डिस्क एक्सेस से बचने के लिए संपीड़ित रूप में संग्रहीत करेगा।

NoSQL डिवाइस आईडी और मीट्रिक आईडी पर सूचकांक बनाने के समान काम करता है, लेकिन अपने तरीके से। डेटाबेस के साथ भले ही आप ऐसा करते हों, इंडेक्स और डेटा अलग-अलग जगहों पर हो सकते हैं और बहुत सारे डिस्क IO होंगे।

स्प्लंक जैसे उपकरण टाइम सीरीज़ डेटा को स्टोर करने के लिए NoSQL बैकेंड का उपयोग कर रहे हैं और फिर एग्रीगेट बनाने के लिए मैप कम का उपयोग कर रहे हैं (जो कि आप जो चाहते हैं वह हो सकता है)। तो NoSQL का उपयोग करने के लिए मेरी राय में एक विकल्प है क्योंकि लोगों ने पहले से ही इसी तरह के उपयोग के मामलों के लिए कोशिश की है। लेकिन क्या एक लाख पंक्तियाँ डेटाबेस को क्रॉल करने के लिए लाएंगी (हो सकता है, सभ्य हार्डवेयर और उचित कॉन्फ़िगरेशन के साथ नहीं)।

Comments

क्या आप बता सकते हैं कि तालिका "डी-सामान्यीकृत" कैसे है? मार्कस की तालिका में कोई त्रुटि है, लेकिन यह सामान्यीकरण त्रुटि नहीं है।

— प्रदर्शनदिवस

मैं अपने आप को सही करूंगा, पारंपरिक अर्थों में तालिकाओं को सामान्य किया जाता है। मेरा मतलब इस अर्थ में डी-सामान्यीकृत था कि उपयोग के मामले में एक तालिका में सभी डेटा है।

— रवींद्र

Answer 4

एक फ़ाइल बनाएं, इसे 1_2.data नाम दें। विचार है? क्या आपको मिला:

• आप 50% स्थान तक बचाते हैं क्योंकि आपको हर डेटा बिंदु के लिए fk_to_device और fk_to_metric मान दोहराने की आवश्यकता नहीं होती है।
• आप और भी अधिक स्थान बचाते हैं क्योंकि आपको किसी भी सूचकांक की आवश्यकता नहीं है।
• डेटा को जोड़कर फ़ाइल (टाइमस्टैम्प, मेट्रिक_वेल्यू) के जोड़े को सहेजें ताकि आपको टाइमस्टैम्प द्वारा मुफ्त में ऑर्डर मिल जाए। (यह मानते हुए कि आपके स्रोत डिवाइस के लिए ऑर्डर डेटा नहीं भेजते हैं)

=> टाइमस्टैम्प द्वारा क्वेरी आश्चर्यजनक रूप से तेज चलती हैं क्योंकि आप पढ़ने के लिए फ़ाइल में सही जगह खोजने के लिए द्विआधारी खोज का उपयोग कर सकते हैं।

यदि आप इसे पसंद करते हैं और भी अधिक अनुकूलित अपनी फ़ाइलों को विभाजित करने के बारे में सोचने लगते हैं;

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

या http://kx.com से kdb + का उपयोग करें क्योंकि वे आपके लिए यह सब करते हैं :) स्तंभ-उन्मुख वह है जो आपकी सहायता कर सकता है।

क्लाउड-आधारित स्तंभ-उन्मुख समाधान पॉप अप हो रहा है, इसलिए आप इसे देख सकते हैं: http://timeseries.guru

Comments

मैंने विषय के बारे में एक ब्लॉग पोस्ट लिखा था। Google अनुवाद के साथ आपको यह मददगार लग सकता है: blog.michaelwittig.info/die-spaltenorientierte-datenbank-kdb

— hellomichibye

Answer 5

यदि आप GPL पैकेज देख रहे हैं, तो RRDTool देखने में अच्छा है। यह स्टोर करने, निकालने और रेखांकन समय-श्रृंखला डेटा के लिए एक अच्छा उपकरण है। आपका उपयोग-मामला बिल्कुल समय-श्रृंखला डेटा जैसा दिखता है।

Answer 6

यह एक ऐसी समस्या है जिसे हमें ApiAxle में हल करना होगा। हमने एक ब्लॉग पोस्ट लिखा है कि हमने रेडिस का उपयोग कैसे किया। यह बहुत लंबे समय तक नहीं रहा है लेकिन यह प्रभावी साबित हो रहा है।

मैंने एक और प्रोजेक्ट के लिए RRDTool का भी उपयोग किया है जो उत्कृष्ट था।

Answer 7

मुझे लगता है कि इस तरह के प्रश्न का उत्तर मुख्य रूप से आपके डेटाबेस के उपयोग के भंडारण के तरीके के बारे में घूमना चाहिए। कुछ डेटाबेस सर्वर रैम और डिस्क का उपयोग करते हैं, कुछ केवल रैम (दृढ़ता के लिए वैकल्पिक रूप से डिस्क) आदि का उपयोग करते हैं। अधिकांश सामान्य SQL डेटाबेस समाधान मेमोरी + डिस्क स्टोरेज का उपयोग कर रहे हैं और डेटा को पंक्ति आधारित लेआउट में लिखते हैं (प्रत्येक डाला कच्चा ही में लिखा जाता है) भौतिक स्थान)। टाइम्स स्टोर के लिए, ज्यादातर मामलों में काम का बोझ कुछ इस तरह होता है: आवेषण की भारी मात्रा में अपेक्षाकृत कम अंतराल, जबकि रीड कॉलम आधारित होते हैं (ज्यादातर मामलों में आप एक विशिष्ट कॉलम से डेटा की एक सीमा को पढ़ना चाहते हैं, एक मीट्रिक का प्रतिनिधित्व करते हैं)

मैंने कॉलमनुमा डेटाबेस पाया है (इसे गूगल करें, आपको मॉनेटबीडी, इंफोबीराइट, पार्सल, आदि मिलेंगे) टाइम सीरीज़ के लिए बहुत अच्छा काम कर रहे हैं।

आपके प्रश्न के लिए, जो व्यक्तिगत रूप से मुझे लगता है कि कुछ अमान्य है (जैसा कि सभी चर्चाएं NoSQL - IMO का उपयोग करके चर्चा करती हैं): आप एक डेटाबेस सर्वर का उपयोग कर सकते हैं जो एक तरफ SQL से बात कर सकता है, जिससे आपका जीवन बहुत आसान हो जाता है क्योंकि हर कोई कई के लिए SQL जानता है वर्ष और इस भाषा को डेटा प्रश्नों के लिए बार-बार सिद्ध किया गया है; लेकिन अभी भी RAM, CPU Cache और Disk का एक Columnar ओरिएंटेड तरीके से उपयोग करते हैं, जिससे आपका सॉल्यूशन सबसे उपयुक्त है Time Series

Answer 8

5 लाख पंक्तियाँ आज के मूसलाधार डेटा के लिए कुछ भी नहीं है। कुछ महीनों में डेटा को टीबी या पीबी में होने की उम्मीद है। इस बिंदु पर RDBMS कार्य के पैमाने पर नहीं है और हमें NoSql डेटाबेस की रैखिक मापनीयता की आवश्यकता है। प्रदर्शन को बढ़ावा देने के लिए डेटा को संग्रहीत करने के लिए उपयोग किए जाने वाले स्तंभ विभाजन के लिए प्रदर्शन प्राप्त किया जाएगा, प्रदर्शन को बढ़ावा देने के लिए अधिक पंक्तियों और कम पंक्तियों की तरह की अवधारणा। HBASE या MapR_DB, आदि के शीर्ष पर किए गए ओपन TSDB कार्य का लाभ उठाएं।

Comments

"RDBMS कार्य के पैमाने पर नहीं है" - वे क्यों नहीं करेंगे? code.facebook.com/posts/190251048047090/…

— जैथ्रुस राइटर

Answer 9

मैं नियमित रूप से समान आवश्यकताओं का सामना करता हूं, और हाल ही में इस प्रकार के डेटा को इकट्ठा करने और संग्रहीत करने के लिए ज़ैबिक्स का उपयोग करना शुरू कर दिया है। Zabbix की अपनी रेखांकन क्षमता है, लेकिन यह Zabbix के डेटाबेस से डेटा को निकालने और हालाँकि इसे पसंद करने की प्रक्रिया के लिए काफी आसान है। यदि आपने Zabbix को पहले से चेक नहीं किया है, तो आपको ऐसा करने के लिए अपना समय मिल सकता है।

Comments

हां, Zabbix अच्छा है और पहले से ही SNMP की निगरानी के साथ एकीकृत है। Zabbix MySQL या PostgreSQL का उपयोग कर सकता है और उबंटू के बॉक्स से कम या ज्यादा बाहर काम करता है।

— डिर्क एडल्डबुलेटेल

धन्यवाद, मुझे ज़ैबिक्स और बहुत सारे अन्य एसएनएमपी उपकरणों का ज्ञान है। हालांकि मैं इस परियोजना को एक शैक्षिक प्रक्रिया के रूप में विकसित कर रहा हूं, यहां चर्चा किए गए विषय और कई अन्य पहलुओं में। एक अच्छी बात हालांकि!

— मार्कस Whybrow

Answer 10

आपको टाइम सीरीज़ डेटाबेस में देखना चाहिए । यह इस उद्देश्य के लिए बनाया गया था।

एक समय श्रृंखला डेटाबेस (TSDB) एक सॉफ्टवेयर प्रणाली है जो समय श्रृंखला डेटा, समय द्वारा अनुक्रमित संख्याओं की सरणियों (एक डेटाटाइम या एक डेटाइम रेंज) को संभालने के लिए अनुकूलित है।

समय-श्रृंखला डेटाबेस InfluxDB का लोकप्रिय उदाहरण

Comments

अब इस सूची में

— टाइमकालेबड