कौन सा बेहतर है - ओरेकल या रेडिस या प्लेटफ़ॉर्म की पसंद को कैसे उचित ठहराया जाए

"यह ज़रूरी है," उसने किसी को संबोधित न करते हुए ज़ोर से कहा। - यह ज़रूरी है! यह बिल्कुल यही कहता है: किसी कंपनी का मुख्य कार्य शेयरधारकों के हित में लाभ कमाना है। खैर, इसके बारे में सोचो! वे किसी चीज़ से नहीं डरते!

यूलि डबोव, "कम बुराई"

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

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

अभिप्रेरण

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

स्वाभाविक रूप से, आप कम भुगतान करना और अधिक पाना चाहते हैं। हालाँकि, आपको यह निर्णय लेने की आवश्यकता है कि क्या अधिक महत्वपूर्ण है - कम भुगतान करना या अधिक प्राप्त करना, और प्रत्येक नोड को एक भार निर्दिष्ट करना होगा। आइए मान लें कि हमारे लिए सस्ते समाधान की तुलना में उच्च-गुणवत्ता वाला समाधान अधिक महत्वपूर्ण है, और हम "लागत" नोड को 40% और "अवसर" नोड को 60% का भार देते हैं।

बड़े निगमों में, आमतौर पर विपरीत सच होता है - लागत भार 50% से कम नहीं होता है, और शायद 60% से अधिक। मॉडल उदाहरण में, यह सब महत्वपूर्ण है कि किसी भी मूल नोड के चाइल्ड नोड्स का कुल वजन 100% होना चाहिए।

कट-ऑफ स्थितियाँ

वेबसाइट db-engines.com लगभग 500 डेटाबेस प्रबंधन प्रणालियाँ ज्ञात हैं। स्वाभाविक रूप से, यदि आप इतने सारे विकल्पों में से एक लक्ष्य मंच चुनते हैं, तो आप एक समीक्षा लेख के साथ समाप्त हो सकते हैं, लेकिन एक वाणिज्यिक परियोजना के साथ नहीं। चॉइस स्पेस को कम करने के लिए, कट-ऑफ मानदंड तैयार किए जाते हैं, और यदि प्लेटफ़ॉर्म इन मानदंडों को पूरा नहीं करता है, तो उस पर विचार नहीं किया जाता है।

कट-ऑफ मानदंड तकनीकी सुविधाओं से संबंधित हो सकते हैं, उदाहरण के लिए:

• एसिड गारंटी;
• संबंधपरक डेटा मॉडल;
• SQL भाषा समर्थन (ध्यान दें, यह "रिलेशनल मॉडल" के समान नहीं है);
• क्षैतिज स्केलिंग की संभावना.

सामान्य मानदंड हो सकते हैं:

• रूस में व्यावसायिक सहायता की उपलब्धता;
• खुला स्त्रोत;
• दूरसंचार और जन संचार मंत्रालय के रजिस्टर में मंच की उपलब्धता;
• कुछ रेटिंग में प्लेटफ़ॉर्म की उपस्थिति (उदाहरण के लिए, db-engines.com रेटिंग के पहले सौ में);
• बाज़ार में विशेषज्ञों की उपस्थिति (उदाहरण के लिए, वेबसाइट hh.ru पर बायोडाटा में प्लेटफ़ॉर्म के नाम की खोज के परिणामों के आधार पर)।

आख़िरकार, उद्यम-विशिष्ट मानदंड हो सकते हैं:

• कर्मचारियों पर विशेषज्ञों की उपलब्धता;
• मॉनिटरिंग सिस्टम एक्स या बैकअप सिस्टम वाई के साथ संगतता, जिस पर सभी समर्थन आधारित हैं...

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

लागत का अनुमान

समाधान की लागत में स्पष्ट रूप से लाइसेंस की लागत, समर्थन की लागत और उपकरण की लागत शामिल होती है।

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

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

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

सही तुलना के लिए एक महत्वपूर्ण बिंदु समान समर्थन शर्तें हैं। उदाहरण के लिए, Oracle समर्थन की लागत प्रति वर्ष लाइसेंस मूल्य का 22% है, लेकिन आपको PostgreSQL समर्थन के लिए भुगतान नहीं करना पड़ता है। क्या इस तरह तुलना करना सही है? नहीं, क्योंकि एक त्रुटि जिसे आपके द्वारा ठीक नहीं किया जा सकता है, उसके पूरी तरह से अलग परिणाम होते हैं: पहले मामले में, सहायता विशेषज्ञ आपको इसे ठीक करने में तुरंत मदद करेंगे, लेकिन दूसरे मामले में, परियोजना में देरी होने या समाप्त होने के समय में देरी होने का जोखिम होता है। अनिश्चित काल के लिए प्रणाली.

आप गणना की शर्तों को तीन तरीकों से बराबर कर सकते हैं:

1. बिना समर्थन के Oracle का उपयोग करें (वास्तव में ऐसा नहीं होता है)।
2. PostgreSQL के लिए समर्थन खरीदें - उदाहरण के लिए, Postgres Professional से।
3. समर्थन की कमी से जुड़े जोखिमों को ध्यान में रखें।

