Kumb on parem – Oracle või Redis või Kuidas platvormivalikut põhjendada

"See on vajalik," ütles ta valjult, pöördumata kellegi poole. - See on vajalik! Täpselt nii on kirjas: ettevõtte põhiülesanne on aktsionäride huvides kasumi teenimine. No mõelge sellele! Nad ei karda midagi!

Yuliy Dubov, "Vähem kurjus"

Sellist pealkirja nähes oled ilmselt juba otsustanud, et artikkel on kas rumalus või provokatsioon. Kuid ärge kiirustage järeldustega: suurettevõtete, eriti riigi osalusega ettevõtete töötajad peavad üsna sageli võrdlema erinevaid platvorme, sealhulgas täiesti erinevaid - näiteks pealkirjas olevaid.

Loomulikult ei võrdle keegi DBMS-e sel viisil, sest nende tugevad ja nõrgad küljed on hästi teada. Reeglina tuleb võrrelda platvorme, mis lahendavad mõne rakenduse probleemi. Artiklis näitan antud juhul kasutatavat metoodikat andmebaaside kui Habri lugejatele tuttava teema näitel. Niisiis,

Motivatsioon

Haridusprojekti või hobiprojektiga alustamisel võib platvormi valimise motivatsioon olla väga mitmekesine: “see on platvorm, mida ma kõige paremini tunnen”, “Olen huvitatud sellest aru saama”, “siin on parim dokumentatsioon” ... Kaubandusettevõtte puhul on valikukriteerium sama: kui palju ma pean maksma ja mida ma selle raha eest saan.

Loomulikult soovite maksta vähem ja saada rohkem. Siiski peate otsustama, mis on olulisem – maksta vähem või saada rohkem, ja määrata igale sõlmele kaal. Oletame, et kvaliteetne lahendus on meie jaoks odavast olulisem ja sõlmele “Kulu” omistame kaaluks 40% ja sõlmele “Võimalused” 60%.

Suurkorporatsioonides on tavaliselt vastupidi – kulukaal ei lange alla 50% ja võib-olla ka üle 60%. Mudeli näites on oluline vaid see, et mis tahes vanemsõlme alamsõlmede kogukaal peab olema 100%.

Katkestustingimused

Veebisait db-engines.com Teada on umbes 500 andmebaasihaldussüsteemi. Kui valite sihtplatvormi nii paljude valikute hulgast, võite loomulikult jõuda ülevaateartiklini, kuid mitte kommertsprojektini. Valikuruumi vähendamiseks sõnastatakse lõikekriteeriumid ja kui platvorm nendele kriteeriumidele ei vasta, siis seda ei arvestata.

Piirkriteeriumid võivad olla seotud tehnoloogiliste omadustega, näiteks:

• ACID garantiid;
• relatsiooniline andmemudel;
• SQL keele tugi (pange tähele, see ei ole sama mis "relatsioonimudel");
• horisontaalse skaleerimise võimalus.

Võib olla üldised kriteeriumid:

• kaubandusliku toe kättesaadavus Venemaal;
• avatud lähtekoodiga;
• platvormi kättesaadavus Telekomi- ja Massikommunikatsiooniministeeriumi registris;
• platvormi olemasolu mõnes reitingus (näiteks db-engines.com reitingu esimeses sajas);
• ekspertide olemasolu turul (näiteks veebisaidi hh.ru CV-st platvormi nime otsimise tulemuste põhjal).

Lõppude lõpuks võivad olla ettevõttepõhised kriteeriumid:

• spetsialistide olemasolu personalis;
• ühilduvus jälgimissüsteemiga X või varusüsteemiga Y, millel kogu tugi põhineb...

Kõige tähtsam on see, et on olemas piirkriteeriumide loend. Vastasel juhul leidub kindlasti mõni ekspert (või "ekspert"), kes naudib juhtkonna erilist usaldust ja kes ütleb: "Miks te ei valinud platvormi Z, ma tean, et see on parim."

Kulude prognoos

Lahenduse maksumus koosneb ilmselgelt litsentside maksumusest, toe maksumusest ja seadmete maksumusest.

