एक आवेदन से एक डेटाबेस के साथ काम करना

शुरुआत में मैं डेटाबेस के साथ काम करते समय कुछ समस्याओं और सुविधाओं को रेखांकित करूंगा, मैं सार में छेद दिखाऊंगा। अगला, हम प्रतिरक्षा के आधार पर एक सरल अमूर्तता का विश्लेषण करेंगे।

पाठक को एक्टिव रिकॉर्ड , डेटा मेपर , आइडेंटिटी मैप और यूनिट ऑफ़ वर्क पैटर्न से थोड़ा परिचित होना चाहिए।

समस्याओं और समाधानों को बड़ी पर्याप्त परियोजनाओं के संदर्भ में माना जाता है जिन्हें फेंका नहीं जा सकता है और जल्दी से फिर से लिखा जा सकता है।

पहचान का नक्शा

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

माणिक ActiveRecord पुस्तकालयों के लिए, यह ऐसा नहीं है:

post_a = Post.find 1 post_b = Post.find 1 post_a.object_id != post_b.object_id # true post_a.title = "foo" post_b.title != "foo" # true 

यानी हमें स्मृति में 2 अलग-अलग वस्तुओं के 2 संदर्भ मिलते हैं।

इस प्रकार, यदि हम अनजाने में एक ही इकाई के साथ काम करना शुरू कर देते हैं, लेकिन हम विभिन्न वस्तुओं द्वारा दर्शाए गए परिवर्तनों को खो सकते हैं।

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

लंबा लेन-देन

लेकिन क्या होगा अगर हम पहचानकर्ता द्वारा चयन नहीं करते हैं? ऑब्जेक्ट की स्थिति और डेटाबेस की स्थिति को सिंक से बाहर होने से रोकने के लिए, चयन का अनुरोध करने से पहले हाइबरनेट फ्लश करें ।
यानी डेटाबेस में गंदी वस्तुओं को डंप करता है ताकि अनुरोध सहमत डेटा पढ़ता है।

यह दृष्टिकोण आपको डेटाबेस लेनदेन को खुला रखने के लिए मजबूर करता है जबकि व्यापार लेनदेन प्रगति पर है।
यदि व्यवसाय लेनदेन लंबा है, तो डेटाबेस में कनेक्शन के लिए जिम्मेदार प्रक्रिया भी निष्क्रिय है। उदाहरण के लिए, यह तब हो सकता है यदि कोई व्यवसाय लेनदेन नेटवर्क पर डेटा का अनुरोध करता है या जटिल गणना करता है।

एन + १

शायद ORM अमूर्त में सबसे बड़ा "छेद" N + 1 क्वेरी समस्या है।

ActiveRecord लाइब्रेरी के लिए रूबी पर उदाहरण:

 posts = Post.all # select * from posts posts.each do |post| like = post.likes.order(id: :desc).first # SELECT * FROM likes WHERE post_id = ? ORDER BY id DESC LIMIT 1 # ... end 

ओआरएम प्रोग्रामर को इस विचार की ओर ले जाता है कि वह केवल स्मृति में वस्तुओं के साथ काम करता है। लेकिन यह नेटवर्क पर उपलब्ध एक सेवा के साथ काम करता है, और कनेक्शन और डेटा ट्रांसफर की स्थापना पर
इसमें समय लगता है। यहां तक ​​कि अगर अनुरोध 50ms निष्पादित किया जाता है, तो 20 अनुरोधों को एक सेकंड के लिए निष्पादित किया जाएगा।

अतिरिक्त डेटा

ऊपर वर्णित एन + 1 समस्या से बचने के लिए कहें, आप ऐसा लिखते हैं
अनुरोध :

 SELECT * FROM posts JOIN LATERAL ( SELECT * FROM likes WHERE post_id = posts.id ORDER BY likes.id DESC LIMIT 1 ) as last_like ON true; 

यानी पद की विशेषताओं के अलावा, अंतिम की सभी विशेषताओं को भी चुना गया है। यह डेटा मैप किस इकाई के लिए है? इस मामले में, आप पोस्ट से एक जोड़े को वापस कर सकते हैं और जैसे, क्योंकि परिणाम में सभी आवश्यक विशेषताएँ हैं।

लेकिन क्या होगा अगर हम केवल खेतों के कुछ हिस्सों का चयन करें, या चयनित फ़ील्ड जो मॉडल में नहीं हैं, उदाहरण के लिए, प्रकाशन की संख्या पसंद है? क्या उन्हें संस्थाओं पर मैप करने की आवश्यकता है? शायद उन्हें सिर्फ डेटा छोड़ दें?

राज्य और पहचान

जेएस कोड पर विचार करें:

 const alice = { id: 0, name: 'Alice' }; 

यहां, ऑब्जेक्ट संदर्भ को alice नाम दिया गया था। क्योंकि यह एक स्थिरांक है, फिर ऐलिस को किसी अन्य वस्तु को कॉल करने का कोई तरीका नहीं है। इसी समय, वस्तु स्वयं ही परस्पर बनी रही।

उदाहरण के लिए, हम एक मौजूदा पहचानकर्ता को असाइन कर सकते हैं:

 const bob = { id: 1, name: 'Bob' }; alice.id = bob.id; 

मुझे आपको याद दिलाना है कि एक इकाई की 2 पहचान हैं: एक लिंक और डेटाबेस में एक प्राथमिक कुंजी। और कॉन्स्टेंट सेव करने के बाद भी ऐलिस बॉब बनाना बंद नहीं कर सकते।

