👼🏽 🧒🏽 🍞 IIoT प्लेटफॉर्म में डेटाबेस: Mail.ru क्लाउड सॉल्यूशंस कई डिवाइसों के डेटा के पेटाबाइट्स के साथ कैसे काम करता है 👨‍👩‍👧‍👧 🅿️ 📢

नमस्ते, मैं एंड्री सर्गेव, Mail.ru Cloud Solutions में IoT समाधान विकास समूह के प्रमुख हूं । यह ज्ञात है कि एक सार्वभौमिक डेटाबेस मौजूद नहीं है। विशेष रूप से तब जब आपको वास्तविक समय मोड में प्रति सेकंड सेंसर से लाखों घटनाओं को संसाधित करने में सक्षम चीजों के इंटरनेट का निर्माण करने की आवश्यकता होती है।

हमारा उत्पाद Mail.ru IoT प्लेटफार्म टारनटूल पर आधारित एक प्रोटोटाइप के साथ शुरू हुआ। हम आपको बताएंगे कि हम किस रास्ते पर गए, हमें किन समस्याओं का सामना करना पड़ा और हमने उन्हें कैसे हल किया। और चीजों के औद्योगिक इंटरनेट के आधुनिक मंच की वर्तमान वास्तुकला को भी दिखाते हैं। लेख में हम बात करेंगे:

हमारे डेटाबेस आवश्यकताओं, सार्वभौमिक समाधान और सीएपी-प्रमेय के बारे में;
क्या डेटाबेस + एप्लिकेशन सर्वर एक दृष्टिकोण में एक चांदी की गोली है;
प्लेटफ़ॉर्म के विकास और उसमें प्रयुक्त डेटाबेस के बारे में;
, Tarantool’ .

, @Databases Meetup by Mail.ru Cloud Solutions. , :

Mail.ru IoT Platform

हमारे उत्पाद, Mail.ru IoT प्लेटफ़ॉर्म, औद्योगिक इंटरनेट ऑफ़ थिंग्स के निर्माण के लिए एक स्केलेबल और हार्डवेयर-स्वतंत्र प्लेटफ़ॉर्म है। यह आपको एक साथ हजारों उपकरणों से डेटा एकत्र करने और इस स्ट्रीम को वास्तविक समय मोड (अर्थात अर्ध-वास्तविक समय) के पास संसाधित करने की अनुमति देता है, जिसमें कस्टम नियमों का उपयोग करना शामिल है - पायथन या लुआ में स्क्रिप्ट।

प्लेटफ़ॉर्म स्रोतों से असीमित मात्रा में कच्चे डेटा को संग्रहीत कर सकता है, डेटा की कल्पना और विश्लेषण के लिए तैयार घटकों का एक सेट है, प्लेटफ़ॉर्म के आधार पर पूर्वानुमानित विश्लेषिकी के लिए अंतर्निहित टूल और एप्लिकेशन बनाने के लिए।

इस तरह से Mail.ru IoT प्लेटफ़ॉर्म डिवाइस दिखता है।

फिलहाल, ग्राहक की सुविधाओं पर ऑन-प्रिमाइसेस मॉडल के अनुसार इंस्टॉलेशन के लिए प्लेटफ़ॉर्म उपलब्ध है, इस साल प्लेटफ़ॉर्म को पब्लिक क्लाउड में सेवा के रूप में जारी करने की योजना है।

टारनटूल प्रोटोटाइप: यह सब कैसे शुरू हुआ

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

टारनटूल प्रोटोटाइप योजना

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

एक IoT प्लेटफॉर्म विकसित करने में हमारा लक्ष्य

एक साथ प्रोटोटाइप के साथ, हमें कार्य मिला - एक पूर्ण विकसित, स्केलेबल और दोष-सहिष्णु IoT- प्लेटफ़ॉर्म बनाने के लिए, जिसे बाद में एक सार्वजनिक क्लाउड में सेवा के रूप में लॉन्च किया जा सकता है।

हमें निम्नलिखित परिचयात्मक के साथ एक मंच बनाने की आवश्यकता थी:

एक साथ सैकड़ों हजारों डिवाइस कनेक्ट करें।
प्रति सेकंड लाखों ईवेंट प्राप्त करें।
निकट वास्तविक समय मोड में स्ट्रीम प्रसंस्करण।
कई वर्षों के लिए कच्चे डेटा का भंडारण।
स्ट्रीमिंग एनालिटिक्स और ऐतिहासिक एनालिटिक्स दोनों के लिए उपकरण।
अधिकतम आपदा वसूली के लिए कई डेटा केंद्रों में तैनाती का समर्थन।

मंच प्रोटोटाइप के पेशेवरों और विपक्ष

सक्रिय विकास की शुरुआत के समय, प्रोटोटाइप निम्नानुसार देखा गया:

टारनटूल, जो डेटाबेस + एप्लिकेशन सर्वर (एप्लिकेशन सर्वर) के रूप में उपयोग किया जाता है;
सभी डेटा टारनटूल मेमोरी में संग्रहीत हैं;
उसी टारनटूल में लुआ पर एक एप्लिकेशन, जो डेटा प्राप्त करने, इसे संसाधित करने और आने वाले डेटा पर उपयोगकर्ता स्क्रिप्ट को कॉल करने के कार्य करता है।

अनुप्रयोगों के निर्माण के इस दृष्टिकोण के अपने फायदे हैं :

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

लेकिन महत्वपूर्ण नुकसान हैं :

हमें कई वर्षों के लिए उपकरणों से कच्चे डेटा को स्टोर करने की आवश्यकता है, लेकिन हमारे पास टारेंटूल के लिए सैकड़ों पेटाबाइट मेमोरी नहीं है।
पहले प्लस का एक सीधा परिणाम: हमारे प्लेटफ़ॉर्म का पूरा कोड डेटाबेस में संग्रहीत कार्यविधियाँ हैं, जिसका अर्थ है कि प्लेटफ़ॉर्म के कोड बेस पर कोई भी अपडेट डेटाबेस का अपडेट है, जो बहुत दर्दनाक है।
, . , Tarantool 24-32 (Tarantool ) . — Tarantool, .
. - , Tarantool Lua , - , LuaJIT .

निष्कर्ष: टारनटूल एमवीपी बनाने के लिए एक अच्छा विकल्प है, लेकिन एक पूर्ण विकसित, स्केलेबल, आसानी से समर्थित और गलती-सहिष्णु IoT मंच जो सैकड़ों हजारों उपकरणों से डेटा प्राप्त कर सकता है, संसाधित कर सकता है और फिट नहीं हो सकता है।

प्रोटोटाइप का मुख्य दर्द जिसे हम छुटकारा दिलाना चाहते थे

सबसे पहले, हम अपने प्रोटोटाइप के दो दर्द का इलाज करना चाहते थे:

डेटाबेस + एप्लिकेशन सेवा की अवधारणा से दूर हो जाओ। हम डेटा स्टोर की परवाह किए बिना एप्लिकेशन कोड को अपडेट करना चाहते थे।
लोड के तहत गतिशील स्केलिंग को सरल बनाएं। मैं अधिक से अधिक कार्यों के लिए आसान स्वतंत्र क्षैतिज स्केलिंग प्राप्त करना चाहता था।

इन समस्याओं को हल करने के लिए, हमने एक अभिनव और अभी तक परीक्षण नहीं किया गया दृष्टिकोण चुना: माइक्रोसिस्ट आर्किटेक्चर और सेवाओं को स्टेटलेस - एप्लिकेशन और स्टेट-डेटाबेस में अलग करना।

स्टेटलेस सेवाओं के संचालन और क्षैतिज स्केलिंग को और सुविधाजनक बनाने के लिए, हमने उन्हें कंटेनरीकृत किया और कुबेरनेट्स को अपनाया।

हमने स्टेटलेस सेवाओं का पता लगाया, यह तय करना बाकी है कि डेटा का क्या करना है।

IoT प्लेटफ़ॉर्म के लिए मूल डेटाबेस आवश्यकताएँ

प्रारंभ में, हम बगीचे को बाड़ना नहीं चाहते थे और सभी प्लेटफ़ॉर्म डेटा को एक सार्वभौमिक डेटाबेस में संग्रहीत करना चाहते थे। लक्ष्यों का विश्लेषण करने के बाद, हम एक सार्वभौमिक डेटाबेस के लिए आवश्यकताओं की निम्नलिखित सूची में आए:

ACID- — , .
— .
— , near real-time.
— - .
— , .
— ( !), .
— , ( !).
SQL — .

CAP-

हमारी आवश्यकताओं के अनुपालन के लिए बाजार पर आने वाले सभी डेटाबेस के माध्यम से छंटनी शुरू करने से पहले, हमने एक काफी प्रसिद्ध उपकरण - कैप-प्रमेय का उपयोग करके विवेक के लिए हमारी आवश्यकताओं को मान्य करने का निर्णय लिया।

सीएपी प्रमेय का कहना है कि एक वितरित प्रणाली में निम्नलिखित तीन गुणों में से अधिकतम दो हो सकते हैं:

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

उदाहरण के लिए, क्लासिक सीए सिस्टम सिंक्रोनस प्रतिकृति के साथ एक पोस्टग्रेसीक्यूएल मास्टर-स्लेव क्लस्टर है, और क्लासिक एपी सिस्टम कैसेंड्रा है।

आइए हम अपनी आवश्यकताओं पर लौटें और कैप प्रमेय का उपयोग करके उन्हें वर्गीकृत करें:

ACID लेनदेन और सख्त संगति (या कम से कम अंततः संगति) C नहीं हैं।
लेखन और पढ़ने और उच्च उपलब्धता के लिए क्षैतिज स्केलिंग ए (मल्टी-मास्टर) है।
दोष सहिष्णुता पी है, जब एक डेटा सेंटर बाहर गिर जाता है, तो मंच को मरना नहीं चाहिए।

निष्कर्ष : हमें जिस सार्वभौमिक डेटाबेस की आवश्यकता है, वह CAP प्रमेय के सभी तीन गुण होने चाहिए, जिसका अर्थ है कि हमारी सभी आवश्यकताओं के लिए कोई सार्वभौमिक डेटाबेस नहीं है।

उस डेटा के लिए एक डेटाबेस चुनना जिसके साथ IoT प्लेटफ़ॉर्म काम करता है

यदि आप एक सार्वभौमिक डेटाबेस नहीं चुन सकते हैं, तो हमने उन डेटा के प्रकारों का चयन करने का निर्णय लिया है जिनके लिए प्लेटफ़ॉर्म काम करेगा और प्रत्येक प्रकार के लिए डेटाबेस का चयन करेगा।

पहले सन्निकटन में, हमने डेटा को दो प्रकारों में विभाजित किया है:

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

मेटाडेटा के लिए डेटाबेस चुनना

मेटाडेटा के लिए डेटाबेस आवश्यकताएँ । मेटाडेटा स्वाभाविक रूप से संबंधपरक है। उन्हें एक छोटी राशि की विशेषता है, उन्हें शायद ही कभी संशोधित किया जाता है, लेकिन वे महत्वपूर्ण डेटा हैं, वे खो नहीं सकते हैं, इसलिए अतुल्यकालिक प्रतिकृति के ढांचे के साथ-साथ एसीआईडी लेनदेन और क्षैतिज रीड स्केलिंग के भीतर भी स्थिरता महत्वपूर्ण है।

इस तरह के आंकड़े बहुत कम हैं और वे अपेक्षाकृत रूप से बदल दिए जाएंगे, इसलिए आप रिकॉर्डिंग में क्षैतिज स्केलिंग का त्याग कर सकते हैं, साथ ही दुर्घटना की स्थिति में रिकॉर्डिंग डेटाबेस की संभावित अयोग्यता भी कर सकते हैं। अर्थात्, कैप प्रमेय के संदर्भ में, हमें एक सीए प्रणाली की आवश्यकता है।

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

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

यह एक पेड़ की संरचना के रूप में उपकरणों का प्रदर्शन कैसा दिखता है।

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

टैग पेड़ों के पूर्ण कार्यान्वयन के लिए, एक संभावित डेटाबेस को निम्नलिखित आवश्यकताओं को पूरा करना चाहिए:

मनमानी चौड़ाई और गहराई वाले पेड़ों का समर्थन।
ACID लेनदेन में पेड़ तत्वों का संशोधन।
एक पेड़ को उखाड़ते समय उच्च प्रदर्शन।

क्लासिक रिलेशनल डेटाबेस छोटे पेड़ों को बहुत अच्छी तरह से संभाल सकते हैं, लेकिन वे मनमानी पेड़ों के साथ ऐसा नहीं करते हैं।

संभावित समाधान। दो डेटाबेस का उपयोग करें - एक पेड़ को संग्रहीत करने के लिए एक ग्राफ डेटाबेस और बाकी मेटा-जानकारी को संग्रहीत करने के लिए एक रिलेशनल डेटाबेस।

इस दृष्टिकोण में एक साथ कई बड़े नुकसान हैं:

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

दो डेटाबेस के साथ एक संभव लेकिन बहुत अच्छा समाधान नहीं

मेटाडेटा के भंडारण के लिए हमारा समाधान । हमने यह भी सोचा और याद किया कि शुरू में यह कार्यक्षमता टारनटूल पर आधारित एक प्रोटोटाइप में लागू की गई थी और यह बहुत अच्छी तरह से निकला।

जारी रखने से पहले, मैं टारेंटूल की एक गैर-मानक परिभाषा देना चाहूंगा: टारेंटूल एक डेटाबेस नहीं है, लेकिन आपके विशिष्ट मामले के लिए एक डेटाबेस के निर्माण के लिए प्राइमेटिक्स का एक सेट है।

उपलब्ध प्राइमिटिव बॉक्स से बाहर:

अंतरिक्ष - डेटा संग्रहीत करने के लिए डेटाबेस में तालिकाओं का एक एनालॉग।
पूर्ण ACID लेनदेन।
वाल लॉग का उपयोग करते हुए प्रतिकृति अतुल्यकालिक है।
एक शार्किंग टूल जो स्वचालित रीशेयरिंग का समर्थन करता है।
संग्रहीत कार्यविधियों के लिए सुपरफास्ट LJJIT।
बड़े मानक पुस्तकालय।
LuaRocks पैकेज प्रबंधक और भी अधिक संकुल के साथ।

हमारा सीए समाधान टारनटूल पर आधारित एक संबंधपरक + ग्राफ डेटाबेस था। हमने टैरनटूल प्राइमरी के आधार पर स्वप्न मेटा सूचना रिपॉजिटरी एकत्र की है:

डेटा संग्रहण के लिए स्थान।
ACID लेनदेन - उपलब्ध थे।
अतुल्यकालिक प्रतिकृति - उपलब्ध थी।
संबंध - संग्रहीत प्रक्रियाओं पर किया जाता है।
पेड़ - संग्रहीत प्रक्रियाओं पर भी बनाया गया।

इस तरह की प्रणालियों के लिए हमारे पास क्लस्टर स्थापना क्लासिक है - लिखने के लिए एक मास्टर और पढ़ने के लिए स्केलिंग के लिए अतुल्यकालिक प्रतिकृति के साथ कई स्लिव।

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

उपकरणों से डेटा के लिए डेटाबेस चुनना

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

डेटाबेस के लिए, पढ़ने और लिखने के लिए क्षैतिज स्केलिंग, उपलब्धता और दोष सहिष्णुता, साथ ही इस डेटा सरणी के साथ काम करने के लिए तैयार विश्लेषणात्मक उपकरणों की उपलब्धता, अधिमानतः SQL पर आधारित, महत्वपूर्ण हैं। उसी समय, हम स्थिरता और एसीआईडी लेनदेन का त्याग कर सकते हैं।

यही है, कैप प्रमेय के ढांचे में, हमें एपी सिस्टम की आवश्यकता है।

अतिरिक्त आवश्यकताएं। हमें यह तय करने के लिए कई अतिरिक्त आवश्यकताएं थीं कि डेटा की विशाल मात्रा कहाँ संग्रहीत की जाएगी:

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