Kui süsteemid on ligikaudu samast klassist (näiteks Microsoft SQL Server ja PostgreSQL), siis lihtsuse mõttes võib eeldada, et mõlema lahenduse seadmete hulk on ligikaudu sama. See võimaldab teil seadmeid mitte hinnata, säästes sellega palju aega ja vaeva. Kui peab võrdlema täiesti erinevaid süsteeme (ütleme Oracle vs Redis), siis on ilmselge, et õigeks hindamiseks on vaja teha suuruse määramine (seadmete hulga arvutamine). Olematu süsteemi suuruse määramine on väga tänamatu töö, mistõttu püütakse selliseid võrdlusi siiski vältida. Seda on lihtne teha: katkestustingimustes kirjutatakse null andmekadu ja relatsioonimudel või vastupidi - koormus 50 tuhat tehingut sekundis.

Litsentside hindamiseks piisab, kui küsida müüjalt või tema partneritelt litsentsi maksumust kindla arvu tuumade ja kindla perioodi tugiteenuste eest. Reeglina on ettevõtetel juba praegu tugevad suhted tarkvaramüüjatega ja kui andmebaasi haldamise osakond ei suuda ise kuluküsimusele vastata, siis piisab selle info saamiseks ühest kirjast.

Erinevatel tarnijatel võivad olla erinevad litsentsimismõõdikud: tuumade arvu, andmemahu või sõlmede arvu järgi. Ootebaas võib olla tasuta või litsentsitud samamoodi nagu põhibaas. Kui mõõdikutes avastatakse erinevusi, peate näidisstendi üksikasjalikult kirjeldama ja arvutama stendi litsentside maksumuse.

Õige võrdluse oluline punkt on samad tugitingimused. Näiteks Oracle'i tugi maksab 22% litsentsihinnast aastas, kuid te ei pea PostgreSQL-i toe eest maksma. Kas niimoodi võrrelda on õige? Ei, sest veal, mida ei saa ise parandada, on hoopis teistsugused tagajärjed: esimesel juhul aitavad tugispetsialistid selle kiiresti parandada, teisel juhul aga on oht projektiga viivitada või valminud töö seisak. süsteemi määramata ajaks.

Arvutustingimusi saate võrdsustada kolmel viisil:

1. Kasutage Oracle'i ilma toetuseta (tegelikkuses seda ei juhtu).
2. Ostke PostgreSQL-i tugi – näiteks Postgres Professionalilt.
3. Võtke arvesse toetuse puudumisega seotud riske.

Näiteks võib riskiarvutus välja näha selline: fataalse andmebaasi tõrke korral on süsteemi seisak 1 tööpäev. Prognoositav kasum süsteemi kasutamisest on 40 miljardit MNT aastas, õnnetusjuhtumite määr on hinnanguliselt 1/400, seega on toetuse puudumise riskiks hinnanguliselt ligikaudu 100 miljonit MNT aastas. Ilmselgelt on "planeeritud kasum" ja "õnnetuste hinnanguline sagedus" virtuaalsed väärtused, kuid palju parem on selline mudel omada, kui mitte.

Tegelikkuses võib süsteem olla liiga oluline, et pikaajalise seisaku maine maksumus oleks vastuvõetamatu, mistõttu on vaja tuge. Kui seisakuid on lubatud, võib toest keeldumine mõnikord olla hea viis raha säästa.

Oletame, et pärast kõiki arvutusi kujuneb platvormi A maksumuseks 5 aastaks 800 miljonit MNT, operatsiooniplatvormi B maksumuseks 650 miljonit MNT ja operatsiooniplatvormi C maksumuseks 600 miljonit MNT. Platvorm C saab võitjana hinna eest täispunkti, platvormid A ja B saavad aga veidi vähem, proportsionaalselt sellega, mitu korda nad on kallimad. Sel juhul – vastavalt 0.75 ja 0.92 punkti.

Võimaluste hindamine

Võimaluste hindamine jaguneb paljudesse rühmadesse, mille arvu piirab vaid hinnangu andja kujutlusvõime. Optimaalne variant näib olevat võimete jagamine meeskondadeks, kes neid võimalusi kasutama hakkavad; meie näites on need arendajad, administraatorid ja infoturbeametnikud. Oletame, et nende funktsioonide kaalud jagunevad 40:40:20.

