कुन राम्रो छ - ओरेकल वा रेडिस वा प्लेटफर्मको छनौटलाई कसरी औचित्य दिने

"यो आवश्यक छ," उनले कसैलाई सम्बोधन नगरी ठूलो स्वरमा भनिन्। - यो आवश्यक छ! यो वास्तवमा के भन्छ: कम्पनीको मुख्य कार्य शेयरधारकहरूको हितमा नाफा बनाउनु हो। खैर, यसको बारेमा सोच्नुहोस्! उनीहरूलाई कुनै कुराको डर छैन!

युली डुबोव, "कम दुष्ट"

यस्तो शीर्षक देखेपछि, तपाईंले सायद पहिले नै निर्णय गर्नुभएको छ कि लेख या त मूर्खता वा एक उत्तेजना हो। तर निष्कर्षमा हतार नगर्नुहोस्: ठूला निगमहरूका कर्मचारीहरू, विशेष गरी राज्यको सहभागिता भएका निगमहरू, प्रायः फरक प्लेटफर्महरू तुलना गर्नुपर्दछ, पूर्ण रूपमा भिन्नहरू सहित - उदाहरणका लागि, शीर्षकमा भएकाहरू।

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

प्रेरणा

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

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

ठूला निगमहरूमा, विपरित सामान्यतया सत्य हुन्छ - लागत वजन 50% भन्दा कम हुँदैन, र शायद 60% भन्दा बढी। मोडेल उदाहरणमा, सबै महत्त्वपूर्ण छ कि कुनै पनि अभिभावक नोडको बाल नोडहरूको कुल वजन 100% हुनुपर्छ।

कट-अफ सर्तहरू

वेबसाइट db-engines.com त्यहाँ लगभग 500 डाटाबेस व्यवस्थापन प्रणालीहरू ज्ञात छन्। स्वाभाविक रूपमा, यदि तपाईंले धेरै विकल्पहरूबाट लक्ष्य प्लेटफर्म छनौट गर्नुभयो भने, तपाईंले समीक्षा लेखको साथ समाप्त गर्न सक्नुहुन्छ, तर व्यावसायिक परियोजना होइन। छनोट ठाउँ घटाउनको लागि, कट-अफ मापदण्डहरू बनाइन्छ, र यदि प्लेटफर्मले यी मापदण्डहरू पूरा गर्दैन भने, यसलाई मानिने छैन।

कट-अफ मापदण्डहरू प्राविधिक सुविधाहरूसँग सम्बन्धित हुन सक्छन्, उदाहरणका लागि:

• ACID ग्यारेन्टी;
• सम्बन्ध डेटा मोडेल;
• SQL भाषा समर्थन (नोट, यो "रिलेशनल मोडेल" जस्तै होइन);
• तेर्सो स्केलिंगको सम्भावना।

त्यहाँ सामान्य मापदण्ड हुन सक्छ:

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

आखिर, त्यहाँ उद्यम-विशिष्ट मापदण्ड हुन सक्छ:

• कर्मचारी मा विशेषज्ञहरु को उपलब्धता;
• अनुगमन प्रणाली X वा ब्याकअप प्रणाली Y संग अनुकूलता, जसमा सबै समर्थन आधारित छ...

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

लागत अनुमान

समाधानको लागत स्पष्ट रूपमा इजाजतपत्रको लागत, समर्थनको लागत र उपकरणको लागत समावेश गर्दछ।

यदि प्रणालीहरू लगभग एउटै वर्ग हुन् (उदाहरणका लागि, Microsoft SQL Server र PostgreSQL), त्यसपछि सरलताको लागि हामी मान्न सक्छौं कि दुबै समाधानहरूको लागि उपकरणको मात्रा लगभग समान हुनेछ। यसले तपाईंलाई उपकरणको मूल्याङ्कन गर्न अनुमति दिनेछ, जसले गर्दा धेरै समय र प्रयास बचत हुनेछ। यदि तपाईंले पूर्णतया फरक प्रणालीहरू तुलना गर्नुपर्दछ (ओरेकल बनाम रेडिस), तब यो स्पष्ट छ कि सही मूल्याङ्कनका लागि साइजिङ (उपकरणको मात्राको गणना) गर्न आवश्यक छ। एक अस्तित्वहीन प्रणालीको आकार एक धेरै कृतज्ञ कार्य हो, त्यसैले तिनीहरू अझै पनि त्यस्ता तुलनाहरूबाट बच्न प्रयास गर्छन्। यो गर्न सजिलो छ: कट-अफ सर्तहरूमा, शून्य डेटा हानि र एक रिलेशनल मोडेल लेखिएको छ, वा यसको विपरित - प्रति सेकेन्ड 50 हजार लेनदेनको लोड।

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

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

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

तपाईं तीन तरिकामा गणना अवस्थाहरू बराबर गर्न सक्नुहुन्छ:

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

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

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

