🥇 कोणते चांगले आहे - ओरॅकल किंवा रेडिस किंवा प्लॅटफॉर्मच्या निवडीचे समर्थन कसे करावे

"हे आवश्यक आहे," ती कोणालाच उद्देशून न बोलता मोठ्याने म्हणाली. - हे आवश्यक आहे! हे नेमके काय म्हणते: कंपनीचे मुख्य कार्य भागधारकांच्या हितासाठी नफा मिळवणे आहे. बरं, विचार करा! त्यांना कशाचीच भीती वाटत नाही!

युली डुबोव्ह, "लेसर एविल"

अशी मथळा पाहिल्यानंतर, तुम्ही कदाचित आधीच ठरवले असेल की लेख एकतर मूर्खपणा आहे किंवा चिथावणी देणारा आहे. परंतु निष्कर्षापर्यंत घाई करू नका: मोठ्या कॉर्पोरेशनच्या कर्मचार्‍यांना, विशेषत: राज्य सहभाग असलेल्या कॉर्पोरेशन्सना बर्‍याचदा वेगवेगळ्या प्लॅटफॉर्मची तुलना करावी लागते, ज्यामध्ये पूर्णपणे भिन्न असतात - उदाहरणार्थ, शीर्षकातील.

अर्थात, अशा प्रकारे कोणीही DBMS ची तुलना करत नाही, कारण त्यांची ताकद आणि कमकुवतपणा सर्वश्रुत आहे. नियमानुसार, काही अनुप्रयोग समस्या सोडवणारे प्लॅटफॉर्म तुलनाच्या अधीन आहेत. लेखात मी या प्रकरणात वापरलेली कार्यपद्धती दर्शवेल, डेटाबेसचे उदाहरण वापरून हा विषय वाचकांना स्वतःच परिचित आहे. तर,

प्रेरणा

जेव्हा तुम्ही एखादा शैक्षणिक प्रकल्प किंवा एखादा छंद प्रकल्प सुरू करता तेव्हा व्यासपीठ निवडण्याची प्रेरणा खूप वैविध्यपूर्ण असू शकते: “हे व्यासपीठ मला सर्वात चांगले माहीत आहे”, “मला हे समजून घेण्यात रस आहे”, “येथे सर्वोत्तम दस्तऐवजीकरण आहे” ... व्यावसायिक कंपनीच्या बाबतीत, निवड निकष समान आहे: मला किती पैसे द्यावे लागतील आणि या पैशासाठी मला काय मिळेल.

साहजिकच, तुम्हाला पैसे कमी आणि जास्त मिळवायचे आहेत. तथापि, आपण अधिक महत्त्वाचे काय आहे हे ठरवणे आवश्यक आहे - कमी पैसे देणे किंवा अधिक मिळवणे आणि प्रत्येक नोडला वजन नियुक्त करणे. चला असे गृहीत धरू की स्वस्त समाधानापेक्षा उच्च-गुणवत्तेचे समाधान आपल्यासाठी अधिक महत्त्वाचे आहे आणि आम्ही “कॉस्ट” नोडला 40% आणि “संधी” नोडला 60% वजन नियुक्त करतो.

मोठ्या कॉर्पोरेशनमध्ये, सामान्यतः उलट सत्य असते - खर्चाचे वजन 50% पेक्षा कमी होत नाही आणि कदाचित 60% पेक्षा जास्त. मॉडेल उदाहरणामध्ये, सर्व महत्त्वाचे आहे की कोणत्याही पालक नोडच्या चाइल्ड नोड्सचे एकूण वजन 100% असणे आवश्यक आहे.

कटिंग अटी

संकेतस्थळ db-engines.com सुमारे 500 डेटाबेस व्यवस्थापन प्रणाली ज्ञात आहेत. साहजिकच, तुम्ही अनेक पर्यायांमधून लक्ष्य प्लॅटफॉर्म निवडल्यास, तुम्हाला पुनरावलोकन लेख मिळेल, परंतु व्यावसायिक प्रकल्प नाही. निवडीची जागा कमी करण्यासाठी, कट-ऑफ निकष तयार केले जातात आणि जर प्लॅटफॉर्म हे निकष पूर्ण करत नसेल तर त्याचा विचार केला जात नाही.