Arendusfunktsioonid hõlmavad järgmist:

• andmetega manipuleerimise lihtsus;
• skaleerimine;
• sekundaarsete indeksite olemasolu.

Kriteeriumide loetelu ja ka nende kaalud on väga subjektiivsed. Isegi sama probleemi lahendamisel varieeruvad need loendid, üksuste kaalud ja vastused oluliselt sõltuvalt teie meeskonna koosseisust. Näiteks Facebook kasutab andmete salvestamiseks MySQL-i ja Instagram on üles ehitatud Cassandrale. On ebatõenäoline, et nende rakenduste arendajad selliseid tabeleid täitsid. Võib vaid oletada, et Mark Zuckerberg valis täieõigusliku relatsioonimudeli, makstes selle eest rakendusliku killustamise vajadusega, samas kui Kevin Systrom ehitas skaleerimise platvormi abil, ohverdades andmetele juurdepääsu lihtsuse.

Haldusfunktsioonide hulka kuuluvad:

• varusüsteemi võimalused;
• jälgimise lihtsus;
• mahuhalduse lihtsus - kettad ja sõlmed;
• andmete replikatsiooni võimalused.

Pange tähele, et küsimused tuleb sõnastada kvantitatiivselt. Võite isegi kokku leppida, kuidas konkreetset funktsiooni hinnata. Proovime näiteks hinnata varundustööriistu, kasutades Oracle DBMS-iga kaasas olevate tööriistade näidet:

Vahend
Kommentaar
Hindamine

imp/exp
Andmete üles- ja laadimine
0.1

varundamise algus/lõpetamine
Failide kopeerimine
0.3

RMAN
Täiendava kopeerimise võimalus
0.7

ZDLRA
Ainult järkjärguline kopeerimine, kiireim taastamine punktini
1.0

Kui puuduvad selged hindamiskriteeriumid, on mõttekas paluda hinnanguid anda mitmel eksperdil ja seejärel nende keskmine arvutada.

Lõpuks loetleme lihtsalt teabeturbe funktsioonid:

• paroolihalduspoliitikate kättesaadavus;
• võimalus ühendada väliseid autentimistööriistu (LDAP, Kerberos);
• juurdepääsu eeskuju;
• auditeerimisvõimalused;
• kettal olevate andmete krüpteerimine;
• krüpteerimine võrgu kaudu edastamise ajal (TLS);
• andmekaitse haldurilt.

Jõudluskontroll

Eraldi tahaksin hoiatada, et ei kasuta argumentidena koormustestide tulemusi, mis pole teie poolt tehtud.

Esiteks võivad testitavate rakenduste andmestruktuur ja koormusprofiil oluliselt erineda probleemist, mida kavatsete lahendada. Umbes 10-15 aastat tagasi armastasid andmebaasimüüjad TPC testides saavutatud tulemustega uhkeldada, kuid nüüd tundub, et keegi ei võta neid tulemusi tõsiselt.

Teiseks sõltub süsteemi jõudlus üsna tugevalt sellest, millisele platvormile kood algselt kirjutati ja mis seadmetest testiti. Olen näinud palju teste, kus Oracle'i võrreldi PostgreSQL-iga. Tulemused ulatuvad ühe süsteemi tingimusteta paremusest teise samavõrra tingimusteta paremuseni.

Ja lõpuks, kolmandaks, sa ei tea midagi sellest, kes testi tegi. Mõlemad kvalifikatsioonid on olulised, mõjutades nii OS-i ja platvormi seadistamise kvaliteeti kui ka motivatsiooni, mis mõjutab testi tulemusi rohkem kui kõik muud tegurid kokku.

Kui jõudlus on kriitiline tegur, viige test läbi ise, eelistatavalt tootmissüsteemi konfigureerivate ja hooldavate inimeste abiga.

Tulemus

Lõpuks peaks kogu tehtud töö tulemuseks olema arvutustabel, kus kõik hinnangud on ühendatud, korrutatud ja summeeritud:

Nagu te mõistate, saate skaalasid muutes ja reitinguid kohandades saavutada mis tahes soovitud tulemuse, kuid see on täiesti teine ​​​​lugu...

Allikas: www.habr.com