यह डेटाबेस जल रहा है...

मैं एक तकनीकी कहानी बताता हूँ.

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

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


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

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

रोजमर्रा के सिंक का डिज़ाइन

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

इसका एक उत्कृष्ट उदाहरण एक उपयोगकर्ता को घूरना है spinner.gif, सोच रहा था कि आख़िर काम कब पूरा होगा। डेवलपर को एहसास हो गया होगा कि प्रक्रिया शायद अटक गई है और GIF स्क्रीन से कभी गायब नहीं होगा। यह एनीमेशन किसी कार्य के निष्पादन का अनुकरण करता है, लेकिन इसकी स्थिति से संबंधित नहीं है। ऐसे मामलों में, कुछ तकनीकी विशेषज्ञ उपयोगकर्ता के भ्रम की सीमा पर आश्चर्यचकित होकर अपनी आँखें घुमाना पसंद करते हैं। हालाँकि, ध्यान दें कि उनमें से कितने लोग घूमती हुई घड़ी की ओर इशारा करते हैं और कहते हैं कि यह वास्तव में स्थिर है?

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

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

दोनों के नाम में अग्नि शब्द है। एक बात मुझे अच्छी तरह याद है. मेरे लिए दूसरी चीज़ एक अलग तरह की आग है. मुझे उनके नाम बताने की कोई जल्दी नहीं है, क्योंकि एक बार जब मैं ऐसा करूंगा, तो हमें पहली बड़ी समस्या का सामना करना पड़ेगा: नाम।

पहले वाले को बुलाया जाता है फायरबेस रीयल-टाइम डेटाबेस, और दूसरा - फायरबेस क्लाउड फायरस्टोर. ये दोनों के उत्पाद हैं फायरबेस सुइट गूगल। उनके एपीआई क्रमशः बुलाए जाते हैं firebase.database(…) и firebase.firestore(…).

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

क्योंकि आपको संकेत करने की आवश्यकता है Firebase फायरबेस प्रश्न में, और इस firestore फायरबेस के बारे में एक प्रश्न में, कम से कम आपको कुछ साल पहले स्टैक ओवरफ्लो पर यह समझाने के लिए।

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

नाशकारी विजय

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

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

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

यहां हमें फायरस्टोर के अस्तित्व के पहले लक्षण दिखाई देने लगते हैं। मैं गलत हो सकता हूं, लेकिन मुझे संदेह है कि Google के प्रबंधन में उच्च स्तर के किसी व्यक्ति ने खरीदारी के बाद फायरबेस को देखा और बस इतना कहा, “नहीं, हे भगवान, नहीं। यह अस्वीकार्य है। बस मेरे नेतृत्व में नहीं।"

वह अपने कक्ष से प्रकट हुए और घोषणा की:

“एक बड़ा JSON दस्तावेज़? नहीं। आप डेटा को अलग-अलग दस्तावेज़ों में विभाजित करेंगे, जिनमें से प्रत्येक का आकार 1 मेगाबाइट से अधिक नहीं होगा।

ऐसा लगता है कि ऐसी सीमा किसी भी पर्याप्त रूप से प्रेरित उपयोगकर्ता आधार के साथ पहली मुठभेड़ में टिक नहीं पाएगी। तुम्हें पता है यह है. उदाहरण के लिए, कार्यस्थल पर, हमारे पास डेढ़ हजार से अधिक प्रस्तुतियाँ हैं, और यह पूरी तरह से सामान्य है।

इस सीमा के साथ, आप इस तथ्य को स्वीकार करने के लिए मजबूर होंगे कि डेटाबेस में एक "दस्तावेज़" किसी भी ऑब्जेक्ट जैसा नहीं होगा जिसे उपयोगकर्ता दस्तावेज़ कह सकता है।

"सरणी की सारणी जिसमें पुनरावर्ती रूप से अन्य तत्व शामिल हो सकते हैं? नहीं। सारणी में केवल निश्चित-लंबाई वाली वस्तुएं या संख्याएं होंगी, जैसा कि भगवान का इरादा था।"

इसलिए यदि आप जियोजसन को अपने फायरस्टोर में डालने की उम्मीद कर रहे थे, तो आप पाएंगे कि यह संभव नहीं है। कुछ भी गैर-एक-आयामी स्वीकार्य नहीं है। मुझे आशा है कि आपको JSON के भीतर Base64 और/या JSON पसंद आएगा।

“JSON HTTP, कमांड लाइन टूल्स या एडमिन पैनल के माध्यम से आयात और निर्यात करता है? नहीं। आप केवल Google क्लाउड स्टोरेज में डेटा निर्यात और आयात कर पाएंगे। मुझे लगता है कि अब इसे यही कहा जाता है। और जब मैं "आप" कहता हूं, तो मैं केवल उन लोगों को संबोधित कर रहा हूं जिनके पास प्रोजेक्ट ओनर की साख है। बाकी सभी लोग जा सकते हैं और टिकट बना सकते हैं।"

