Zein da hobea - Oracle edo Redis edo Nola justifikatu plataformaren aukeraketa

"Hau beharrezkoa da", esan zuen ozen, inori zuzendu gabe. - Hau beharrezkoa da! Hauxe dio, hain zuzen ere: enpresa baten zeregin nagusia akziodunen interesen irabaziak lortzea da. Tira, pentsatu! Ez dute ezeren beldur!

Yuliy Dubov, "Gaizki txikia"

Halako goiburu bat ikusita, ziurrenik dagoeneko erabaki duzu artikulua astakeria edo probokazio bat dela. Baina ez izan ondorioak ateratzeko presarik: korporazio handietako langileek, batez ere estatuaren parte-hartzea duten korporazioek, askotan plataforma desberdinak alderatu behar dituzte, guztiz desberdinak barne - adibidez, tituluan daudenak.

Zein da hobea - Oracle edo Redis edo Nola justifikatu plataformaren aukeraketa

Jakina, inork ez ditu DBMSak horrela konparatzen, haien indarguneak eta ahuleziak ezagunak direlako. Oro har, aplikazio-arazoren bat konpontzen duten plataformak konparazioaren menpe daude. Artikuluan kasu honetan erabiltzen den metodologia erakutsiko dut, datu-baseen adibidea Habr-eko irakurleek bertatik bertara ezagutzen duten gai gisa erabiliz. Beraz,

Motibazioa

Hezkuntza-proiektu bat edo zaletasun-proiektu bat hasten zarenean, plataforma bat aukeratzeko motibazioa oso anitza izan daiteke: “hau da ondoen ezagutzen dudan plataforma”, “hau ulertzea interesatzen zait”, “hemen dokumentazio onena” ... Merkataritza sozietate baten kasuan, hautaketa irizpidea bera da: zenbat ordaindu beharko dudan eta zer lortuko dudan diru horren truke.

Jakina, gutxiago ordaindu eta gehiago lortu nahi duzu. Hala ere, garrantzitsuagoa dena erabaki behar duzu: gutxiago ordaintzea edo gehiago lortzea, eta pisu bat esleitu nodo bakoitzari. Demagun kalitate handiko irtenbide bat merkeagoa baino garrantzitsuagoa dela guretzat, eta %40ko pisua esleitzen diogu “Kostua” nodoari, eta %60a “Aukerak” nodoari.

Zein da hobea - Oracle edo Redis edo Nola justifikatu plataformaren aukeraketa

Korporazio handietan kontrakoa gertatzen da normalean: kostuaren pisua ez da %50etik behera jaisten, eta agian %60tik gorakoa. Ereduaren adibidean, garrantzitsua dena da edozein nodo nagusiren seme-alaben pisu osoa % 100ekoa izan behar dela.

Mozketa baldintzak

Webgunea db-engines.com Datu-baseak kudeatzeko 500 sistema inguru ezagutzen dira. Jakina, helburu-plataforma bat aukeratzen baduzu hainbeste aukeretatik, baliteke berrikuspen-artikulu batekin bukatzea, baina ez proiektu komertziala. Aukera-espazioa murrizteko, mozketa-irizpideak formulatzen dira, eta plataformak irizpide horiek betetzen ez baditu, orduan ez da kontuan hartzen.

Mozte-irizpideak ezaugarri teknologikoekin zerikusia izan dezakete, adibidez:

  • ACID bermeak;
  • datu erlazionalaren eredua;
  • SQL hizkuntzaren euskarria (kontuan izan, hau ez da "erlazio-eredua" bezalakoa);
  • eskala horizontala egiteko aukera.

Irizpide orokorrak egon daitezke:

  • Errusian laguntza komertziala eskuragarri izatea;
  • kode irekia;
  • plataformaren erabilgarritasuna Telekomunikazio eta Masa Komunikazio Ministerioaren Erregistroan;
  • plataformaren presentzia balorazio batzuetan (adibidez, db-engines.com kalifikazioaren lehen ehunean);
  • merkatuan adituen presentzia (adibidez, hh.ru webguneko curriculumean plataformaren izena bilatzeko emaitzetan oinarrituta).

Azken finean, enpresaren irizpide espezifikoak egon daitezke:

  • langileen espezialisten eskuragarritasuna;
  • X monitorizazio sistemarekin edo Y babeskopia sistemarekin bateragarritasuna, zeinetan euskarri guztiak oinarritzen diren...

Garrantzitsuena mozteko irizpideen zerrenda bat dagoela da. Bestela, zalantzarik gabe, zuzendaritzarengandik konfiantza berezia duen adituren bat (edo "aditu") izango da, "zergatik ez duzu Z plataforma aukeratu, badakit onena dela".

Kostuen estimazioa

