MongoDB और PostgreSQL का एक साथ उपयोग करना

Question

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

उस ने कहा, कुछ झुर्रियाँ (आश्चर्य, आश्चर्य) हैं। जबकि कुछ झुर्रियाँ परियोजना के लिए काफी विशिष्ट हैं, मेरा मानना ​​है कि कुछ सामान्य अवलोकन और प्रश्न हैं जो सामने आए हैं, जिनमें एक कैनोनिकल उत्तर नहीं है (जो मुझे मिल सकता है, वैसे भी) और यह एक व्यापक समस्या डोमेन पर लागू होता है । यहाँ बहुत कुछ है और मुझे यकीन नहीं है कि यह StackExchange Q & A प्रारूप के लिए एक अच्छा फिट है, लेकिन मुझे लगता है कि यह एक) एक जवाब देने योग्य प्रश्न है और b) गैर-विशिष्ट पर्याप्त है ताकि यह समुदाय को लाभान्वित कर सके। मेरे कुछ विचार मेरे लिए विशिष्ट हैं, लेकिन मुझे लगता है कि प्रश्न का उपयोग SQL बनाम NoSQL बनाम दोनों के साथ सामना करने वाले किसी के लिए भी हो सकता है।

पृष्ठ - भूमि:

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

TL; DR: मुझे लगता है कि नीचे # 5 गंध परीक्षण पास करता है। क्या आप? क्या किसी के पास एकल एप्लिकेशन में SQL और NOSQL के एकीकरण के साथ अनुभव है? मैंने समस्या के इस वर्ग के सभी संभावित दृष्टिकोणों को नीचे सूचीबद्ध करने का प्रयास किया। क्या मैंने एक आशाजनक विकल्प को याद किया है?

जटिलताओं:

• दस्तावेजों के कई अलग-अलग वर्ग हैं। आवश्यकताएं पहले से ही दर्जनों विभिन्न दस्तावेजों के लिए कॉल करती हैं। यह संख्या केवल कभी भी बढ़ जाएगी। सबसे अच्छा संभव मामला वह होगा जिसमें हम एक साधारण डोमेन विशिष्ट भाषा, कोड पीढ़ी और एक लचीली स्कीमा का लाभ उठा सकते हैं ताकि डोमेन विशेषज्ञ डीबीए या प्रोग्रामर के हस्तक्षेप के बिना नए दस्तावेज़ वर्गों को जोड़ सकें। (नोट: पहले से ही पता है कि हम ग्रीनस्पून के दसवें नियम से बाहर रह रहे हैं )
• पिछले सफल लेखन की अखंडता परियोजना की एक केंद्रीय आवश्यकता है। डेटा व्यापार महत्वपूर्ण होगा। लिखने पर पूर्ण ACID शब्दार्थ का त्याग किया जा सकता है, बशर्ते कि जो चीजें संक्षिप्त रूप से लिखी जाती हैं, वे लिखी रहें।
• दस्तावेज स्वयं जटिल हैं। हमारे विशिष्ट मामले में प्रोटोटाइप दस्तावेज़ को प्रति दस्तावेज़ उदाहरण में 150 + अलग-अलग डेटा के भंडारण की आवश्यकता होगी। पैथोलॉजिकल केस परिमाण का क्रम बदतर हो सकता है, लेकिन निश्चित रूप से दो नहीं।
• दस्तावेजों का एक एकल वर्ग बाद के समय में अद्यतन करने के लिए एक चलती लक्ष्य विषय है।
• जब हम एक रिलेशनल डेटाबेस में हुक करते हैं तो हमें Django से मिलने वाला मुफ्त सामान पसंद आता है। हम django-nonrel fork का उपयोग करने के लिए दो Django संस्करणों को वापस लाने के बिना मुफ्त में रखना चाहते हैं। ORM को पूरी तरह से डंप करना 1.3 पर डाउनग्रेड करने के लिए बेहतर है।

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

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

प्रस्तावित हल:

1. प्रति दस्तावेज़ वर्ग एक तालिका

