Қайсысы жақсы – Oracle немесе Redis немесе платформаны таңдауды қалай негіздеуге болады

«Бұл қажет», - деді ол дауыстап, ешкімге хабарласпай. - Бұл керек! Мұнда дәл осылай айтылған: компанияның негізгі міндеті – акционерлердің мүддесі үшін пайда табу. Ал, ойланыңыз! Олар ештеңеден қорықпайды!

Юлий Дубов, «Кіші зұлымдық»

Мұндай тақырыпты көріп, сіз мақаланы не ақымақтық, не арандатушылық деп шешкен шығарсыз. Бірақ қорытынды жасауға асықпаңыз: ірі корпорациялардың қызметкерлері, әсіресе мемлекет қатысатын корпорациялар, әртүрлі платформаларды, соның ішінде мүлдем басқаларын, мысалы, тақырыптағыларды салыстыруға тура келеді.

Қайсысы жақсы – Oracle немесе Redis немесе платформаны таңдауды қалай негіздеуге болады

Әрине, ешкім ДҚБЖ-ны бұлай салыстырмайды, өйткені олардың күшті және әлсіз жақтары белгілі. Әдетте, кейбір қолданбалы мәселелерді шешетін платформалар салыстыруға жатады. Мақалада мен Habr оқырмандарына таныс тақырып ретінде деректер базасының мысалын пайдаланып, осы жағдайда қолданылатын әдістемені көрсетемін. Сонымен,

Мотивация

Сіз білім беру жобасын немесе хобби жобасын бастаған кезде, платформаны таңдау мотивациясы өте әртүрлі болуы мүмкін: «бұл мен жақсы білетін платформа», «мен оны түсінуге қызығамын», «міне ең жақсы құжаттама» ...Коммерциялық компания болса, іріктеу критерийі бірдей: мен қанша төлеуім керек және бұл ақшаға не аламын.

Әрине, сіз аз төлеп, көп алғыңыз келеді. Дегенмен, сіз не маңыздырақ екенін шешуіңіз керек - аз төлеу немесе көп алу және әрбір түйінге салмақ тағайындаңыз. Біз үшін арзанға қарағанда жоғары сапалы шешім маңызды деп есептейік және біз «Шығын» түйініне 40%, ал «Мүмкіндіктер» түйініне 60% салмақ тағайындаймыз.

Қайсысы жақсы – Oracle немесе Redis немесе платформаны таңдауды қалай негіздеуге болады

Ірі корпорацияларда, әдетте, керісінше болады - шығындардың салмағы 50% -дан төмен түспейді, мүмкін 60% -дан жоғары. Үлгі мысалында маңыздысы кез келген ата-аналық түйіннің еншілес түйіндерінің жалпы салмағы 100% болуы керек.

Кесу шарттары

Веб-сайт db-engines.com 500-ге жуық дерекқорды басқару жүйесі белгілі. Әрине, егер сіз көптеген нұсқалардың ішінен мақсатты платформаны таңдасаңыз, коммерциялық жоба емес, шолу мақаласы болуы мүмкін. Таңдау кеңістігін азайту үшін кесу критерийлері тұжырымдалады, ал егер платформа осы критерийлерге сәйкес келмесе, онда ол қарастырылмайды.

Шектеу критерийлері технологиялық ерекшеліктерге қатысты болуы мүмкін, мысалы:

  • ACID кепілдіктері;
  • реляциялық деректер моделі;
  • SQL тілін қолдау (ескерту, бұл «реляциялық үлгімен» бірдей емес);
  • көлденең масштабтау мүмкіндігі.

Жалпы критерийлер болуы мүмкін:

  • Ресейде коммерциялық қолдаудың болуы;
  • ашық дереккөз;
  • телекоммуникациялар және бұқаралық коммуникациялар министрлігінің тізілімінде платформаның болуы;
  • платформаның кейбір рейтингте болуы (мысалы, db-engines.com рейтингінің бірінші жүздігінде);
  • нарықта сарапшылардың болуы (мысалы, hh.ru веб-сайтындағы түйіндемеде платформа атауын іздеу нәтижелері бойынша).

Өйткені, кәсіпорынға тән критерийлер болуы мүмкін:

  • штатта мамандардың болуы;
  • мониторинг жүйесі X немесе сақтық көшірме жүйесі Y, барлық қолдау негізінде үйлесімділік...

Ең бастысы, кесу критерийлерінің тізімі бар. Әйтпесе, басшылықтың ерекше сеніміне ие болған кейбір сарапшы (немесе «сарапшы») міндетті түрде болады, олар «неге сіз Z платформасын таңдамадыңыз, мен бұл ең жақсы екенін білемін» деп жауап береді.

Шығындар сметасы

Шешімнің құны лицензиялар құнынан, қолдау құнынан және жабдық құнынан тұратыны анық.