हमारा निर्णय । ClickHouse विशेष रूप से हमारी आवश्यकताओं के अनुकूल है - प्रतिकृति, मल्टीमास्टर, शार्किंग, एसक्यूएल समर्थन और एक मुक्त क्लस्टर के साथ समय श्रृंखला का एक स्तंभ-आधारित डेटाबेस। इसके अलावा, Mail.ru को भंडारण वॉल्यूम के सबसे बड़े ClickHouse समूहों में से एक के संचालन में कई वर्षों का सफल अनुभव है।

लेकिन कोई फर्क नहीं पड़ता कि ClickHouse कितना अच्छा है, और हमें इसके साथ समस्या है।

इन उपकरणों और उनके समाधान के लिए डेटाबेस की समस्याएं

लेखन प्रदर्शन के साथ समस्या। तुरंत एक बड़ी डेटा स्ट्रीम के लेखन प्रदर्शन के साथ एक समस्या थी। उन्हें जितनी जल्दी हो सके विश्लेषणात्मक डेटाबेस में लाने की आवश्यकता है ताकि वास्तविक समय में घटनाओं के प्रवाह का विश्लेषण करने वाले नियम किसी विशेष उपकरण के इतिहास को देख सकें और यह निर्णय ले सकें कि अलर्ट बढ़ाएं या नहीं।

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

इसलिए हम खराब रिकॉर्डिंग प्रदर्शन के साथ सामना करते हैं। रिकॉर्डिंग

समस्या का समाधान किया गया था, लेकिन सिस्टम में प्रवेश करने वाले डेटा और हमारे डेटाबेस में उनकी उपस्थिति के बीच हमें कई सेकंड का एक महत्वपूर्ण विलंब हुआ।

और यह विभिन्न एल्गोरिदम के लिए महत्वपूर्ण है जो वास्तविक समय में सेंसर से डेटा का जवाब देते हैं।

प्रदर्शन का मुद्दा पढ़ें। वास्तविक समय डाटा प्रोसेसिंग के लिए स्ट्रीम एनालिटिक्स को लगातार डेटाबेस से जानकारी की आवश्यकता होती है - ये दसियों हजारों छोटे प्रश्न हैं। औसतन, एक ClickHouse नोड एक ही समय में लगभग सौ विश्लेषणात्मक प्रश्न रखता है; यह बड़ी मात्रा में डेटा को संसाधित करने के लिए भारी भारी विश्लेषणात्मक प्रश्नों के लिए बनाया गया था। बेशक, यह सैकड़ों हजारों सेंसर से डेटा के प्रवाह में रुझानों की गणना करने के लिए उपयुक्त नहीं है।

बड़ी संख्या में अनुरोध के साथ ClickHouse अच्छी तरह से काम नहीं करता

है । हमने ClickHouse के सामने कैश डालने का फैसला किया, जिसमें पिछले 24 घंटों के लिए सबसे अधिक अनुरोधित हॉट डेटा होगा।

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

अंत में, हमें एक त्वरित क्लिकहाउस की आवश्यकता थी, जो गति के लिए स्मृति में सब कुछ संग्रहीत कर सकता है। हमें बाजार पर कोई उपयुक्त समाधान नहीं मिला, इसलिए हमने टारेंटूल प्राइमेटिव्स के आधार पर इसका निर्माण करने का निर्णय लिया:

दृढ़ता - (वाल-लॉग + स्नैपशॉट) है।
प्रदर्शन - स्मृति में सभी डेटा है।
स्केलिंग - प्रतिकृति + तेज है।
उच्च उपलब्धता - वहाँ है
समय श्रृंखला विश्लेषिकी उपकरण (समूहन, एकत्रीकरण, आदि) - संग्रहीत प्रक्रियाओं पर बनाया गया।
टीटीएल - एक पृष्ठभूमि फाइबर (कोरटाइन) के साथ संग्रहीत प्रक्रियाओं पर बनाया गया।

यह एक सुविधाजनक और उत्पादक समाधान निकला - एक उदाहरण पढ़ने के लिए 10,000 आरपीसी रखता है, जिसमें हजारों प्रश्नों के विश्लेषणात्मक प्रश्न शामिल हैं।

यहाँ परिणामी वास्तुकला है:

अंतिम वास्तुकला: ClickHouse एक विश्लेषणात्मक डेटाबेस और टारेंटूल कैश के रूप में जो 24 घंटे में डेटा संग्रहीत करता है