जैसा कि आप देख सकते हैं, फायरबेस डेटा मॉडल का वर्णन करना आसान है। इसमें एक विशाल JSON दस्तावेज़ है जो JSON कुंजियों को URL पथों के साथ जोड़ता है। यदि आप साथ लिखते हैं HTTP PUT в / फायरबेस निम्नलिखित है:

{
  "hello": "world"
}

फिर GET /hello वापसी करेंगे "world". मूलतः यह बिल्कुल वैसे ही काम करता है जैसी आप अपेक्षा करते हैं। फायरबेस ऑब्जेक्ट्स का संग्रह /my-collection/:id JSON शब्दकोश के समतुल्य {"my-collection": {...}} जड़ में, जिसकी सामग्री उपलब्ध है /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

यह ठीक काम करता है यदि प्रत्येक इंसर्ट में टकराव-मुक्त आईडी हो, जिसके लिए सिस्टम के पास एक मानक समाधान हो।

दूसरे शब्दों में, डेटाबेस 100% JSON(*) संगत है और CouchDB जैसे HTTP के साथ बढ़िया काम करता है। लेकिन मूल रूप से आप इसका उपयोग वास्तविक समय एपीआई के माध्यम से करते हैं जो वेबसोकेट, प्राधिकरण और सदस्यता को सारांशित करता है। व्यवस्थापक पैनल में दोनों क्षमताएं हैं, जो वास्तविक समय संपादन और JSON आयात/निर्यात दोनों की अनुमति देती हैं। यदि आप अपने कोड में भी ऐसा ही करते हैं, तो आपको आश्चर्य होगा कि कितना विशेष कोड बर्बाद हो जाएगा जब आपको एहसास होगा कि पैच और डिफ JSON लगातार स्थिति को संभालने के 90% नियमित कार्यों को हल करता है।

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

उन्होंने एक वास्तविक समय NoSQL डेटाबेस लिया और इसे ऑटो-जॉइन और एक अलग गैर-JSON कॉलम के साथ एक धीमी गैर-एसक्यूएल में बदल दिया। GraftQL जैसा कुछ.

हॉट जावा

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

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

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

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

मैं डेटा संरचनाओं के बारे में कुछ बातें समझता हूं। मैं निश्चित रूप से "एक बड़े JSON ट्री में सब कुछ" अवधारणा को डेटाबेस से बड़े पैमाने की संरचना के किसी भी अर्थ को अमूर्त करने के प्रयास के रूप में देखता हूं। सॉफ़्टवेयर से यह अपेक्षा करना कि वह किसी भी संदिग्ध डेटा संरचना फ्रैक्टल से आसानी से निपट लेगा, बिल्कुल पागलपन है। मुझे यह कल्पना करने की ज़रूरत नहीं है कि चीजें कितनी बुरी हो सकती हैं, मैंने कठोर कोड ऑडिट किए हैं और मैंने वो चीज़ें देखीं जिनके बारे में आप लोगों ने कभी सपने में भी नहीं सोचा था. लेकिन मैं यह भी जानता हूं कि अच्छी संरचनाएं कैसी दिखती हैं, उनका उपयोग कैसे करें и ऐसा क्यों किया जाना चाहिए?. मैं एक ऐसी दुनिया की कल्पना कर सकता हूं जहां फायरस्टोर तर्कसंगत लगेगा और इसे बनाने वाले लोग सोचेंगे कि उन्होंने अच्छा काम किया है। लेकिन हम इस दुनिया में नहीं रहते.

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

यदि आप इसके बारे में जानकारी के लिए Google डॉक्स खोजते हैं, तो उम्मीद है कि आपका ध्यान BigTable और BigQuery जैसी किसी चीज़ की ओर इंगित किया जाएगा। हालाँकि, ये सभी समाधान इतने सघन कॉर्पोरेट बिक्री शब्दजाल के साथ हैं कि आप तुरंत पीछे मुड़कर कुछ और तलाशना शुरू कर देंगे।

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

(*) यह एक मजाक है, ऐसी कोई बात नहीं है 100% JSON संगत.

विज्ञापन के अधिकार पर

ढूंढ रहे हैं VDS डिबगिंग परियोजनाओं के लिए, विकास और होस्टिंग के लिए एक सर्वर? आप निश्चित रूप से हमारे ग्राहक हैं 🙂 विभिन्न कॉन्फ़िगरेशन, एंटी-डीडीओएस और विंडोज लाइसेंस के सर्वर के लिए दैनिक मूल्य पहले से ही कीमत में शामिल हैं।

स्रोत: www.habr.com