Егер жүйелер шамамен бірдей класс болса (мысалы, Microsoft SQL Server және PostgreSQL), қарапайым болу үшін екі шешімге арналған жабдықтың көлемі шамамен бірдей болады деп болжауға болады. Бұл жабдықты бағаламауға мүмкіндік береді, осылайша көп уақыт пен күш-жігерді үнемдейді. Егер сізге мүлде басқа жүйелерді салыстыруға тура келсе (айталық, Oracle және Redis), онда дұрыс бағалау үшін өлшемдерді (жабдық көлемін есептеу) жасау керек екені анық. Жоқ жүйенің өлшемін анықтау өте ризашылықсыз жұмыс, сондықтан олар әлі де мұндай салыстырудан аулақ болуға тырысады. Мұны істеу оңай: кесу жағдайында деректердің нөлдік жоғалуы және реляциялық модель жазылады немесе керісінше - секундына 50 мың транзакция жүктемесі.

Лицензияларды бағалау үшін жеткізушіден немесе оның серіктестерінен ядролардың белгіленген санына лицензия құнын және белгіленген кезеңге қолдау көрсетуді сұрау жеткілікті. Әдетте, компаниялардың бағдарламалық жасақтама жеткізушілерімен тығыз қарым-қатынасы бар және егер деректер базасының операциялар бөлімі шығындар туралы сұраққа өздігінен жауап бере алмаса, онда бұл ақпаратты алу үшін бір әріп жеткілікті.

Әртүрлі жеткізушілерде әртүрлі лицензиялау көрсеткіштері болуы мүмкін: ядролар саны, деректер көлемі немесе түйіндер саны бойынша. Күту режимінің базасы тегін болуы мүмкін немесе ол негізгі сияқты лицензиялануы мүмкін. Көрсеткіштердегі қандай да бір айырмашылықтар табылса, үлгі стендті егжей-тегжейлі сипаттап, стендке арналған лицензиялардың құнын есептеу керек болады.

Дұрыс салыстыру үшін маңызды сәт - бірдей қолдау шарттары. Мысалы, Oracle қолдауы жылына лицензия бағасының 22% тұрады, бірақ PostgreSQL қолдауына ақы төлеудің қажеті жоқ. Бұлай салыстыру дұрыс па? Жоқ, өйткені өз бетімен түзетілмейтін қатенің салдары мүлде басқаша болады: бірінші жағдайда қолдау көрсету мамандары оны түзетуге тез көмектеседі, ал екінші жағдайда жобаны кешіктіру немесе аяқталған жұмыстың тоқтап қалу қаупі бар. белгісіз мерзімге арналған жүйе.

Есептеу шарттарын үш жолмен теңестіруге болады:

  1. Oracle қолданбасын қолдаусыз пайдаланыңыз (шын мәнінде бұл болмайды).
  2. PostgreSQL қолдауын сатып алыңыз - мысалы, Postgres Professional.
  3. Қолдаудың болмауына байланысты тәуекелдерді ескеріңіз.

Мысалы, тәуекелді есептеу келесідей болуы мүмкін: қауіпті дерекқор ақаулығы жағдайында жүйенің тоқтап қалу уақыты 1 жұмыс күнін құрайды. Жүйені пайдаланудан түсетін болжамды пайда жылына 40 миллиард теңгені құрайды, апаттың деңгейі 1/400 деп бағаланады, осылайша қолдаудың болмауы қаупі жылына шамамен 100 миллион теңгеге бағаланады. Әлбетте, «жоспарланған пайда» және «болжалды апат жиілігі» виртуалды мәндер, бірақ мұндай модель болмағаннан гөрі жақсырақ.

Шындығында, жүйе ұзақ мерзімді үзілістердің беделді құны қолайсыз болуы үшін тым маңызды болуы мүмкін, сондықтан қолдау қажет болады. Егер тоқтап тұруға рұқсат етілсе, қолдаудан бас тарту кейде ақшаны үнемдеудің жақсы жолы болуы мүмкін.

Барлық есептеулерден кейін А платформасының 5 жылдағы құны 800 млн тг, В операциялық платформасының құны 650 млн тг, С операциялық платформасының құны 600 млн тенге болып шығады деп есептейік. С платформасы жеңімпаз ретінде баға бойынша толық ұпай алады, ал A және B платформалары қанша есе қымбатқа түсетініне пропорционалды түрде сәл аз алады. Бұл жағдайда – тиісінше 0.75 және 0.92 балл.

Мүмкіндікті бағалау

Мүмкіндіктерді бағалау көптеген топтарға бөлінеді, олардың саны тек бағалауды жасайтын адамның қиялымен шектеледі. Оңтайлы нұсқа мүмкіндіктерді осы мүмкіндіктерді пайдаланатын командаларға бөлу болып көрінеді; біздің мысалда бұл әзірлеушілер, әкімшілер және ақпараттық қауіпсіздік қызметкерлері. Бұл функциялардың салмақтары 40:40:20 ретінде үлестірілді делік.

