सभी एप्लिकेशन डेटा पर निर्भर करते हैं, फिर भी एप्लिकेशन डेवलपर्स डेटाबेस के बारे में सोचना पसंद नहीं करते। किसी विशेष डेटाबेस के आंतरिक और क्वेरी भाषा को सीखना संज्ञानात्मक भार जोड़ता है, और संदर्भ स्विचिंग की आवश्यकता होती है जो उत्पादकता से अलग हो जाती है। फिर भी, सफल अनुप्रयोगों को उत्तरदायी, लचीला और स्केलेबल होना चाहिए - सभी विशेषताएँ जो डेटाबेस की पसंद से निर्धारित होंगी।
तब, एक एप्लिकेशन डेवलपर को इन विचारों को कैसे संतुलित करना चाहिए? क्या होगा यदि हम डेवलपर्स से डेटाबेस-विशिष्ट मुहावरों को सीखने की अपेक्षा करने के बजाय, डेवलपर-अनुकूल मुहावरों में डेटा सेवा प्रदान करके शेष राशि को स्थानांतरित कर सकते हैं?
Stargate प्रोजेक्ट में, के साथ काम करने के लिए डिज़ाइन किया गया ओपन-सोर्स API डेटा गेटवे, हम अपने आगामी के बारे में सार्वजनिक रूप से बात करना शुरू करने के लिए उत्साहित हैं जो JSON-उन्मुख डेवलपर्स को उनकी शर्तों पर पूरा करता है। न केवल JSON-उन्मुख डेवलपर्स के लिए यह अच्छी खबर है, बल्कि जिस तकनीक का हमने अनुसरण किया है, वह डेटा सेवाओं का उत्पादन करने के लिए डेटा एपीआई और उन्नत डेटा मॉडलिंग का लाभ उठाने के लिए एक नया डिज़ाइन पैटर्न बनाती है।
इस लेख में, मैं चर्चा करूँगा कि स्टारगेट के साथ कैसेंड्रा का उपयोग करके डेवलपर-अनुकूल मुहावरों को कैसे प्रदान किया जाए, और हम JSON के लिए ऐसा करने के लिए कैसे काम कर रहे हैं।
डेटा मॉडल: इंटरऑपरेबिलिटी बनाम मुहावरा
शुरुआती दिनों में, कैसंड्रा को कभी-कभी "इंडेक्स बनाने की मशीन" के रूप में वर्णित किया गया था। यह कैसंड्रा की अंतर्निहित लचीलापन और लचीलेपन का एक वसीयतनामा था, एक ऐसी मिट्टी जिसमें से अधिक मजबूत संरचनाओं को ढाला जा सकता था। कैसंड्रा आज अधिक संभावनाओं वाली एक समृद्ध मिट्टी है। यह न केवल एक बेहतरीन डेटाबेस है, बल्कि यह डेटाबेस बनाने के लिए एक बेहतरीन मशीन भी है। यहाँ Stargate प्रोजेक्ट में, हम JSON API का उपयोग डेटाबेस विकास में एक नए प्रतिमान के पहले उदाहरण के रूप में साबित करने के लिए कर रहे हैं।
एक डेटाबेस का दूसरे से निर्मित होना असामान्य नहीं है। यहां तक कि MongoDB के ऊपर बनाया गया है, यदि आप पर्याप्त गहराई तक खोदते हैं। AWS पर्दे के पीछे MySQL के व्यापक उपयोग के लिए जाना जाता है, जिसमें शामिल है। इसलिए कैसेंड्रा का उपयोग करने का विचार, इसकी अंतर्निहित मापनीयता और प्रदर्शन के साथ, अन्य डेटा सिस्टम के लिए बिल्डिंग ब्लॉक के रूप में समझ में आता है।
फिर भी एप्लिकेशन डेवलपर वास्तव में डेटाबेस से इंटरैक्ट नहीं करते हैं। भले ही आपका संगठन अपने स्वयं के डेटाबेस इन्फ्रास्ट्रक्चर का प्रबंधन करता है और उस इन्फ्रास्ट्रक्चर के खिलाफ एप्लिकेशन बनाता है, पहला कदम आम तौर पर आपके एप्लिकेशन के लिए आवश्यक डेटा मॉडल को परिभाषित और कार्यान्वित करना है।
वे डेटा मॉडल एप्लिकेशन और डेटाबेस के बीच मध्यस्थता करते हैं। कुछ मायनों में, डेटा मॉडलिंग एक डेटाबेस को सीमित करता है; यह विकृत लेता है, और इस प्रकार सामान्य-उद्देश्य, मिट्टी और इसे किसी विशेष अनुप्रयोग मुहावरे के लिए निर्मित कुछ उद्देश्य में ढालता है। हम कुछ मुहावरे के लिए इंटरऑपरेबिलिटी का त्याग करते हैं।
क्या मुहावरेदार चीज़ के लिए व्यापार करना और इंटरऑपरेबल कुछ छोड़ना एक अच्छा विचार है? यदि आप औसत को मात देना चाहते हैं, तो इसका उत्तर जोरदार "हां" है। डेटाबेस चुनते समय हम इस तरह से ज्यादा नहीं सोचते हैं, लेकिन प्रोग्रामिंग भाषाओं को चुनते समय हमने इस तरह से लंबे समय से सोचा है।
यह विचार दशकों पहले था जब उन्होंने समझाया था कि कैसे वायावेब ने पहले व्यापक रूप से सफल, वेब-आधारित ई-कॉमर्स प्लेटफॉर्म बनाने के लिए शुरुआती डॉट-कॉम की दौड़ जीती थी। जरूरी नहीं कि वायावेब सबसे तेज या सबसे स्केलेबल ई-कॉमर्स प्लेटफॉर्म था। ग्राहम के शब्दों में, यह "उचित रूप से कुशल" था। इसके बजाय, ग्राहम का तर्क है कि, प्रोग्रामिंग भाषाओं के लिए, मशीन-पठनीय से मानव-पठनीय के पैमाने पर, अधिक मानव-पठनीय (और इस प्रकार उच्च-स्तरीय) भाषाएं अधिक शक्तिशाली हैं क्योंकि वे डेवलपर उत्पादकता में सुधार करती हैं। और वायावेब के समय, ग्राहम ने सोचा कि सबसे शक्तिशाली भाषा थी। ग्राहम के तर्क का सार यह है:
"हमारी परिकल्पना यह थी कि यदि हम अपना सॉफ़्टवेयर लिस्प में लिखते हैं, तो हम अपने प्रतिस्पर्धियों की तुलना में तेज़ी से सुविधाएँ प्राप्त करने में सक्षम होंगे, और अपने सॉफ़्टवेयर में ऐसे कार्य भी करने में सक्षम होंगे जो वे नहीं कर सकते थे। और क्योंकि लिस्प इतना उच्च स्तर का था, हमें एक बड़ी विकास टीम की आवश्यकता नहीं होगी, इसलिए हमारी लागत कम होगी। यदि ऐसा होता, तो हम कम पैसे में बेहतर उत्पाद पेश कर सकते थे और फिर भी लाभ कमा सकते थे। हम सभी उपयोगकर्ताओं को प्राप्त कर लेंगे, और हमारे प्रतिस्पर्धियों को कोई नहीं मिलेगा और अंततः व्यवसाय से बाहर हो जाएगा।
डेवलपर उत्पादकता अनलॉक करना
ग्राहम ने उन शब्दों को 20 साल पहले लिखा था, और डेवलपर उत्पादकता उत्तर सितारा बनी हुई है जो प्रौद्योगिकी में बहुत से नवाचारों का मार्गदर्शन करती है। जहाँ ग्राहम उच्च-स्तरीय भाषाओं की शक्ति के बारे में बात करते हैं, हम उसी अवधारणा को व्यक्त करते हैं जो डेवलपर्स को ऐसे उपकरण प्रदान करते हैं जो उनके सॉफ़्टवेयर विकास अनुभव के लिए अधिक मुहावरेदार हैं।
ग्राहम लिस्प (ठीक ही) की प्रशंसा करते हैं, और डॉट-कॉम के समय से, हमने नई उच्च-स्तरीय भाषाओं का प्रसार देखा है: रूबी और रस्ट, एक जोड़े का नाम। हमने स्विफ्ट, फ्लटर और डार्ट जैसी मोबाइल डिवाइस डेवलपर भाषाओं और फ्रेमवर्क के जन्म और प्रसार को भी देखा है।
तो C और C++ जैसी भाषाएं अभी भी महत्वपूर्ण क्यों हैं? C के बारे में पुराना चुटकुला एक महत्वपूर्ण सत्य रखता है: "असेंबली भाषा की शक्ति को असेंबली भाषा के उपयोग में आसानी के साथ जोड़ना।" यदि आप एक कंपाइलर लिखना चाहते हैं, तो आपको मशीनी भाषा मुहावरे के करीब और प्राकृतिक भाषा मुहावरे से दूर जाने की जरूरत है।
दूसरे शब्दों में, अन्य खूबियों में, C और C++ नई भाषाओं के निर्माण की मशीन हैं। लिस्प की ग्राहम की प्रशंसा में जो बात नज़रअंदाज़ करना आसान है वह यह है कि लिस्प में "भाषाओं के निर्माण के लिए मशीन" की कुछ विशेषताएं भी हैं।
मैक्रोज़ की अवधारणा को पेश करने के लिए लिस्प पहली व्यापक रूप से इस्तेमाल की जाने वाली भाषा थी, और यह अक्सर मैक्रोज़ की अवधारणा होती है जो उन नए लोगों को लिस्प तक ले जाती है। एक बार जब आप मैक्रोज़ को समझ जाते हैं, तो आप समझ जाते हैं कि लिस्प एक भाषा की तुलना में एक मेटा-लैंग्वेज अधिक है और मैक्रोज़ का उपयोग किसी विशिष्ट समस्या डोमेन के लिए एक उद्देश्य-निर्मित भाषा बनाने के लिए किया जा सकता है।
मैक्रोज़ का प्रारंभिक सेट डिजाइन करना और बनाना कठिन, बौद्धिक रूप से चुनौतीपूर्ण काम है। लेकिन एक बार ग्राहम और वायावेब टीम ने ऐसा किया, वास्तव में उनके पास काम करने के लिए एक ई-कॉमर्स प्रोग्रामिंग भाषा थी, और इसने डेवलपर उत्पादकता को अनलॉक कर दिया जिससे वे अपनी प्रतिस्पर्धा से आगे निकल गए।
बीस साल बाद, यह सब प्रोग्रामिंग भाषाओं के संदर्भ में पर्याप्त स्पष्ट प्रतीत होता है। तो, डेटाबेस की दुनिया में क्या हुआ है? संक्षिप्त उत्तर यह है कि डेटाबेस अधिक धीरे-धीरे विकसित हुए हैं।
डेटा एपीआई क्रांति
यदि सारणीबद्ध डेटा डेटाबेस की दुनिया की असेंबली भाषा है, तो SQL क्वेरी भाषाओं की C/C++ है। हमने एक ऐसे युग में सारणीबद्ध डेटा संरचनाएं और डेटा सामान्यीकरण की अवधारणा विकसित की जब कंप्यूटिंग और भंडारण महंगा था, और उपयोग के मामलों के लिए जो अपेक्षाकृत कम स्कीमा परिवर्तनों के साथ अच्छी तरह से परिभाषित थे। उस संदर्भ में, किसी भी प्रकार के पैमाने पर कुशलता से संचालित करने के लिए, डेटाबेस को कंप्यूटर को संग्रहीत करने और जानकारी तक पहुंचने के तरीके की बारीकी से नकल करने की आवश्यकता होती है।
आज की दुनिया इसके विपरीत है, जिससे पहले का समय तुलनात्मक रूप से पुरातन प्रतीत होता है: गणना और भंडारण लागत अत्यधिक कमोडिटीकृत होती है, लेकिन मशीन लर्निंग और आर्टिफिशियल इंटेलिजेंस के साथ संयुक्त वास्तविक समय के डेटा की दुनिया में, उपयोग के मामले ओपन-एंडेड होते हैं और स्कीमा परिवर्तन होते हैं। अक्सर।
डेटाबेस प्रौद्योगिकी में सबसे हालिया क्रांति NoSQL क्रांति थी, जो संबंधपरक डेटाबेस दुनिया के उच्च पुजारियों द्वारा निर्धारित सारणीबद्ध, सामान्यीकृत डेटा के कैनन की सीधी प्रतिक्रिया थी। जब हम "NoSQL क्रांति" कहते हैं, तो हम 2004 से उस अवधि का उल्लेख करते हैं, जब Google ने अपना जारी किया था, 2007 तक, जब Amazon ने अपना प्रकाशित किया था।
इस अवधि से जो उभरा वह डेटाबेस का एक परिवार था जिसने दो पोषित संबंधपरक सिद्धांतों को छोड़ कर अभूतपूर्व गति, मापनीयता और लचीलापन हासिल किया: NoSQL डेटाबेस ने डेटा सामान्यीकरण पर असामान्य डेटा का समर्थन किया, और लेन-देन की स्थिरता पर अंतिम स्थिरता का समर्थन किया। कैसेंड्रा, पहली बार 2008 में रिलीज़ हुई, इस क्रांति से बाहर निकली।
डेटा एपीआई डेटाबेस तकनीक में अगली बड़ी क्रांति होगी, एक ऐसी क्रांति जो अभी शुरू ही हुई है। डेटाबेस की दुनिया में परिवर्तन प्रोग्रामिंग भाषाओं और अनुप्रयोग विकास में परिवर्तन से पीछे रह जाते हैं। इसलिए जबकि RESTful API कुछ समय के लिए रहे हैं, और वितरित सेवा-उन्मुख अनुप्रयोगों के लिए आर्किटेक्चर में प्रवेश करने में मदद की है, हम केवल डेटा API को एप्लिकेशन इंफ्रास्ट्रक्चर के एक महत्वपूर्ण भाग के रूप में प्रकट होते हुए देखना शुरू कर रहे हैं।
इस क्रांति के महत्व को समझने के लिए, और कैसे, पॉल ग्राहम की उद्घोषणा के 20 साल बाद, डेटाबेस दुनिया अंततः डेवलपर उत्पादकता पर वितरित कर रही है, आइए स्टारगेट की अपनी कहानी देखें। यह इंटरऑपरेबल बनाम मुहावरेदार विषय पर लौटने से शुरू होता है।
स्टारगेट: एक उच्च निष्ठा, मुहावरेदार डेवलपर अनुभव
जब हमने फैसला किया कि कैसेंड्रा पारिस्थितिकी तंत्र को डेटा गेटवे की आवश्यकता है, तो हमने तात्कालिकता के साथ स्टारगेट एपीआई के मूल सेट का निर्माण किया। इसका मतलब एक अखंड वास्तुकला था; मोनोलिथ निर्माण में तेज़ होते हैं, फिर भी हमेशा बेहतर नहीं होते। हमने कैसेंड्रा क्वेरी लैंग्वेज (CQL) API, REST API और RESTful Document API के साथ लॉन्च किया। हमने जल्दी से एक अतिरिक्त एपीआई के रूप में ग्राफकलाइन को जोड़ा। आज तक, स्टारगेट इंटरऑपरेबल रहा है; Stargate से सब कुछ एक देशी CQL डेटा मॉडल का उपयोग करके संग्रहीत किया जाता है, इसलिए सिद्धांत रूप में, आप किसी भी API से किसी भी तालिका को क्वेरी कर सकते हैं।
हमने सीखा है कि व्यवहार में, वास्तव में कोई भी ऐसा नहीं करता है। डेवलपर्स अपने विशेष मुहावरे से चिपके रहते हैं। इंटरऑपरेबिलिटी का पक्ष लेकर, हमने कैसेंड्रा-इस्म्स को डेवलपर अनुभव में उड़ा दिया, इस प्रकार डेवलपर उत्पादकता को बाधित किया। क्योंकि स्टार्गेट के मूल संस्करण के लिए डेवलपर्स को कैसेंड्रा के विस्तृत-स्तंभ सारणीबद्ध डेटा संरचनाओं को समझने की आवश्यकता थी, कुंजीस्थानों और विभाजनों को समझने के लिए, हमने मशीन मुहावरे के बहुत करीब और मानव मुहावरे से बहुत दूर लंगर डाला है।
इंटरऑपरेबिलिटी ट्रैप उद्देश्य-निर्मित डिजाइन सोच पर सामान्य उद्देश्य का पक्ष लेने के लिए है। हमने उद्देश्य-निर्मित के संदर्भ में सोचने के लिए प्रेरित किया है, जो अभिव्यक्ति की अधिक विशिष्ट विधा के लिए कुछ सामान्य क्षमता का व्यापार करता है, हमें मानव मुहावरे के करीब और मशीन मुहावरे से और दूर ले जाता है। और इसलिए हमने सोचना शुरू किया: क्या हम कैसेंड्रा के नोएसक्यूएल फाउंडेशन (पैमाना, उपलब्धता और प्रदर्शन) के गुणों को बनाए रखते हुए एक उच्च-विश्वस्तता मुहावरेदार डेवलपर अनुभव प्रदान कर सकते हैं?
कुंजी डेटा मॉडलिंग में निहित है। कैसंड्रा को "डेटाबेस के लिस्प" में बदलने के लिए, हमें एक डेटा मॉडल की आवश्यकता थी जो लिस्प मैक्रोज़ के अनुरूप एक उद्देश्य की पूर्ति कर सके, साथ में एक स्टारगेट एपीआई जो डेवलपर्स को उस डेटा मॉडल के साथ मुहावरेदार तरीके से बातचीत करने में सक्षम बनाएगी। हमने JSON के साथ शुरुआत की, एप्लिकेशन डेवलपर्स के बीच डेटा संरचनाओं का सबसे बड़ा सामान्य विभाजक, और इस तरह Stargate के लिए JSON API का निर्माण शुरू किया। तब हमें यह पता लगाना था कि कैसेंड्रा में JSON को सबसे अच्छा कैसे बनाया जाए।
Stargate के पास पहले से ही एक दस्तावेज़ API है, लेकिन Stargate के मूल दस्तावेज़ API में, हमने एक डेटा मॉडल का उपयोग किया एक JSON दस्तावेज़ को कैसेंड्रा तालिका के रूप में प्रस्तुत करने के लिए। यह मॉडल एक कैसेंड्रा तालिका में एक दस्तावेज़ को कई पंक्तियों में मैप करता है और इंटरऑपरेबिलिटी को संरक्षित करता है। यदि आप परिणामी तालिका को क्वेरी करने के लिए CQL का उपयोग करते हैं, तो आपको सार्थक परिणाम मिलेंगे।
इस मूल श्रेडिंग डेटा मॉडल में डाउनसाइड्स हैं। यह किसी दस्तावेज़ के बारे में मेटाडेटा को संरक्षित नहीं करता है। उदाहरण के लिए, सरणियों वाले किसी भी दस्तावेज़ के लिए, एक बार दस्तावेज़ लिखे जाने के बाद, हम दस्तावेज़ का पूरी तरह से निरीक्षण किए बिना सरणी आकार के बारे में कुछ भी नहीं जानते हैं। अधिक महत्वपूर्ण रूप से, हम अनुक्रमण के बारे में कैसेंड्रा की अपेक्षाओं से अलग हो गए हैं। कैसेंड्रा पंक्तियों पर अनुक्रमित करता है, लेकिन अब हमने अपने दस्तावेज़ को कई पंक्तियों में फैला दिया है, जिससे दस्तावेज़ों का मूल कैसेंड्रा सूचकांक असंभव हो गया है।
कैसेंड्रा को JSON के लिए एक उपयुक्त स्टोरेज इंजन बनाने के लिए, हमें एक नए डेटा मॉडल की आवश्यकता होगी, जो श्रेडिंग से बेहतर हो। हमने इसे "सुपर श्रेडिंग" कहा। आप दिसंबर में आरोन मॉर्टन के में सुपर श्रेडिंग के बारे में अधिक जान सकते हैं, लेकिन यहां एक टीज़र है: हम कैसेंड्रा की विस्तृत-स्तंभ प्रकृति का लाभ उठाते हुए प्रति पंक्ति एक दस्तावेज़ को संग्रहीत करते हैं, यह जानते हुए कि कैसेंड्रा पंक्ति बहुत बड़ी भी संभाल सकती है दस्तावेज़।
हमारे पास उस पंक्ति में स्तंभों का एक सेट भी है जो स्पष्ट रूप से JSON दस्तावेज़ की मानक मेटाडेटा विशेषताओं को संग्रहीत करने के लिए है। अब हमारे पास कुछ और आसानी से अनुक्रमित करने योग्य है, साथ ही मेटाडेटा को संरक्षित करने और पुनर्प्राप्त करने का साधन भी है।
कैसेंड्रा में वापस योगदान
हाँ, यह सब बड़े पैमाने पर काम करने के लिए हमें कैसेंड्रा में कुछ अंतर्निहित परिवर्तनों की आवश्यकता होगी। कैसेंड्रा 5 में ऐप्पल का योगदान देने वाला एकॉर्ड, डेटा परिवर्तनों को अधिक लेनदेन तरीके से संभालने में हमारी मदद करेगा। स्टोरेज-अटैच्ड इंडेक्सिंग (SAI) और ग्लोबल सॉर्ट, जो , हमें JSON दस्तावेज़ों के विरुद्ध श्रेणीबद्ध प्रश्नों को अधिक प्रभावी तरीके से संभालने में मदद करेगा।
कैसेंड्रा सॉफ्टवेयर का एक स्थिर टुकड़ा नहीं है; यह एक जीवंत और उभरता हुआ ओपन-सोर्स प्रोजेक्ट है। इसलिए हम डेटाबेस पक्ष में परिवर्तनों को बढ़ावा देने के लिए क्लाइंट-साइड उभरने वाली आवश्यकताओं का उपयोग करने की एक पुरानी कैसंड्रा परंपरा को भी जारी रख रहे हैं। उपयोगकर्ता की जरूरतों ने एकॉर्ड, एसएआई और ग्लोबल सॉर्ट के प्रस्तावों को प्रेरित किया है। ये न केवल Stargate के JSON API को बेहतर बनाएंगे बल्कि कैसेंड्रा को बेहतर बनाएंगे। यह एक महान अनुस्मारक है कि डेटा इंजीनियर और एप्लिकेशन डेवलपर दो अलग-अलग समुदाय नहीं हैं, बल्कि विस्तारित कैसेंड्रा समुदाय के मानार्थ समूह हैं।
और JSON सिर्फ पहला कदम है। अनिवार्य रूप से, हमने एक दस्तावेज़ डेटाबेस का निर्माण किया होगा, जिसे आप कैसेंड्रा, स्टारगेट और एक यथोचित कुशल कैसेंड्रा डेटा मॉडल से JSON एपीआई के माध्यम से इंटरैक्ट करते हैं। सुपर श्रेडिंग हमारा मैक्रो है। यह दृष्टिकोण डेटाबेस बनाने के लिए कैसेंड्रा को एक मशीन में बदल देता है।
क्या इस दृष्टिकोण का कैसंड्रा के अलावा किसी अन्य डेटाबेस द्वारा अनुसरण किया जा सकता है? आसानी से नहीं, और यहाँ क्यों है। ऊष्मप्रवैगिकी के दूसरे नियम का एक प्रकार का डेटाबेस एनालॉग है जो कैसेंड्रा के पक्ष में काम करता है। हम किसी ऐसी चीज से शुरू करते हैं जो तेज, स्केलेबल और लचीला है, लेकिन डेवलपर्स के लिए बहुत मुहावरेदार नहीं है। उचित दक्षता की बाधाओं के भीतर, हम डेवलपर्स को प्रस्तुत करने के लिए अधिक मुहावरेदार इंटरफ़ेस के लिए उस गति, पैमाने और लचीलेपन में से कुछ का व्यापार करते हैं। जो आसानी से नहीं किया जा सकता वह है उल्टी दिशा में जाना। किसी ऐसी चीज से शुरू करना जो बेहद मुहावरेदार है और फिर यह पता लगाने की कोशिश करना कि इसे कैसे तेज, स्केलेबल और लचीला बनाया जाए, यह एक कठिन काम है जो शायद संभव भी नहीं है।
वह थर्मोडायनामिक सिद्धांत है कि डेटा एपीआई नई डेटाबेस क्रांति क्यों है, और कैसेंड्रा डेटाबेस है जो इस क्रांति को शक्ति प्रदान करेगा।