कट-ऑफ निकष तांत्रिक वैशिष्ट्यांशी संबंधित असू शकतात, उदाहरणार्थ:

ACID हमी देते;
रिलेशनल डेटा मॉडेल;
SQL भाषा समर्थन (लक्षात ठेवा, हे "रिलेशनल मॉडेल" सारखे नाही);
क्षैतिज स्केलिंगची शक्यता.

सामान्य निकष असू शकतात:

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

शेवटी, एंटरप्राइझ-विशिष्ट निकष असू शकतात:

कर्मचार्‍यांवर तज्ञांची उपलब्धता;
मॉनिटरिंग सिस्टम X किंवा बॅकअप सिस्टम Y सह सुसंगतता, ज्यावर सर्व समर्थन आधारित आहे...

सर्वात महत्वाची गोष्ट म्हणजे कट ऑफ निकषांची यादी आहे. अन्यथा, निश्चितपणे असे काही तज्ञ (किंवा "तज्ञ") असतील ज्यांना व्यवस्थापनाकडून विशेष विश्वास आहे जे म्हणतील "तुम्ही प्लॅटफॉर्म Z का निवडले नाही, मला माहित आहे की ते सर्वोत्तम आहे."

खर्चाचा अंदाज

सोल्यूशनच्या किंमतीमध्ये परवान्यांची किंमत, समर्थनाची किंमत आणि उपकरणांची किंमत यांचा समावेश होतो.

जर सिस्टम अंदाजे समान वर्गाच्या असतील (उदाहरणार्थ, मायक्रोसॉफ्ट एसक्यूएल सर्व्हर आणि पोस्टग्रेएसक्यूएल), तर साधेपणासाठी आम्ही असे गृहीत धरू शकतो की दोन्ही सोल्यूशन्ससाठी उपकरणांची संख्या अंदाजे समान असेल. हे आपल्याला उपकरणांचे मूल्यांकन न करण्याची परवानगी देईल, ज्यामुळे बराच वेळ आणि मेहनत वाचेल. जर तुम्हाला पूर्णपणे भिन्न प्रणालींची तुलना करायची असेल (म्हणा, ओरॅकल वि. रेडिस), तर हे स्पष्ट आहे की योग्य मूल्यांकनासाठी आकारमान करणे (उपकरणांच्या रकमेची गणना) करणे आवश्यक आहे. अस्तित्वात नसलेल्या सिस्टीमला आकार देणे हे अत्यंत कृतज्ञ कार्य आहे, म्हणून ते अजूनही अशा तुलना टाळण्याचा प्रयत्न करतात. हे करणे सोपे आहे: कट-ऑफ परिस्थितीत, शून्य डेटा हानी आणि एक रिलेशनल मॉडेल लिहिलेले आहे, किंवा त्याउलट - प्रति सेकंद 50 हजार व्यवहारांचा भार.

परवान्यांचे मूल्यमापन करण्यासाठी, विक्रेत्याला किंवा त्याच्या भागीदारांना निश्चित संख्येच्या कोर आणि एका निश्चित कालावधीसाठी समर्थनासाठी परवान्याच्या किंमतीसाठी विचारणे पुरेसे आहे. नियमानुसार, कंपन्यांचे सॉफ्टवेअर विक्रेत्यांशी आधीपासूनच मजबूत संबंध आहेत आणि जर डेटाबेस ऑपरेशन्स विभाग स्वतःच्या खर्चाच्या प्रश्नाचे उत्तर देऊ शकत नसेल तर ही माहिती मिळविण्यासाठी एक पत्र पुरेसे आहे.

वेगवेगळ्या विक्रेत्यांकडे भिन्न परवाना मेट्रिक्स असू शकतात: कोरच्या संख्येनुसार, डेटा व्हॉल्यूम किंवा नोड्सच्या संख्येनुसार. स्टँडबाय बेस विनामूल्य असू शकतो किंवा मुख्य प्रमाणेच परवाना दिला जाऊ शकतो. मेट्रिक्समध्ये काही फरक आढळल्यास, तुम्हाला मॉडेल स्टँडचे तपशीलवार वर्णन करावे लागेल आणि स्टँडसाठी परवान्यांच्या किंमतीची गणना करावी लागेल.