Әзірлеу функцияларына мыналар жатады:

  • деректерді өңдеудің қарапайымдылығы;
  • масштабтау;
  • қайталама көрсеткіштердің болуы.

Критерийлер тізімі, сондай-ақ олардың салмақтары өте субъективті. Тіпті бір мәселені шешкен кезде де бұл тізімдер, элементтердің салмағы және жауаптары сіздің командаңыздың құрамына байланысты айтарлықтай өзгереді. Мысалы, Facebook деректерді сақтау үшін MySQL пайдаланады, ал Instagram Кассандраға салынған. Бұл қосымшаларды әзірлеушілер мұндай кестелерді толтыруы екіталай. Марк Цукерберг толыққанды реляциялық модельді таңдап, оны қолданбалы бөлшектеу қажеттілігімен төледі деп болжауға болады, ал Кевин Систром деректерге қол жеткізуді жеңілдетіп, платформаны пайдаланып масштабтауды құрды.

Әкімшілік функцияларға мыналар жатады:

  • резервтік жүйенің мүмкіндіктері;
  • бақылаудың қарапайымдылығы;
  • сыйымдылықты басқарудың қарапайымдылығы – дискілер мен түйіндер;
  • деректерді репликациялау мүмкіндіктері.

Сұрақтар сандық түрде берілуі керек екенін ескеріңіз. Сіз тіпті белгілі бір функцияны қалай бағалау керектігі туралы келісе аласыз. Мысалы, Oracle ДҚБЖ-мен қамтамасыз етілген құралдардың мысалын пайдаланып сақтық көшірме құралдарын бағалауға тырысайық:

Құрал
Пікір
бағалау

им/exp
Деректерді жүктеп салу және жүктеу
0.1

сақтық көшірме жасауды бастау/аяқтау
Файлдарды көшіру
0.3

RMAN
Қосымша көшіру мүмкіндігі
0.7

ZDLRA
Тек қосымша көшіру, нүктеге дейін ең жылдам қалпына келтіру
1.0

Егер нақты бағалау критерийлері болмаса, бірнеше сарапшылардан рейтингтер беруді сұрап, содан кейін олардың орташа мәнін алу мағынасы бар.

Соңында, біз жай ғана ақпаратты қорғау функцияларын тізімдейміз:

  • парольді басқару саясатының болуы;
  • сыртқы аутентификация құралдарын қосу мүмкіндігі (LDAP, Kerberos);
  • қол жеткізудің үлгі үлгісі;
  • аудиторлық мүмкіндіктер;
  • дискідегі деректерді шифрлау;
  • желі арқылы жіберу кезінде шифрлау (TLS);
  • әкімшіден деректерді қорғау.

Өнімділік сынағы

Сонымен қатар, мен сіз жасамаған кез келген жүктеме сынақтарының нәтижелерін дәлел ретінде пайдаланбауды ескерткім келеді.

Біріншіден, тексерілетін қолданбалардың деректер құрылымы мен жүктеме профилі сіз шешетін мәселеден айтарлықтай өзгеше болуы мүмкін. Шамамен 10-15 жыл бұрын дерекқор жеткізушілері TPC сынақтарында қол жеткізілген нәтижелерді мақтан тұтқанды ұнататын, бірақ қазір бұл нәтижелерді ешкім байыппен қабылдамайтын сияқты.

Екіншіден, жүйенің өнімділігі кодтың бастапқыда қай платформа үшін жазылғанына және сынақ қандай жабдыққа жасалғанына байланысты. Мен Oracle-ді PostgreSQL-пен салыстырған көптеген сынақтарды көрдім. Нәтижелер бір жүйенің сөзсіз артықшылығынан екіншісінің бірдей сөзсіз артықшылығына дейін ауытқиды.

Ақырында, үшіншіден, сіз кімнің сынақтан өткені туралы ештеңе білмейсіз. Екі біліктілік те маңызды, олар операциялық жүйені және платформаны орнату сапасына әсер етеді, сондай-ақ тест нәтижелеріне барлық басқа факторларға қарағанда көбірек әсер ететін мотивация.

Егер өнімділік маңызды фактор болса, сынақты өзіңіз өткізіңіз, жақсырақ өндіріс жүйесін конфигурациялайтын және қызмет көрсететін адамдардың көмегімен.

нәтиже

Ақырында, барлық орындалған жұмыстың нәтижесі электрондық кесте болуы керек, онда барлық бағалаулар біріктіріліп, көбейтіледі және қорытындыланады:

Қайсысы жақсы – Oracle немесе Redis немесе платформаны таңдауды қалай негіздеуге болады

Түсінгеніңіздей, таразыларды өзгерту және бағалауларды реттеу арқылы сіз кез келген қалаған нәтижеге қол жеткізе аласыз, бірақ бұл мүлдем басқа әңгіме...

Ақпарат көзі: www.habr.com

пікір қалдыру