Konponbidearen kostua, jakina, lizentzien kostuak, laguntzaren kostuak eta ekipoen kostuak osatzen dute.

Sistemak gutxi gorabehera klase berekoak badira (adibidez, Microsoft SQL Server eta PostgreSQL), orduan, sinpletasunerako, bi soluzioetarako ekipamendu kopurua gutxi gorabehera berdina izango dela pentsa dezakegu. Horri esker, ekipamendua ez ebaluatzea ahalbidetuko duzu, eta horrela denbora eta esfortzu asko aurreztuko dira. Sistema guztiz desberdinak alderatu behar badituzu (esaterako, Oracle vs. Redis), bistakoa da ebaluazio zuzen bat egiteko beharrezkoa dela dimentsionatzea (ekipamendu kopuruaren kalkulua). Existitzen ez den sistema bat dimentsionatzea oso esker oneko zeregina da, beraz, oraindik ere saiatzen dira halako konparazioak saihesten. Erraza da hau egiteko: mozketa-baldintzetan, zero datu-galera eta erlazio-eredu bat idazten dira, edo alderantziz - 50 mila transakzio segundoko karga.

Lizentziak ebaluatzeko, nahikoa da saltzaileari edo bere bazkideei nukleo kopuru finko baterako lizentzia baten kostua eta epe finko baterako laguntza eskatzea. Oro har, enpresek harreman sendoak dituzte dagoeneko software saltzaileekin, eta datu-baseen eragiketen sailak ezin badu bere kabuz kostuen galderari erantzun, orduan gutun bat nahikoa da informazio hori lortzeko.

Saltzaile ezberdinek lizentzia-neurri desberdinak izan ditzakete: nukleo kopuruaren, datuen bolumenaren edo nodo kopuruaren arabera. Egonerako oinarria doakoa izan daiteke, edo lizentzia nagusia izan daitekeen modu berean. Neurrietan desberdintasunik aurkitzen bada, stand-eredua zehatz-mehatz deskribatu eta standaren lizentzien kostua kalkulatu beharko duzu.

Konparaketa zuzena egiteko puntu garrantzitsu bat laguntza-baldintza berdinak dira. Adibidez, Oracle-ren laguntzak lizentziaren prezioaren % 22 kostatzen du urtean, baina ez duzu PostgreSQL-ren laguntza ordaindu beharrik. Zuzena al da honela konparatzea? Ez, zure kabuz konpondu ezin den errore batek ondorio guztiz desberdinak dituelako: lehenengo kasuan, laguntza-espezialistek azkar lagunduko dizute konpontzen, baina bigarren kasuan, proiektua atzeratzeko edo amaitutakoaren geldialdi-denbora atzeratzeko arriskua dago. sistema epe mugagaberako.

Kalkulu-baldintzak hiru modutara berdindu ditzakezu:

  1. Erabili Oracle laguntzarik gabe (errealitatean ez da hori gertatzen).
  2. Erosi PostgreSQL-rako laguntza, adibidez, Postgres Professional-en.
  3. Kontuan hartu laguntza faltarekin lotutako arriskuak.

Esate baterako, arriskuen kalkulua honelakoa izan daiteke: datu-basearen hutsegite larri bat gertatuz gero, sistemaren geldialdia lanegun batekoa izango litzateke. Sistema erabiltzeagatik aurreikusitako irabazia 1 milioi MNTkoa da urtean, istripu-tasa 40/1koa dela kalkulatzen da, beraz, laguntza falta izateko arriskua gutxi gorabehera 400 milioi MNTkoa da urtean. Jakina, “planifikatutako irabazia” eta “estimatutako istripuen maiztasuna” balio birtualak dira, baina askoz hobe da horrelako eredu bat edukitzea ez edukitzea baino.

Egia esan, sistema oso garrantzitsua izan daiteke epe luzeko geldialdiaren ospe-kostua onartezina izateko, beraz, laguntza beharrezkoa izango da. Etenaldia onartzen bada, laguntza ukatzea batzuetan dirua aurrezteko modu ona izan daiteke.

Demagun kalkulu guztien ondoren, A plataforma eragilearen kostua 5 urtez 800 milioi MNT dela, B plataforma eragilearen kostua 650 milioi MNT dela eta C plataforma eragilearen kostua 600 milioi MNT dela. C plataformak, irabazle gisa, puntu osoa jasotzen du prezioagatik, A eta B plataformak, berriz, apur bat gutxiago, zenbat aldiz garestiago diren proportzioan. Kasu honetan – 0.75 eta 0.92 puntu, hurrenez hurren.

Aukeraren ebaluazioa