हामी सबै गणना पछि, 5 वर्षको लागि अपरेटिङ प्लेटफर्म A को लागत 800 मिलियन MNT, अपरेटिङ प्लेटफर्म B को लागत 650 मिलियन MNT, र अपरेटिंग प्लेटफर्म C को लागत 600 मिलियन MNT छ भनेर मानौं। प्लेटफर्म C, विजेताको रूपमा, मूल्यको लागि पूर्ण अंक प्राप्त गर्दछ, जबकि प्लेटफर्म A र B ले थोरै कम प्राप्त गर्दछ, तिनीहरू कति पटक बढी महँगो छन् भन्ने अनुपातमा। यस अवस्थामा - क्रमशः 0.75 र 0.92 अंक।

अवसर मूल्याङ्कन

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

विकास कार्यहरू समावेश छन्:

• डाटा हेरफेर को सजिलो;
• मापन;
• माध्यमिक सूचकांकहरूको उपस्थिति।

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

प्रशासनिक कार्यहरू समावेश छन्:

• ब्याकअप प्रणाली क्षमताहरू;
• निगरानी को सजिलो;
• क्षमता व्यवस्थापनको सहजता - डिस्क र नोडहरू;
• डाटा प्रतिकृति क्षमताहरू।

कृपया ध्यान दिनुहोस् कि प्रश्नहरू मात्रात्मक रूपमा शब्दहरू हुनुपर्छ। तपाइँ पनि एक विशेष प्रकार्य कसरी मूल्याङ्कन गर्ने मा सहमत हुन सक्नुहुन्छ। आउनुहोस्, उदाहरणका लागि, Oracle DBMS सँग आपूर्ति गरिएका उपकरणहरूको उदाहरण प्रयोग गरेर ब्याकअप उपकरणहरू मूल्याङ्कन गर्ने प्रयास गरौं:

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

imp/exp
डाटा अपलोड र लोड गर्दै
0.1

ब्याकअप सुरु/अन्तमा
फाइलहरू प्रतिलिपि गर्दै
0.3

RMAN
बढ्दो प्रतिलिपि क्षमता
0.7

ZDLRA
केवल वृद्धिशील प्रतिलिपि, बिन्दुमा छिटो रिकभरी
1.0

यदि त्यहाँ कुनै स्पष्ट मूल्याङ्कन मापदण्ड छैन भने, यसले धेरै विशेषज्ञहरूलाई मूल्याङ्कन दिन र त्यसपछि तिनीहरूलाई औसत गर्न सोध्नु उचित हुन्छ।

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

• पासवर्ड व्यवस्थापन नीतिहरूको उपलब्धता;
• बाह्य प्रमाणीकरण उपकरणहरू जडान गर्ने क्षमता (LDAP, Kerberos);
• पहुँच को रोल मोडेल;
• अडिट क्षमताहरू;
• डिस्क मा डाटा को गुप्तिकरण;
• नेटवर्क (TLS) मा प्रसारण समयमा गुप्तिकरण;
• प्रशासकबाट डाटा सुरक्षा।

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

अलग रूपमा, म कुनै पनि लोड परीक्षणको नतिजाहरू प्रयोग गर्न विरुद्ध चेतावनी दिन चाहन्छु जुन तपाईंद्वारा तर्कको रूपमा बनाइएको थिएन।

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

दोस्रो, प्रणालीको कार्यसम्पादन कुन प्लेटफर्मको लागि मूल रूपमा कोड लेखिएको थियो र कुन उपकरणमा परीक्षण गरिएको थियो भन्ने कुरामा पूर्ण रूपमा निर्भर गर्दछ। मैले धेरै परीक्षणहरू देखेको छु जहाँ Oracle PostgreSQL सँग तुलना गरिएको थियो। परिणामहरू एक प्रणालीको बिना शर्त श्रेष्ठतादेखि अर्कोको समान रूपमा बिना शर्त श्रेष्ठतासम्म हुन्छन्।

र अन्तमा, तेस्रो, तपाईलाई कसले परीक्षण गर्यो भन्ने बारे केहि थाहा छैन। दुबै योग्यताहरू महत्त्वपूर्ण छन्, OS र प्लेटफर्म सेटअपको गुणस्तरलाई प्रभाव पार्ने, साथै प्रेरणा, जसले परीक्षण परिणामहरूलाई संयुक्त रूपमा अन्य सबै कारकहरू भन्दा बढी प्रभाव पार्छ।

यदि प्रदर्शन एक महत्वपूर्ण कारक हो भने, परीक्षण आफैं सञ्चालन गर्नुहोस्, अधिमानतः उत्पादन प्रणाली कन्फिगर र मर्मत गर्ने व्यक्तिहरूको सहयोगमा।

परिणाम

अन्तमा, सबै कामको नतिजा एक स्प्रेडसिट हुनुपर्छ जहाँ सबै अनुमानहरू संयुक्त, गुणन र संक्षेप गरिएको छ:

तपाईंले बुझ्नुभएको रूपमा, स्केलहरू परिवर्तन गरेर र मूल्याङ्कनहरू समायोजन गरेर तपाईंले कुनै पनि इच्छित परिणाम प्राप्त गर्न सक्नुहुन्छ, तर त्यो पूर्ण रूपमा फरक कथा हो...

स्रोत: www.habr.com