कुछ तालिकाओं को एक डेटाबेस से दूसरे में पोस्ट करता है


9

मुझे निम्न स्थिति मिली है: मेरे पास पोस्टग्रेजिकल डेटाबेस चलाने वाली तीन मशीनें हैं। एक मशीन क्लाइंट खाते की जानकारी रखती है (इस मशीन को कॉल करें), अन्य दो मशीनें क्लाइंट लॉगिंग जानकारी (इन L1 और L2 को कॉल करें) रखती हैं। बंटवारे का कारण कई मशीनों पर लोडिंग को अलग करना है (इसलिए कुछ क्लाइंट L1 को लॉगिंग जानकारी भेजते हैं, कुछ L2 को ... और शायद कुछ समय L3, L4, ...)।

लॉगिंग जानकारी प्राप्त करते समय, प्रिंसिपल में, मैं Ln पर लॉगिंग टेबल और क्लाइंट अकाउंट टेबल के बीच JOIN करने में सक्षम होना चाहता हूं। वास्तव में मैं इस तरह से जॉइन नहीं कर सकता (और यहां तक ​​कि अगर मैं कर सकता था, तो मैं चाहता हूं। सी लोडिंग से बचने के लिए)।

मेरा विचार एल 1, एल 2 में से प्रत्येक पर सी पर तालिकाओं को दोहराने के लिए है ... ताकि मैं इसमें शामिल हो सकूं। जहां तक ​​सी से तालिकाओं का संबंध है, सी मास्टर है और एल 1, एल 2, ... दास हैं। लेकिन L1, L2 पर अन्य तालिकाओं के लिए, ... ये मशीनें स्वामी हैं। यह बिल्कुल मास्टर-मास्टर प्रतिकृति नहीं है, और क्या यह बिल्कुल मास्टर-दास नहीं है।

पोस्टग्रेज कर सकते हैं (मैं 9.1 चल रहा हूं) प्रतिकृति को ऐसा करने के लिए राजी किया जा सकता है, या यदि कोई अन्य पैकेज नहीं है जो काम करेगा। अंतिम उपाय में, मैं कुछ कोड को समय-समय पर सिंक की तालिकाओं में लिख सकता हूं (मैं कुछ देरी बर्दाश्त कर सकता हूं), लेकिन यह अच्छा होगा!

अग्रिम में धन्यवाद।


1
शायद C तक पहुँचने के लिए लॉगिंग मशीनों पर FDW का उपयोग करें ? हालाँकि, यह C. पर एक प्रदर्शन हिट होगा। Materialized Views प्रदर्शन हिट को कम कर सकता है, लेकिन मुझे यकीन नहीं है कि PostgreSQL विदेशी तालिका के अपडेट का पता कैसे लगाता है। यदि यह स्वचालित रूप से होता है (जो कि भौतिकीकृत दृश्य प्रलेखन के समाप्त होने का सुझाव देता है), तो यह आपकी समस्या को पूरी तरह से हल कर सकता है। हालांकि ये 9.3 फीचर हैं। बहुत सक्रिय मेलिंग सूची भी मदद की हो सकती है।
jpmc26

जवाबों:


4

PostgreSQL 9.3 पर, आप postgres_fdwअन्य मशीन पर विदेशी तालिका को पारदर्शी रूप से क्वेरी करने के लिए उपयोग कर सकते हैं ।

dblinkएंड्रयू द्वारा उल्लिखित पुराने संस्करणों पर, एक विकल्प हो सकता है।

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

एक भविष्य का विकल्प (उम्मीद है कि पोस्टग्रेसीक्यू 9.5 में) तार्किक स्ट्रीमिंग, तार्किक बदलाव और निष्कर्षण की प्रतिकृति होगी, जो कि व्यक्तिगत डेटाबेस या तालिकाओं को SQL स्तर पर दोहराया जा सकेगा। इसके लिए काम का एक हिस्सा PostgreSQL 9.4 के लिए प्रतिबद्ध था, लेकिन जो आप करना चाहते हैं उसके लिए इसे उपयोगी बनाने के लिए पर्याप्त नहीं है।


3

आपको इसे प्राप्त करने के लिए dblinks और materialized views का उपयोग करना चाहिए। दोनों विशेषताएं पोस्टग्रैज के नवीनतम संस्करणों में निर्मित हैं:

http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html

http://www.postgresql.org/docs/9.3/static/dblink.html

अनिवार्य रूप से आप प्रत्येक डेटाबेस L1, L2 पर एक Mview का निर्माण करते हैं ... C पर तालिकाओं से निकाले गए डेटा के साथ, फिर Mview रिफ्रेश को समय-समय पर आवश्यकतानुसार अपडेट करने के लिए उपयोग करते हैं। डेटा को स्थानीय रूप से संग्रहीत किया जाता है इसलिए इसे एक्सेस करना बहुत तेज़ है। यह केवल तभी उपयुक्त है जब डेटा अपेक्षाकृत स्थिर हो और आपको स्थानीय डेटाबेस से कभी-कभार थोड़ी बहुत जानकारी न हो। आपको इसे उचित रूप से प्रबंधित करने के लिए ताज़ा आवृत्तियों को सेट करना चाहिए, और यदि यह स्वीकार्य नहीं है, तो आपको बस एक डेटाबेस लिंक का उपयोग करना चाहिए और परिणामी सुस्ती से निपटना चाहिए।

यदि आपको अतिरिक्त कार्यक्षमता की आवश्यकता है, तो स्नैपशॉट प्रोजेक्ट तेज़ ताज़ा और स्नैपशॉट लॉग जैसी उन्नत सुविधाएँ प्रदान करता है:

http://pgfoundry.org/projects/snapshot/

इससे आप रीफ़्रेश कर सकते हैं केवल उन पंक्तियों को अपडेट कर सकते हैं जिन्हें अपडेट करने की आवश्यकता होती है, जो उन्हें आपके ऐप में व्यवधान को कम करते हुए, बड़े, इनलेटस्टिक डेटासेट के लिए बेहद तेज़ बना सकते हैं। डिफ़ॉल्ट रूप से Mviews को पूरी तरह से गिरा दिया जाता है और Postgres में फिर से बनाया जाता है, जो स्पष्ट कारणों के लिए प्रदर्शन के लिए बहुत बुरा हो सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.