हाइब्रिड डीबी सिस्टम: डेटा के लिए NoSQL, संबंधों के लिए एसक्यूएल। सर्वश्रेष्ठ प्रणालियां?

Question

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

मैं एक लाइव वोटिंग सिस्टम बना रहा हूं।

मैं एसक्यूएल और MongoDB के साथ आराम कर रहा हूँ, तो यह लगभग निर्णय का एक पहलू नहीं है

लेकिन सब कुछ से मैं वेब पर पढ़ा है (हालांकि मैं MongoDB संरचना और जे एस अधिक इस समय :) पसंद करते हैं) , मैं अभी भी अपने फैसले से असहज महसूस करता हूं।

• वस्तुओं (उपयोगकर्ता, आइटम, टिप्पणियाँ आदि)
• होने संबंधों के लिए एसक्यूएल तालिकाओं (तालिका उपयोगकर्ता के आइटम के लिए NoSQL दस्तावेज होने:

  मुझे क्या करना चाहते हैं दोनों का लाभ गठबंधन करने के लिए है , उपयोगकर्ता-टिप्पणियां आदि)

• एक NoSQL दस्तावेज़ में मतदान के परिणाम की नकल जब भी एक वोट है या एक नियमित अंतराल में (वोट परिणामों के प्रदर्शन पर भी गति)

महान उन्नत स्तर हासिल करने के लिए ntages मैं देखता हूं:

1. किसी दस्तावेज़ से पूछताछ (उदा। एक उपयोगकर्ता अपनी प्रोफाइल प्रदर्शित करने के लिए), मेरे पास सभी नोएसक्यूएल लाभ (गति, सभी एक ही स्थान पर, स्कीमा लचीलापन इत्यादि)
2. आंकड़े करते समय (उदाहरण के लिए वोट की संख्या), मेरे पास सभी SQL लाभ
3. हैं Parallelisation: मैं, एसक्यूएल में वोट और async मोड में दस्तावेजों
4. तेजी से पढ़ें प्राप्त कर सके slowish बारे में (और यह मेरे मामले में कोई फर्क नहीं पड़ता)
5. रिश्ता ईमानदारी हमेशा

मेरे सवालों संरक्षित है हैं:

• क्या ऐसा करने के लिए यह एक अच्छा अभ्यास है? वेब इसके बारे में बहुत शर्मीला लगता है
• क्या मैं उच्च डीबी लोड के साथ मूंगफली का अनुकूलन कर रहा हूं?

Answer 1

एकमात्र कारण आप एक RDBMS के साथ एक NoSQL डेटाबेस का उपयोग करना चाहते गति और लचीलापन हासिल करने के लिए है, तो मैं था (पूर्ण एसक्यूएल और तरह का चयन करें * मेज से जहां primary_key = XXX प्रश्नों के प्राप्त करने में कठिनाई दस्तावेज़ की तुलना) इसके बजाय कैशिंग सर्वर का उपयोग करने का सुझाव दें (जैसे मेमकैच)। आप SQL दस्तावेज़ों का उपयोग करके दस्तावेज़/परिणाम बना सकते हैं और बाद में इसे पुनर्प्राप्त करने के लिए memcache में एक एकल कुंजी मान का उपयोग करके इसे संग्रहीत कर सकते हैं। MongoDB कहने से लागू करना बहुत आसान है। लेकिन यह निश्चित रूप से आपकी आवश्यकताओं पर निर्भर करता है यदि आप वास्तव में केवल अपने दस्तावेज़ों के लिए अधिक जटिल प्रश्नों का उपयोग करने के लिए कुंजी या योजना का उपयोग करके दस्तावेज़ लुकअप करने का इरादा रखते हैं।

Answer 2

मैं वस्तुओं और रिश्तों को मॉडलिंग के लिए एक और सुझाव फेंकना चाहता हूं जो स्केल करेगा।

विचार के लिए कुछ खाना:

1. कि आपने कहा, के रूप में मॉडल संस्थाओं/MongoDB की तरह एक दस्तावेज़ डेटाबेस में वस्तुओं।
2. टाइटन या नियो 4j जैसे ग्राफ डेटाबेस में संबंधों को स्टोर करें।जटिल संबंधों को संग्रहित करने के लिए ये प्रणालियां मेरी राय में अधिक उपयुक्त हैं। आप कई जटिल रिश्तों पर आसानी से ट्रैवर्सल कर सकते हैं और फिर जब आपको ग्राफ़ में गंतव्य नोड/वर्टेक्स मिलता है, तो आप मोंगो से दस्तावेज़ लोड कर सकते हैं।
3. Riak जैसे कुछ पर विचार करें, जो एक नोएसक्यूएल दस्तावेज़ स्टोर है जो भी दस्तावेज़ों (रिश्तों) के बीच संबंध है। वे संबंधों को बहुत जटिल बनाने की सलाह देते हैं, लेकिन किसी अन्य प्रणाली की आवश्यकता के बिना दस्तावेजों को एक साथ जोड़ना संभव है।

Answer 3

"सर्वश्रेष्ठ अभ्यास" एक भयानक शब्द है - इसका उपयोग अक्सर आंत वृत्ति को न्यायसंगत बनाने के लिए किया जाता है, "इस तरह हमने इसे हमेशा किया है", या अन्य पूर्वाग्रह।

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

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

आपके प्लेटफ़ॉर्म पर काम करने वाले डेवलपर्स को तकनीकी ढेर दोनों में विशेषज्ञता की आवश्यकता होगी - कल्पना करने की कोशिश करें कि किसी दिए गए उपयोगकर्ता की टिप्पणी संख्या गलत क्यों प्रतीत होती है।

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

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

मुझे नहीं लगता कि लाभ उन कमियों से अधिक हैं।