वास्तव में आपके प्रश्न का उत्तर नहीं है (टिप्पणी करने के लिए पर्याप्त प्रतिष्ठा नहीं है (?!?)), लेकिन यह समझना कि आपकी समस्या स्केल है, और आप PostgreSQL से आ रहे हैं, क्या आपने अभी तक PostgresXC को आजमाया है? यह NoSQL की तुलना में एक बहुत आसान संक्रमण हो सकता है। NoSQL डेटाबेस, जैसा कि मुझे लगता है कि आपको पता है, बहुत अलग प्रदर्शन विशेषताओं और बारीकियां हैं जो वास्तव में अच्छे से अधिक नुकसान कर सकती हैं। Postgres-XC PostgreSQL का बहु-मास्टर लेखन-स्केलेबल कांटा है और पोस्टग्रेएसक्यूएल फीचर स्टैंडपॉइंट से 9.1 और 9.2 के बीच कहीं भी बैठता है और यह एक सक्रिय प्रोजेक्ट है। 9.2 अनुरूपता इस महीने या आखिरी बार तय की गई थी अगर मुझे सही याद आती है। यह अपेक्षाकृत आसान है कि यह क्या है - आप 2 जीटीएम का निर्माण करेंगे, एक प्राथमिक के रूप में और एक फेलओवर के रूप में, उन्हें पर्याप्त स्मृति दें। फिर आप समन्वयक और डेटा नोड्स, 1 समन्वयक और प्रति डेटा 1 डेटा नोड जोड़े जोड़कर क्षैतिज पैमाने पर स्केल कर सकते हैं। आपका आवेदन स्तर किसी भी समन्वयक से बात कर सकता है, लेनदेन उचित समन्वयक को भेज दिया जाता है और आप तालिका द्वारा अपने डेटा का वितरण निर्दिष्ट कर सकते हैं - या तो छोटे संदर्भ तालिकाओं के लिए दोहराया गया है या बड़े लोगों के लिए वितरित किया जा सकता है। यदि आप अपने प्रश्नों को अच्छी तरह से डिजाइन करते हैं, तो आप बड़े पैमाने पर प्रदर्शन सुधार प्राप्त कर सकते हैं क्योंकि आपके प्रश्नों को एकाधिक समन्वयक/डेटा नोड जोड़े पर एक साथ भेज दिया जा सकता है और निष्पादित किया जा सकता है।
मुझे पता है कि आप नोएसक्यूएल की तलाश में हैं, लेकिन मैं इसका जिक्र करता हूं क्योंकि हमारे पास भी क्षैतिज स्केल समस्या का लंबवत था और अंत में मुझे लगता है कि संबंधपरक क्षमता बनाने के बजाय एक संबंध प्रणाली में नोएसक्यूएल क्षमता बनाना आसान था एक नोएसक्यूएल सिस्टम में। और निश्चित रूप से यह सब आपके डेटा पर निर्भर करता है, कभी-कभी नोएसक्यूएल बिल्कुल सर्वोत्तम विकल्प है। कभी-कभी यह एक प्रमुख सिरदर्द भी हो सकता है, उदाहरण के लिए कुछ नोएसक्यूएल डेटाबेस में फाइल सिस्टम विकास के साथ समस्याएं होती हैं, जबकि आपने सोचा था कि आपने क्षैतिज स्केलेबिलिटी खरीदी है जिससे आप अपने SAN को घर और घर से बाहर घायल कर सकते हैं।
वैसे भी, उम्मीद है कि मदद करता है! मैं इसे एक टिप्पणी के रूप में छोड़ देता था लेकिन स्टैक ओवरफ्लो में उस अजीब प्रतिष्ठा की बात चल रही थी।
मैं पोस्टग्रेस-एक्ससी के साथ भी उल्लेख करना भूल गया था, आप निर्दिष्ट कर सकते हैं कि आप कौन से कॉलम वितरित करना चाहते हैं और किस प्रकार के एल्गोरिदम द्वारा। मैं आमतौर पर हैश द्वारा वितरित करता हूं, और दो चीजों को सुनिश्चित करता हूं, पहले हैश को एप्लिकेशन-साइड जेनरेट किया जा सकता है ताकि मुझे उन टेबल पर जुड़ने की ज़रूरत नहीं है जो पंक्तियों के गैजिलियन हैं और दूसरा हैश है जो सर्वर पर वितरण स्तर रखता है सही है, लेकिन एक ही सर्वर पर संबंधित जानकारी को एक साथ रखते हुए ताकि प्रश्नों की शिपिबिलिटी में वृद्धि हो सके। यही है, यदि आपके पास ग्राहक तालिका और ग्राहक ऑर्डर टेबल है, तो दोनों क्लाइंट की हैश पर दोनों क्लाइंट अद्वितीय जानकारी जो दोनों टेबलों में है और सुनिश्चित करें कि आप उस एप्लिकेशन-साइड को उत्पन्न कर सकते हैं। मुझे आशा है कि यह समझ में आता है, मुझे यकीन नहीं है कि मैंने एक अच्छा काम समझाया है। यदि आप उस पर और स्पष्टीकरण चाहते हैं तो कृपया मुझे बताएं, डॉक्स अभी एक्ससी पर बिखरे हुए हैं, इसलिए मैं जो कुछ भी संबंधित हूं वह ओजेटी है।
मोंगोडीबी सरणी क्षेत्रों पर सूचकांक बनाने की अनुमति देता है। लेकिन आपको ** ** postgreSQL से दूसरे डेटाबेस तकनीक में डेटा को स्थानांतरित करने की आवश्यकता क्यों है? – Philipp
क्योंकि डीबी अब बड़ा है और गति पर चलने वाले एक (महंगे) सर्वर में होने की लागत हमें कम महंगी सर्वरों का उपयोग करके डीबी के लिए नोएसक्यूएल क्लस्टर स्थापित करने की लागत से अधिक है। –
लगता है जैसे आप स्मृति कैशिंग तकनीकों का उपयोग नहीं कर रहे हैं जैसे कि मेमकेच पर्याप्त रूप से। –