क्या आपने अपने हाथ साबुन से धोए थे? फिर शुगर फ्री चाय

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

मैं सभी 3 स्पष्ट विकल्पों की तरह नहीं हूँ - "एक संबंधपरक डेटाबेस का उपयोग करें", "NoSQL-DB का उपयोग करें", "परियोजना कार्यों द्वारा एक डेटाबेस का चयन करें" लेख शीर्षक में बताए गए कारण के लिए।

मैं एक उदाहरण दूंगा। जरा कल्पना करें: एक नए बड़े प्रोजेक्ट की शुरुआत, बॉस सभी डेवलपर्स को इकट्ठा करते हैं और कहते हैं, "इसलिए, हमें अब यह तय करने और निर्णय लेने की आवश्यकता है कि हम कोड में कौन से कंटेनर का उपयोग करेंगे - सरणियाँ, वैक्टर, सूचियां, कुएं, शायद पेड़।" इसे रोको! यह किस तरह का सवाल है? परियोजना अभी तक शुरू नहीं हुई है - हम कैसे जानते हैं? वैसे भी - सबसे अधिक संभावना है, कोड एक या दूसरे के विभिन्न स्थानों में उपयोग किया जाएगा - अच्छी तरह से, जहां यह अधिक प्रभावी होगा। "नहीं, नहीं," अधिकारियों का कहना है, "आपको अभी चयन करने और अनुमोदित करने की आवश्यकता है, उदाहरण के लिए, कोड में उपयोग किए जाने वाले एकमात्र कंटेनर के रूप में एक एकल लिंक की गई सूची।" क्या बकवास है ?! क्यों! "ठीक है, यह तरीका है।" पर्दा।

क्या आपने पहले ही इस उदाहरण की बेरुखी महसूस की है? अब अपने डेटाबेस में वापस आते हैं। क्लासिक रिलेशनल डेटाबेस, जैसे कि MySQL, के प्रसिद्ध फायदे हैं:

• सापेक्षता (धन्यवाद कैप)
• अपूर्ण, लेकिन सभी के लिए परिचित और सभी SQL द्वारा समर्थित
• कई तालिकाओं को अद्यतन करने के लिए ईमानदार लेनदेन

और NoSQL डेटाबेस (मैं उनके बारे में एक दस्तावेज़-उन्मुख भाग के बारे में बात कर रहा हूं) उनके फायदे हैं:

• कुंजी द्वारा त्वरित दस्तावेज़ खोज
• दस्तावेज़ की संरचना को बदलने में लचीलापन
• सरल प्रतिकृति और पैनापन

यह स्पष्ट रूप से देखा जाता है कि एक प्रकार के डेटाबेस के फायदे दूसरे प्रकार के नुकसान हैं। तो मुझे बताएं - परियोजना की शुरुआत में मुझे "साबुन से हाथ धोना या चीनी के साथ चाय पीना" क्यों चुनना चाहिए? मुझे दोनों चाहिए!

मेरे पास ऐसे डेटा हैं जो किसी भी तरह से बर्बाद या खो नहीं सकते हैं - यह उपयोगकर्ता डेटा, वित्तीय लेनदेन, मेरी सेवा के लिए कुछ विशिष्ट है। यह MySQL में निहित होगा, लेनदेन द्वारा संरक्षित, प्रमाणित उपयोगिताओं के साथ बैकअप। इस डेटा को बदलने का कार्य थोड़ी देर तक करें - उपयोगकर्ता एक अतिरिक्त आधे सेकंड का इंतजार करेगा, लेकिन 100% मामलों में वह अपने पैसे खाते में जमा करेगा।

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

तो बस किसी भी परियोजना की शुरुआत में ("मेरी बिल्ली वास्का के मुख पृष्ठ" की तुलना में बड़े पैमाने पर) दोनों प्रकार के डेटाबेस को बढ़ाने के लिए नहीं? क्या दोनों आधारों को उठाना लंबा या महंगा है?

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

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

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