प्रत्येक दस्तावेज़ वर्ग को अपनी तालिका प्राप्त होती है, जिसमें सभी मेटाडेटा और डेटा के लिए कॉलम होते हैं।

लाभ:

• मानक SQL डेटा मॉडल खेलने में है।
• रिलेशनल डेटा को सबसे अच्छे तरीके से हैंडल किया जाता है। बाद में अगर हमें जरूरत पड़ेगी तो हम इसे असामान्य कर देंगे।
• Django का बिल्ट-इन एडमिन इंटरफेस इन टेबल को इंट्रोस्पेक्ट करने में सहज है और ORM बॉक्स से 100% डेटा के साथ खुशी से रह सकता है।

नुकसान:

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

2. ईएवी मॉडलिंग

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

लाभ:

• मॉडल के लिए आसान है।

नुकसान:

• प्रश्न करना अधिक कठिन है।
• DB परत में अब एक एप-स्तरीय वस्तु के गठन के लिए एक सीधा-आगे प्रतिनिधित्व नहीं है।
• हम DB स्तर की बाधा जाँच खो देंगे।
• एक टेबल पर पंक्तियों की संख्या 100 गुना अधिक तेजी से बढ़ेगी। संभवतः भविष्य के दर्द बिंदु, प्रदर्शन-वार।
• सीमित अनुक्रमण संभव है।
• जहाँ तक ORM का संबंध है, DB स्कीमा निरर्थक है। बैटरियों में शामिल वेब ऐप सामान संरक्षित है लेकिन कस्टम डेटा मॉडल के लिए कस्टम क्वेरी की आवश्यकता होती है।

3. PostgreSQL hstore या json फ़ील्ड का उपयोग करें

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

लाभ:

• हमें Django ORM और बिल्ट-इन इनटॉरस और सेशन मैनेजमेंट का लाभ मिलता है।
• सब कुछ एक बैकेंड में रहता है जिसे हमने पहले अन्य परियोजनाओं पर सफलतापूर्वक उपयोग किया है।

नुकसान:

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

4. पूर्ण बोर दस्तावेज़ उन्मुख जाओ

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

लाभ:

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

नुकसान:

• ORM Django ट्रंक के लिए खिड़की से बाहर है। मुफ्तखोर जो इसके साथ खिड़की से बाहर निकलते हैं: ऑउटफिट फ्रेमवर्क, सेशन फ्रेमवर्क, एडमिन इंटरफेस, निश्चित रूप से कई अन्य चीजें।
• या तो मोंगो की संदर्भित क्षमताओं (जिसमें कई प्रश्नों की आवश्यकता होती है) का उपयोग करना चाहिए या डेटा को असामान्य बनाना चाहिए। न केवल हम Django से मिलने वाले मुफ्त के सामानों को खो देते हैं, हम उन पोस्टों को भी खो देते हैं, जैसे जोइनिंग्स को हमने पोस्टग्रेक्यूएल में दी थी।
• डेटा सुरक्षा। जब कोई MongoDB के बारे में पढ़ता है, तो ऐसा लगता है कि हमेशा कम से कम एक व्यक्ति यह बताता है कि यह आपके डेटा को कैसे खो देगा और खो देगा। वे कभी भी किसी विशेष घटना का हवाला नहीं देते हैं और हो सकता है कि यह सब केवल हॉगवॉश हो या सिर्फ पुरानी डिफ़ॉल्ट आग से संबंधित हो और लेखन-चिंता को भूल जाए लेकिन यह अभी भी मुझे चिंतित करता है। हम निश्चित रूप से किसी भी मामले में एक बहुत ही पागल बैकअप रणनीति का उपयोग कर रहे हैं (यदि डेटा चुपचाप दूषित है कि अच्छी तरह से निश्चित रूप से सारहीन हो सकता है ..)।

5. PostgreSQL और MongoDB

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

लाभ:

• प्रत्येक बैकएंड केवल वही करता है जो इसमें अच्छा है।
• कई प्रश्नों की आवश्यकता के बिना मॉडल के बीच संदर्भ संरक्षित हैं।
• हमें बैटरी रखने के लिए मिलती है जो Django ने हमें दिया है जहां तक ​​उपयोगकर्ता, सत्र आदि का संबंध है।
• केवल एक documentsटेबल की जरूरत है, चाहे कितने ही अलग-अलग वर्ग के दस्तावेज बनाए जाएं।
• कम अक्सर queried दस्तावेज़ डेटा को दृढ़ता से कहीं अधिक अक्सर मेटाडेटा से अलग किया जाता है।

नुकसान:

• दस्तावेज़ डेटा को पुनर्प्राप्त करने के लिए 2 अनुक्रमिक प्रश्नों की आवश्यकता होगी, पहले SQL DB के खिलाफ और फिर MongoDB के खिलाफ (हालांकि यह इससे भी बदतर नहीं है अगर मानगो में एक ही डेटा संग्रहीत किया गया था और इसे असामान्य नहीं किया गया है)
• लिखना अब परमाणु नहीं होगा। एक एकल Mongo दस्तावेज़ के खिलाफ एक लेख को परमाणु होने की गारंटी दी गई है और PG स्पष्ट रूप से परमाणु गारंटी दे सकता है, लेकिन दोनों में लिखने की परमाणुता सुनिश्चित करने के लिए आवेदन तर्क की आवश्यकता होगी, प्रदर्शन और जटिलता दंड के साथ कोई संदेह नहीं है।
• दो बैकएंड = दो क्वेरी भाषाएँ = असंतुष्ट व्यवस्थापक आवश्यकताओं के साथ दो अलग-अलग प्रोग्राम = दो डेटाबेस स्मृति के लिए मर रहे हैं।

Comments

मैं एक JSONडेटाटाइप वाले कॉलम के लिए जाऊंगा । Postgres में नई सुविधाओं का उपयोग करने से डरो मत - Postgres टीम उन विशेषताओं को जारी नहीं करती है जो स्थिर नहीं हैं। और 9.2 वास्तव में वह नया नहीं है)। इसके अलावा आप 9.3 JSON सुविधाओं का उपयोग एक बार कर सकते हैं। यदि आप हमेशा अपने एप्लिकेशन कोड में दस्तावेजों को पूरी तरह से संसाधित कर रहे हैं (बल्कि तब SQL का उपयोग करके), तो आप JSON को एक नियमित textकॉलम में भी संग्रहीत कर सकते हैं ।

— a_horse_with_no_name

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

— चक्क्माश

@chucksmash। क्या आप # 5 के साथ गए, आखिर? आपने दोनों dbs को लागू करने का प्रबंधन कैसे किया? आपने किन उपकरणों का उपयोग किया? यदि नहीं, तो क्यों?

— xpanta

@chucksmash अभी भी आपके द्वारा वादा किए गए फ़ीडबैक की प्रतीक्षा कर रहा है।

— भस्म पारिख