योग्य तुलनेसाठी महत्त्वाचा मुद्दा म्हणजे समान समर्थन परिस्थिती. उदाहरणार्थ, ओरॅकल सपोर्टची किंमत प्रति वर्ष परवान्याच्या किंमतीच्या 22% आहे, परंतु तुम्हाला PostgreSQL समर्थनासाठी पैसे द्यावे लागणार नाहीत. अशी तुलना करणे योग्य आहे का? नाही, कारण एक त्रुटी जी स्वतःच दुरुस्त केली जाऊ शकत नाही त्याचे पूर्णपणे भिन्न परिणाम आहेत: पहिल्या प्रकरणात, सहाय्यक तज्ञ आपल्याला त्वरीत त्याचे निराकरण करण्यात मदत करतील, परंतु दुसर्‍या प्रकरणात, प्रकल्पास उशीर होण्याचा धोका आहे किंवा पूर्ण होण्याचा डाउनटाइम आहे. अनिश्चित काळासाठी प्रणाली.

तुम्ही गणना अटी तीन प्रकारे समान करू शकता:

समर्थनाशिवाय ओरॅकल वापरा (प्रत्यक्षात असे होत नाही).
PostgreSQL साठी समर्थन खरेदी करा - उदाहरणार्थ, Postgres Professional कडून.
समर्थनाच्या अभावाशी संबंधित जोखीम विचारात घ्या.

उदाहरणार्थ, जोखीम गणना यासारखी दिसू शकते: घातक डेटाबेस अयशस्वी झाल्यास, सिस्टम डाउनटाइम 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 चाचण्यांमध्ये मिळालेल्या निकालांची प्रशंसा करणे आवडते, परंतु आता असे दिसते की, कोणीही या निकालांना गांभीर्याने घेत नाही.

दुसरे म्हणजे, कोड मूळतः कोणत्या प्लॅटफॉर्मसाठी लिहिला गेला आणि कोणत्या उपकरणावर चाचणी केली गेली यावर सिस्टमची कार्यक्षमता जोरदारपणे अवलंबून असते. मी बर्‍याच चाचण्या पाहिल्या आहेत जिथे ओरॅकलची तुलना PostgreSQL शी केली गेली होती. परिणाम एका प्रणालीच्या बिनशर्त श्रेष्ठतेपासून दुसऱ्याच्या समान बिनशर्त श्रेष्ठतेपर्यंत असतात.

आणि शेवटी, तिसरे म्हणजे, चाचणी कोणी केली याबद्दल आपल्याला काहीही माहिती नाही. दोन्ही पात्रता महत्त्वाच्या आहेत, OS आणि प्लॅटफॉर्म सेट करण्याच्या गुणवत्तेवर प्रभाव टाकतात, तसेच प्रेरणा, जे इतर सर्व घटकांच्या एकत्रित परिणामांपेक्षा चाचणी परिणामांवर अधिक प्रभाव पाडतात.

कामगिरी हा एक महत्त्वाचा घटक असल्यास, चाचणी स्वतः करा, शक्यतो उत्पादन प्रणाली कॉन्फिगर आणि देखरेख करतील अशा लोकांच्या मदतीने.

परिणाम

शेवटी, केलेल्या सर्व कामाचा परिणाम एक स्प्रेडशीट असावा जिथे सर्व अंदाज एकत्रित, गुणाकार आणि सारांशित केले जातात:

जसे तुम्ही समजता, स्केल बदलून आणि रेटिंग समायोजित करून तुम्ही कोणताही इच्छित परिणाम साध्य करू शकता, परंतु ही एक पूर्णपणे वेगळी कथा आहे...

स्त्रोत: www.habr.com

कोणते चांगले आहे - ओरॅकल किंवा रेडिस किंवा प्लॅटफॉर्मच्या निवडीचे समर्थन कसे करावे