नया डेटा प्रकार - राज्य और उसका भंडारण

हमने सभी डेटा के लिए विशेष डेटाबेस का चयन किया, लेकिन प्लेटफ़ॉर्म विकसित हुआ और एक नया डेटा प्रकार दिखाई दिया - स्थिति। राज्य में उपकरणों और सेंसरों की वर्तमान स्थिति होती है, साथ ही धारा विश्लेषण नियमों के लिए विभिन्न वैश्विक चर भी होते हैं।

उदाहरण के लिए, कमरे में एक प्रकाश बल्ब है। इसे बंद और चालू दोनों किया जा सकता है, और आपको हमेशा इसकी वर्तमान स्थिति तक पहुंच होनी चाहिए, जिसमें नियम भी शामिल हैं। एक अन्य उदाहरण स्ट्रीम नियमों में एक चर है, उदाहरण के लिए, किसी प्रकार का काउंटर। इस प्रकार के डेटा को लगातार रिकॉर्डिंग और त्वरित पहुंच की आवश्यकता होती है, लेकिन साथ ही डेटा स्वयं एक अपेक्षाकृत छोटी राशि पर कब्जा कर लेता है।

मेटा-सूचना रिपॉजिटरी इन प्रकार के डेटा के लिए खराब रूप से अनुकूल है, क्योंकि राज्य अक्सर बदल सकता है, और हमारे मामले में रिकॉर्डिंग छत एक मास्टर तक सीमित है। दीर्घकालिक और परिचालन भंडार भी खराब रूप से अनुकूल हैं, क्योंकि हमारा राज्य पिछली बार तीन साल पहले बदल गया था, और हमारे लिए त्वरित रीड एक्सेस होना महत्वपूर्ण है।

अर्थात्, उस डेटाबेस के लिए जिसमें राज्य संग्रहीत है, पढ़ने और लिखने के लिए क्षैतिज स्केलिंग, उच्च उपलब्धता और गलती सहिष्णुता महत्वपूर्ण है, जबकि मूल्यों / दस्तावेजों के स्तर पर स्थिरता की आवश्यकता है। आप समग्र स्थिरता और एसीआईडी लेनदेन पर आकर्षित हो सकते हैं।

एक उपयुक्त समाधान किसी भी कुंजी मान या एक दस्तावेज़ डेटाबेस हो सकता है: एक छायांकित रेडिस क्लस्टर, MongoDB, या फिर टारनटूल।

टारनटूल पेशेवरों:

टारनटूल का उपयोग करने का यह सबसे लोकप्रिय तरीका है।
क्षैतिज स्केलिंग - अतुल्यकालिक प्रतिकृति + तेज है।
दस्तावेज़ स्तर पर संगति - है।

नतीजतन, अब हमारे पास तीन टारनटूल हैं, जिनका हम पूरी तरह से अलग-अलग मामलों के लिए उपयोग करते हैं: मेटा-सूचना, उपकरणों से डेटा पढ़ने और स्थिति डेटा संग्रहीत करने के लिए कैश।

IoT प्लेटफ़ॉर्म के लिए डेटाबेस कैसे चुनें

एक सार्वभौमिक डेटाबेस मौजूद नहीं है।
प्रत्येक प्रकार के डेटा का अपना डेटाबेस होता है जो इसके लिए सबसे उपयुक्त होता है।
कभी-कभी आपके लिए आवश्यक डेटाबेस बाजार पर उपलब्ध नहीं हो सकता है।
टारेंटूल एक विशेष डेटाबेस के लिए आधार के रूप में उपयुक्त है।

यह बात सबसे पहले Mail.ru Cloud Solutions द्वारा @ डेटाबेस डेटाबेस मीट में की गई थी। अन्य प्रदर्शनों का एक वीडियो देखें और Tele.ru इवेंट घोषणाओं के लिए साइन अप करें Mail.ru समूह पर Kubernetes के आसपास ।

और क्या पढ़ें :

IIoT प्लेटफॉर्म में डेटाबेस: Mail.ru क्लाउड सॉल्यूशंस कई डिवाइसों के डेटा के पेटाबाइट्स के साथ कैसे काम करता है