@chucksmash ओपी ने नहीं दिया ... :(

— अल्बर्ट रोथमैन

Answer 1

कुछ विचार....

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

आप संभवतः अपने मेटाडेटा को सामान्य डेटा, कक्षाओं के लिए आवश्यक डेटा और दस्तावेज़ डेटा में अलग कर सकते हैं। इस संबंध में आपके पास सामान्य सामान्य जानकारी के साथ एक सामान्य सूची तालिका होगी और प्रति कक्षा एक तालिका होगी। इस तालिका में आपके पास एक hstore, json, या xml फ़ील्ड होगा, जो शेष डेटा को उन स्तंभों के साथ संग्रहीत करेगा जहाँ आप डेटा संग्रहीत कर रहे हैं जो कि पर्याप्त रूप से विवश होना चाहिए। यह आपको प्रति वर्ग इन तालिकाओं में डालने की आवश्यकता को कम करेगा, लेकिन आपको अपनी पसंद के अनुसार बाधाओं का लाभ उठाने की अनुमति देगा। तीन विकल्पों में अलग-अलग मुद्दे हैं और अलग-अलग विचार करने लायक हैं:

hstore अपेक्षाकृत सीमित है लेकिन इसका उपयोग बहुत से लोग करते हैं। यह बहुत नया नहीं है, लेकिन यह केवल एक कुंजी / मूल्य की दुकान है, और json और xml के विपरीत नेस्टेड डेटा संरचनाओं में असमर्थ है।

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

xml सबसे अधिक सुविधाओं के साथ, और सबसे लंबे समय तक समर्थन इतिहास के साथ तीनों का सबसे अच्छा समर्थन है। तो फिर, यह XML है .....

हालाँकि, यदि आप Mongo और PostgreSQL के साथ जाने का निर्णय लेते हैं, तो ध्यान दें कि PostgreSQL 2 चरण प्रतिबद्ध का समर्थन करता है जिसका अर्थ है कि आप लेखन कार्य को चला सकते हैं, फिर इसे जारी करें PREPARE TRANSACTIONऔर यदि यह सफल होता है तो Mongo में आपका परमाणु लेखन। यदि वह सफल होता है तो COMMITआप PostgreSQL में कर सकते हैं ।

Comments

ये सभी महान सुझाव हैं। मैंने पहले hstore / json का उपयोग करने का उल्लेख किया था (और xml को चुपचाप छूट दिया था, क्योंकि, अच्छी तरह से, xml) लेकिन मैंने उन्हें आपके द्वारा अनुशंसित तरीके से उपयोग करने के बारे में नहीं सोचा था। इस सब के शीर्ष पर, पोस्टग्रेज 2 चरण का प्रतिबद्ध सुझाव सोना है। मुझे नहीं पता था कि यह अस्तित्व में है। महान सुझावों के लिए धन्यवाद।

— चकस्माश

2 चरणबद्ध वचन वास्तव में सोना है। यह अग्रानुक्रम में एक NoSQL का उपयोग बहुत संभव बनाता है। खासकर अगर 2 DB के बीच का डेटा शायद ही कभी परस्पर संबंध

— रखता है

Answer 2

आप MongoDB और Postgres में रहने वाले डेटा में शामिल होने के लिए Presto या Dremio जैसे क्वेरी इंजन को सेटअप कर सकते हैं और एक ही क्वेरी के साथ पोस्टग्रेज कर सकते हैं। इन डेटाबेस में से प्रत्येक के लिए दोनों में कनेक्टर हैं (डॉक्स को यहां और यहां देखें ) और क्रमशः, "एसक्यूएल ऑन एनीथिंग" और "कुछ भी ज्वाइन" चलाने का प्रस्ताव करते हैं।

प्रेस्टो का परीक्षण करने के लिए, आप HWSop, Hive और Presto के साथ AWS EMR पर एक छोटा क्लस्टर तैनात कर सकते हैं (यदि आप कमांड लाइन का उपयोग नहीं करना चाहते हैं तो ह्यू), यह बॉक्स से काम करता है - सेट करने के लिए इन निर्देशों का पालन करना सुनिश्चित करें कनेक्टर्स । हाइव कड़ाई से आवश्यक नहीं है, लेकिन इसके साथ, आप मोंगो और पोस्टग्रेज के बीच जुड़ने से परिणाम का उपयोग करके तालिकाओं का निर्माण कर सकते हैं ( उदाहरण के लिए इस पृष्ठ की जांच करें )। बाज़ार में एक भुगतान किया गया संस्करण भी है , जो (माना जाता है) भारी रूप से अनुकूलित है, और इसमें 30 दिन का परीक्षण है।

मैंने Dremio का उपयोग नहीं किया है, लेकिन AWS, Azure या परिसर में इसे तैनात करने के लिए कुछ आसान तरीके हैं । उनके पास अपनी वेबसाइट पर कुछ ऑनलाइन पाठ्यक्रम हैं , "वर्चुअल लैब" तक पहुंच के लिए, जिसका उपयोग आप मुफ्त में कक्षाओं का पालन करने के लिए कर सकते हैं।