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

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

यूली डुबोव, "द लेसर इविल"

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

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

अभिप्रेरण

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

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

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

कट-ऑफ शर्तें

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

कट-ऑफ मानदंड तकनीकी विशेषताओं से संबंधित हो सकते हैं, जैसे:

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

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

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

अंत में, कंपनी के लिए विशिष्ट मानदंड हो सकते हैं:

• स्टाफ पर विशेषज्ञों की उपलब्धता;
• मॉनिटरिंग सिस्टम X या बैकअप सिस्टम Y के साथ संगतता, जिससे सभी समर्थन जुड़ा हुआ है…

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

लागत आकलन

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

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

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

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

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

गणना की स्थितियों को समान करने के तीन तरीके हैं:

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

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

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

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

अवसर का आकलन

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

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

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

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

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

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

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

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

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

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

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

जेडडीएलआरए
केवल वृद्धिशील बैकअप, बिंदु पर सबसे तेज़ पुनर्स्थापना
1.0

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

अंत में, आइए सूचना सुरक्षा कार्यों की सूची बनाएं:

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

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

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

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

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

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

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

परिणाम

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

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

स्रोत: www.habr.com