Aukeren ebaluazioa talde askotan banatzen da, eta horien kopurua ebaluazioa egiten duenaren irudimenak soilik mugatzen du. Aukera optimoa gaitasunak gaitasun horiek erabiliko dituzten taldeetan banatzea omen da; gure adibidean, hauek garatzaileak, administratzaileak eta informazioaren segurtasuneko arduradunak dira. Demagun funtzio horien pisuak 40:40:20 gisa banatuta daudela.

Garapen funtzioak hauek dira:

  • datuak manipulatzeko erraztasuna;
  • eskalatzea;
  • bigarren mailako indizeen presentzia.

Irizpideen zerrenda, baita haien pisuak ere, oso subjektiboak dira. Arazo bera konpontzen denean ere, zerrenda, elementuen pisuak eta erantzunak nabarmen aldatuko dira zure taldearen osaeraren arabera. Adibidez, Facebook-ek MySQL erabiltzen du datuak gordetzeko, eta Instagram Cassandraren gainean eraikita dago. Nekez bete izana aplikazio hauen garatzaileek taula horiek. Mark Zuckerbergek eredu erlazional oso bat aukeratu zuela asma daiteke, zatiketa aplikatuaren beharrarekin ordainduz, eta Kevin Systromek plataforma erabiliz eskalatzea eraiki zuen, datuetara sartzeko erraztasuna sakrifikatuz.

Administrazio funtzioak honako hauek dira:

  • babeskopia sistemaren gaitasunak;
  • jarraipena egiteko erraztasuna;
  • gaitasuna kudeatzeko erraztasuna - diskoak eta nodoak;
  • datuak erreplikatzeko gaitasunak.

Kontuan izan galderak modu kuantitatiboan idatzi behar direla. Funtzio jakin bat nola ebaluatu ere adostu dezakezu. Saia gaitezen, adibidez, babeskopia tresnak baloratzen Oracle DBMS-ekin hornitutako tresnen adibidea erabiliz:

Tool
Comment
Ebaluazio

imp/exp
Datuak kargatzea eta kargatzea
0.1

babeskopia hasi/amaitu
Fitxategiak kopiatzea
0.3

RMAN
Kopiatzeko gaitasuna gehigarria
0.7

ZDLRA
Kopiaketa inkrementala bakarrik, puntuko berreskuratze azkarrena
1.0

Ebaluazio-irizpide argirik ez badago, zentzuzkoa da hainbat adituri balorazioak emateko eskatzea eta, ondoren, batez bestekoa.

Azkenik, informazioaren segurtasun-funtzioak zerrendatuko ditugu:

  • pasahitzak kudeatzeko politiken erabilgarritasuna;
  • kanpoko autentifikazio tresnak (LDAP, Kerberos) konektatzeko gaitasuna;
  • sarbidearen eredua;
  • auditoretza gaitasunak;
  • diskoan datuak zifratzea;
  • enkriptatzea sarearen bidez transmititzean (TLS);
  • administratzailearengandik datuen babesa.

Errendimendu-probak

Bereiz, zuk egin ez dituzun karga-probaren emaitzak argudio gisa erabiltzeaz ohartarazi nahi dut.

Lehenik eta behin, probatzen ari diren aplikazioen datu-egitura eta karga-profila konpontzen ari zaren arazotik nabarmen desberdina izan daiteke. Duela 10-15 urte inguru, datu-baseen saltzaileek TPC probetan lortutako emaitzak erakustea gustatzen zitzaien, baina orain, dirudienez, inork ez ditu serio hartzen emaitza horiek.

Bigarrenik, sistemaren errendimenduaren araberakoa da jatorriz kodea zein plataformatarako idatzi zen eta proba zein ekipamenduren araberakoa da. Proba asko ikusi ditut Oracle PostgreSQL-ekin alderatzen zen. Emaitzak sistema baten baldintzarik gabeko nagusitasunetik beste baten baldintzarik gabeko nagusitasunera doaz.

Eta azkenik, hirugarrenik, ez dakizu ezer proba nork egin duen. Bi titulazioak garrantzitsuak dira, sistema eragilearen eta plataformaren konfigurazioaren kalitatean eragiten baitute, baita motibazioan ere, probaren emaitzetan beste faktore guztiek batuta baino gehiago eragiten baitute.

Errendimendua faktore kritikoa bada, egin proba zuk zeuk, ahal izanez gero, ekoizpen-sistema konfiguratu eta mantenduko duten pertsonen laguntzarekin.

Emaitza

Azkenik, egindako lan guztiaren emaitza kalkulu-orri bat izan behar da, non estimazio guztiak batu, biderkatu eta batu diren:

Zein da hobea - Oracle edo Redis edo Nola justifikatu plataformaren aukeraketa

Ulertzen duzunez, eskalak aldatuz eta balorazioak egokituz nahi duzun emaitza lor dezakezu, baina hori guztiz bestelakoa da...

Iturria: www.habr.com

Gehitu iruzkin berria