ऑब्जेक्ट, जिस लिंक को हमने alice कहा है, 2 कर्तव्यों को करता है: यह एक साथ मॉडल पहचान और राज्य करता है। एक राज्य एक मूल्य है जो एक निश्चित समय में एक इकाई का वर्णन करता है।

लेकिन क्या होगा अगर हम इन 2 जिम्मेदारियों को अलग कर दें और राज्य के लिए अपरिवर्तनीय संरचनाओं का उपयोग करें?

 function Ref(initialState, validator) { let state = initialState; this.deref = () => state; this.swap = (updater) => { const newState = updater(state); if (! validator(state, newState) ) throw "Invalid state"; state = newState; return newState; }; } const UserState = Immutable.Record({ id: null, name: '' }); const aliceState = new UserState({id: 0, name: 'Alice'}); const alice = new Ref( aliceState, (oldS, newS) => oldS.id === newS.id ); alice.swap( oldS => oldS.set('name', 'Queen Alice') ); alice.swap( oldS => oldS.set('id', 1) ); // BOOM! 

Ref - एक अपरिवर्तित राज्य के लिए एक कंटेनर, इसके नियंत्रित प्रतिस्थापन की अनुमति देता है। जैसे हम वस्तुओं का नाम लेते हैं, वैसे ही मॉडल पहचान को देखें। वोल्गा नदी को हम कहते हैं, लेकिन हर समय इसकी एक अलग अपरिवर्तनीय स्थिति होती है।

भंडारण

निम्नलिखित एपीआई पर विचार करें:

 storage.tx( t => { const alice = t.get(0); const bobState = new UserState({id: 1, name: 'Bob'}); const bob = t.create(bobState); alice.swap( oldS => oldS.update('friends', old => old.push(bob.deref.id)) ); }); 

t.get और t.create Ref का एक उदाहरण देते हैं।

हम व्यापार लेनदेन t खोलते हैं, ऐलिस को उसके पहचानकर्ता द्वारा खोजते हैं, बॉब बनाते हैं और संकेत देते हैं कि ऐलिस बॉब को अपना दोस्त मानता है।

ऑब्जेक्ट t ref के निर्माण को नियंत्रित करता है।

t स्वयं के भीतर इकाई पहचानकर्ताओं के मानचित्रण को स्टोर कर सकता है, जिसमें ref राज्य होता है। यानी आइडेंटिटी मैप लागू कर सकते हैं। इस मामले में, t एक कैश के रूप में कार्य करता है, ऐलिस के बार-बार अनुरोध पर, डेटाबेस के लिए कोई अनुरोध नहीं होगा।

t लेनदेन के अंत में ट्रैक करने के लिए संस्थाओं की प्रारंभिक स्थिति को याद रख सकता है जो परिवर्तन को डेटाबेस में लिखे जाने की आवश्यकता है। यानी कार्य की इकाई को लागू कर सकते हैं। या, यदि Ref पर्यवेक्षक समर्थन जोड़ा जाता है, तो ref में प्रत्येक परिवर्तन के साथ डेटाबेस में परिवर्तन को रीसेट करना संभव हो जाता है। ये परिवर्तन को ठीक करने के लिए आशावादी और निराशावादी दृष्टिकोण हैं।

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

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

एपीआई आपको एक समय में संस्थाओं को निकालने की अनुमति देता है, जो बहुत इष्टतम नहीं है। क्योंकि हमने आइडेंटिटी मैप पैटर्न लागू किया है, फिर हम एपीआई में preload विधि में प्रवेश कर सकते हैं:

 storage.tx( t => { t.preload([0, 1, 2, 3]); const alice = t.get(0); // from cache }); 

प्रश्नों

यदि हम लंबे लेनदेन नहीं चाहते हैं, तो हम एक मनमानी कुंजी द्वारा चयन नहीं कर सकते, क्योंकि स्मृति में गंदी वस्तुएं हो सकती हैं और चयन एक अप्रत्याशित परिणाम देगा।

हम क्वेरी का उपयोग कर सकते हैं और लेनदेन के बाहर किसी भी डेटा (स्थिति) को पुनः प्राप्त कर सकते हैं और लेनदेन में डेटा को फिर से पढ़ सकते हैं।

 const aliceId = userQuery.findByEmail('alice@mail.com'); storage.tx( t => { const alice = t.getOne(aliceId); }); 

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

आदेश

ऐसी स्थितियां हैं जब डेटा पढ़ने के बिना एक ऑपरेशन किया जा सकता है। उदाहरण के लिए, सभी ग्राहकों के खातों से मासिक शुल्क घटाएं। या संघर्ष के मामले में डेटा (upsert) डालें और अपडेट करें।

प्रदर्शन की समस्याओं के मामले में, स्टोरेज और क्वेरी से बंडल को इस तरह के कमांड से बदला जा सकता है।

संचार

यदि इकाइयाँ एक दूसरे को बेतरतीब ढंग से संदर्भित करती हैं, तो उन्हें बदलते समय स्थिरता सुनिश्चित करना मुश्किल है। संबंध सरल बनाने, सुव्यवस्थित करने, अनावश्यक त्याग करने का प्रयास करते हैं।

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

उदाहरण के लिए, कुल मिलाकर लेंट (मूल) और इसके अनुवाद शामिल हो सकते हैं। या आदेश और उसकी स्थिति।

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

निष्कर्ष

मैंने डेटाबेस के साथ काम करते समय समस्याओं पर जोर दिया, प्रतिरक्षा का उपयोग करने का विकल्प दिखाया।
लेख का प्रारूप विषय को विस्तार से प्रकट करने की अनुमति नहीं देता है।

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