उदाहरण के लिए, जोखिम गणना इस तरह दिख सकती है: घातक डेटाबेस विफलता की स्थिति में, सिस्टम डाउनटाइम 1 कार्यदिवस होगा। सिस्टम का उपयोग करने से अनुमानित लाभ 40 बिलियन एमएनटी प्रति वर्ष है, दुर्घटना दर 1/400 होने का अनुमान है, इस प्रकार समर्थन की कमी का जोखिम लगभग 100 मिलियन एमएनटी प्रति वर्ष होने का अनुमान है। जाहिर है, "योजनाबद्ध लाभ" और "अनुमानित दुर्घटना आवृत्ति" आभासी मूल्य हैं, लेकिन ऐसा कोई मॉडल न होने की तुलना में ऐसा मॉडल होना कहीं बेहतर है।

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

आइए मान लें कि सभी गणनाओं के बाद, 5 वर्षों के लिए ऑपरेटिंग प्लेटफॉर्म ए की लागत 800 मिलियन एमएनटी, ऑपरेटिंग प्लेटफॉर्म बी की लागत 650 मिलियन एमएनटी और ऑपरेटिंग प्लेटफॉर्म सी की लागत 600 मिलियन एमएनटी हो जाती है। प्लेटफ़ॉर्म सी, विजेता के रूप में, कीमत के लिए एक पूर्ण अंक प्राप्त करता है, जबकि प्लेटफ़ॉर्म ए और बी को थोड़ा कम मिलता है, इस अनुपात में कि वे कितनी बार अधिक महंगे हैं। इस मामले में - क्रमशः 0.75 और 0.92 अंक।

अवसर का आकलन

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

विकास कार्यों में शामिल हैं:

• डेटा हेरफेर में आसानी;
• स्केलिंग;
• द्वितीयक सूचकांकों की उपस्थिति.

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

प्रशासन के कार्यों में शामिल हैं:

• बैकअप सिस्टम क्षमताएं;
• निगरानी में आसानी;
• क्षमता प्रबंधन में आसानी - डिस्क और नोड्स;
• डेटा प्रतिकृति क्षमताएँ।

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

उपकरण
टिप्पणी
मूल्यांकन

छोटा सा भूत/एक्सप
डेटा अपलोड और लोड करना
0.1

बैकअप प्रारंभ/समाप्ति करें
फ़ाइलों की प्रतिलिपि बनाना
0.3

आरमेंन
वृद्धिशील प्रतिलिपि क्षमता
0.7

ZDLRA
केवल वृद्धिशील प्रतिलिपि, बिंदु तक सबसे तेज़ पुनर्प्राप्ति
1.0

यदि कोई स्पष्ट मूल्यांकन मानदंड नहीं हैं, तो कई विशेषज्ञों से रेटिंग देने और फिर उन्हें औसत करने के लिए कहना समझ में आता है।

अंत में, हम केवल सूचना सुरक्षा कार्यों को सूचीबद्ध करते हैं:

• पासवर्ड प्रबंधन नीतियों की उपलब्धता;
• बाहरी प्रमाणीकरण उपकरण (एलडीएपी, केर्बरोस) को जोड़ने की क्षमता;
• पहुंच का रोल मॉडल;
• लेखापरीक्षा क्षमताएं;
• डिस्क पर डेटा का एन्क्रिप्शन;
• नेटवर्क पर ट्रांसमिशन के दौरान एन्क्रिप्शन (टीएलएस);
• व्यवस्थापक से डेटा सुरक्षा.

प्रदर्शन का परीक्षण

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

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

दूसरे, सिस्टम का प्रदर्शन काफी हद तक इस बात पर निर्भर करता है कि कोड मूल रूप से किस प्लेटफ़ॉर्म के लिए लिखा गया था और परीक्षण किस उपकरण पर किया गया था। मैंने कई परीक्षण देखे हैं जहां Oracle की तुलना PostgreSQL से की गई थी। परिणाम एक प्रणाली की बिना शर्त श्रेष्ठता से लेकर दूसरे की समान रूप से बिना शर्त श्रेष्ठता तक होते हैं।

और अंत में, तीसरी बात, आपको इस बारे में कुछ भी पता नहीं है कि परीक्षण किसने किया। दोनों योग्यताएं महत्वपूर्ण हैं, जो ओएस और प्लेटफ़ॉर्म की स्थापना की गुणवत्ता के साथ-साथ प्रेरणा को भी प्रभावित करती हैं, जो अन्य सभी कारकों की तुलना में परीक्षण परिणामों को अधिक प्रभावित करती हैं।

यदि प्रदर्शन एक महत्वपूर्ण कारक है, तो परीक्षण स्वयं करें, अधिमानतः उन लोगों की मदद से जो उत्पादन प्रणाली को कॉन्फ़िगर और बनाए रखेंगे।

परिणाम

अंत में, किए गए सभी कार्यों का परिणाम एक स्प्रेडशीट होना चाहिए जहां सभी अनुमान संयुक्त, गुणा और सारांशित किए जाएं:

जैसा कि आप समझते हैं, पैमानों को बदलकर और रेटिंग को समायोजित करके आप कोई भी वांछित परिणाम प्राप्त कर सकते हैं, लेकिन यह पूरी तरह से अलग कहानी है...

स्रोत: www.habr.com