एक डेटाबेस न केवल एक डेटा वेयरहाउस है

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

टीएल, डॉ

नीचे प्रमाणीकरण, उपयोगकर्ताओं, एक्सेस अधिकार, डेटा अखंडता, FDW, लॉगिंग और आंकड़ों के बारे में होगा। कोई नई बात नहीं।

नोट

• मेरा मतलब रूबी ऑन रेल्स एंड पोस्टग्रेज़ होगा, लेकिन अधिकांश संदर्भ अन्य भाषाओं और डीबीएमएस में अच्छी तरह से सहन किए जाते हैं।
• मैं कुछ भी नया नहीं कहूंगा, यह सब लंबे समय से प्रलेखन और लेखों में वर्णित है। मैं सिर्फ उपकरणों के बारे में एक बार फिर याद दिलाना चाहता हूं और जहां उन्हें जीवन को थोड़ा बेहतर बनाने के लिए लागू किया जा सकता है।

सहकर्मी / पहचान प्रमाणीकरण

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

सहकर्मी और पहचान के बारे में पीजी प्रलेखन।

बारीकियाँ: उपयुक्त यदि आपके पास सर्वर पर केवल रूट और सुपरयुसर नहीं है; और पहचान के मामले में, आप नेटवर्क, हार्डवेयर को नियंत्रित करते हैं और सुनिश्चित करते हैं कि कोई घुसपैठिए और सबोटर्स नहीं हैं।

उपयोग के उदाहरण

सुरक्षा। आप डेटाबेस से पासवर्ड नहीं हटा सकते हैं और इसे स्थानीय वातावरण से या कहीं और से कनेक्ट कर सकते हैं। कोई पासवर्ड नहीं है और खींचने के लिए कुछ भी नहीं है।

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

पहुँच अधिकार

यूनिक्स में, हर कोई उनके बारे में सोचता है और वे जड़ से काम करने या 'chmod 777' पर बहुत तिरछी दिखती हैं। लेकिन डेटाबेस में सब कुछ कुछ अलग है। सुपरसुसर और जाओ। हालांकि सब कुछ कम नहीं है (और शायद और भी अधिक) शांत।

भूमिका वंशानुक्रम (यूनिक्स में समूह की तरह एक सा) का एक पदानुक्रम है, विभिन्न स्तरों तक पहुंच है: विशिष्ट ऑब्जेक्ट्स (जैसे फ़ाइल अनुमतियाँ) से, विशिष्ट ऑपरेटरों (जैसे sudoers में नियम), यहां तक कि विशिष्ट लाइनों तक । संक्षेप में, सब कुछ है। इसका उपयोग करें।

आवेदन क्षेत्रों

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

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

अखंडता बाधा

रेल 5 में, कम से कम किसी तरह, संदर्भ और डेटा अखंडता के साथ काम शुरू हुआ। लेकिन, सामान्य मामले में, कई डेवलपर्स का मानना ​​है कि मॉडल या इसके एनवायरनमेंट में सत्यापन डेटा की सुसंगत स्थिति को संरक्षित करने के लिए पर्याप्त है। काश, यह बिल्कुल सच नहीं होता।

मान्यताओं को छोड़ दिया जा सकता है, आप सीधे डेटाबेस में जा सकते हैं और एसक्यूएल चला सकते हैं, आप प्रवास के दौरान मोप कर सकते हैं। सामान्य तौर पर, बहुत कुछ किया जा सकता है। इसलिए, व्यापार तर्क पर भरोसा करने वाली हर चीज को डेटाबेस द्वारा नस्ट किया जाना चाहिए। यह डेटा की अखंडता को बनाए रखने और अगली तैनाती पर "आश्चर्य" न करने का एकमात्र तरीका है।

विदेशी डेटा आवरण

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

FDW का उपयोग करना

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

साथ ही, भविष्य में, आप बाहरी तालिका को एक भौतिक दृष्टिकोण या सिर्फ एक तालिका के साथ बदल सकते हैं, लेकिन वेब एप्लिकेशन में कुछ भी नहीं बदल सकते हैं।

और फिर भी, आप विदेशी प्रकार के एमएस एक्सेस से जुड़ सकते हैं और मॉडल में संबंधों के उपयोग पर प्रतिबंध के साथ समस्याएं गायब हो जाती हैं। आखिरकार, यदि आपके पास 2+ कनेक्शन हैं, तो आप वेब एप्लिकेशन स्तर पर दो आधारों के साथ नहीं जुड़ेंगे, हालांकि ORM (विशेष रूप से, ActiveRecord) ईमानदारी से ऐसा करने की कोशिश करेगा ... और गिर जाएगा। और डेटाबेस स्तर पर, यह कुछ मामलों में, लगभग बिना ओवरहेड के किया जा सकता है।

लॉगिंग

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

N + 1 के बारे में भी याद रखें। डेटाबेस इसके बारे में कुछ नहीं कहेगा। तृतीय-पक्ष उपकरण का उपयोग करें। उदाहरण के लिए, बुलेट और सामान्य ज्ञान।

आंकड़े

यह याद रखना चाहिए कि यह है और यह बदबू आ सकती है। पहले तो सब ठीक रहा। लेकिन समय के साथ, आमतौर पर, निम्नलिखित परिणाम: डेटा के परिवर्तन की दर लगभग समान होती है, और तालिका का आकार बड़ा होता है। नतीजतन, वैक्यूम / विश्लेषण तालिकाएं कम बार होने लगती हैं और कुछ बिंदु पर अनुसूचक को याद करना शुरू हो जाता है। सबसे अच्छे मामले में, अनुरोध उपरोक्त लॉगिंग में आता है, सबसे बुरे में - आप बस पीड़ित हैं और समझ में नहीं आता कि क्यों। सामान्य तौर पर, pg_stat_user_tables में pg_stat_user_tables और तालिकाओं पर लोड के साथ वैक्यूम / विश्लेषण तिथियों को सहसंबंधित करें।

और कभी-कभी आप अनुमानित count लिए आंकड़ों का उपयोग कर सकते हैं। यह शायद ही कभी काम में आता है, लेकिन काफी उपयुक्त है, क्योंकि पीजी ओरेकल नहीं है और पूरी तालिका के लिए count ओ (1) में नहीं की गई है, हालांकि मैं वास्तव में चाहता हूं।

अंत

पढ़ने के लिए धन्यवाद। यदि मुश्किल नहीं है, तो नीचे दिए गए प्रश्न का उत्तर दें। SQL के बजाय, GQL के बारे में हाल के एक लेख के प्रकाश में , उसने मुझे विशेष रूप से परेशान करना शुरू कर दिया।