Mis on parem – Oracle või Redis või Kuidas põhjendada platvormi valikut

– Pead näe, – ütles ta valjult, ei kõnelenud kellelegi. – Pead näe! Jutust on nii selgelt kirjas, et ühiskonna peamine ülesanne on kasumi teenimine aktsionäride huvides. Kas te ei mõtle sellele? Mitte midagi ei kardeta!

Juli Dublov, „Vähem rassistlik halb“

Kui te sellist pealkirja näete, olete tõenäoliselt juba otsustanud, et artikkel on kas rumalus või provokatsioon. Kuid ärge tehke järeldusi liiga kiiresti: suurte korporatsioonide, eriti riigiosalusega korporatsioonide töötajad peavad üsna tihti erinevaid platvorme võrdlema, sealhulgas täiesti erinevaid – näiteks need, mis on pealkirjas.

Loomulikult ei võrrelda keegi andmebaase, sest nende tugevused ja nõrkused on hästi teada. Reeglina võrreldakse platvorme, mis lahendavad teatud rakenduslikku ülesannet. Artiklis näitan meetodit, mida selleks kasutatakse, andmebaaside näitel, mida lugenud Khabra lugejad tunnevad. Nii et,

Motivatsioon

Kui alustate õppeprojekti või hobiprojekti, võib platvormi valiku motiveerimine olla väga mitmekesine: „seda platvormi tunnen ma kõige paremini“, „selle üle on huvitav aru saada“, „siin on parim dokumentatsioon“... Kaubandusliku ettevõtte korral on valikukriteerium üks: kui palju tuleb maksta ja mida ma selle raha eest saan.

Muidugi soovite maksta vähem ja saada rohkem. Siiski on oluline otsustada, mis on olulisem – vähem maksta või rohkem saada, ja iga sõlme määrata kaal. Oletame, et meile on olulisem kvaliteetne lahendus kui odav, seega anname sõlmele „Hind“ kaalu 40% ja sõlmele „Võimalused“ 60%.

Suurtes korporatsioonides on tavaliselt vastupidi – hinna kaal ei lange kunagi alla 50% ja võib-olla isegi üle 60%. Mudel näiteks näitab, et iga vanema sõlme summaalne kaal peab olema 100%.

Välistavad tingimused

Veebileht db-engines.com on teada umbes 500 andmebaaside haldust süsteemi. Loomulikult, kui valida sihtplatvorm nii suure koguse variantide hulgast, võib sellest saada ülevaate artikkel, kuid mitte kaubanduslik projekt. Valiku ruumi piiramise jaoks formuleeritakse välistavad kriteeriumid ja kui platvorm ei vasta nendele kriteeriumitele, siis seda ei arvestata.

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

• ACID-garantii;
• relatsiooniline andmemudel;
• SQL keele toetus (pange tähele, et see ei ole sama, mis 'relatsiooniline mudel');
• horisontaalne skaleeritavus.

Võivad olla ka üldised kriteeriumid:

• kaubandusliku toe olemasolu Eestis;
• avatud lähtekood;
• platvormi olemasolu Ministeeriumi Raamatus;
• platvormi olemasolu mingis järjestuses (näiteks esimese saja hulgas db-engines.com järjestuses);
• ekspertide olemasolu turul (näiteks platvormi nime otsingust tulevate CV-de põhjal veebisaidil hh.ru).

Lõppkokkuvõttes võivad olla ettevõttespetsiifilised kriteeriumid:

• spetsialistide olemasolu meeskonnas;
• kooskõla seire süsteemiga X või varundussüsteemiga Y, millele kõik tugi toetub…

Kõige olulisem on, et välistavate kriteeriumide nimekiri oleks olemas. Vastasel korral leiab alati mõni ekspert (või 'ekspert'), kellel on juhtkonna seas eriline usaldus, kes ütleb: 'Miks te ei valinud platvormi Z, ma tean, et see on parim'.

Maksuhinnang

Lahenduse maksumus koosneb ilmselt litsentside, toe ja seadmete maksumusest.

Kui süsteemid on enam-vähem samas klassis (näiteks Microsoft SQL Server ja PostgreSQL), võib lihtsuse huvides arvata, et seadmete arv mõlemas lahenduses on enam-vähem sama. See säästab aega ja vaeva seadmete hindamisel. Kui aga tuleb võrrelda täiesti erinevaid süsteeme (ütleme, Oracle vs. Redis), on selge, et korrektseks hindamiseks on vajalik suuruse määramine (seadmete arvu arvutamine). Mitteeksisteeriva süsteemi suuruse määramine on tänamatult keeruline ülesanne, mistõttu selliseid võrreldes püüavad ikkagi vältida. Seda on lihtne teha: välistavates tingimustes kirjutatakse nullandmete kaotus ja relatsiooniline mudel või vastupidi – koormus 50 tuhat tehingut sekundis.

Litsentide hindamiseks piisab, kui küsida teenusepakkujalt või tema partneritelt litsentsi hinda fikseeritud arvu südamike ja fikseeritud perioodi toetuse eest. Üldiselt on ettevõtetel juba tugevad suhted tarkvarateenuse pakkujatega, ja kui andmebaasi halduskeskus ei saa ise hinda öelda, siis piisab, kui saata üks kiri, et saada vajalik teave.

Erinevatel teenusepakkujatel võivad olla erinevad litsentseerimise mõõdikud: südamike arvu, andmemahtude või sõlmede arvu järgi. Standby-andmebaas võib olla tasuta või litsentseeritud sama kui põhiversioon. Kui selguvad erinevused mõõdikutes, tuleb mudelstandi detailne kirjeldamine ning litsentside hindade arvutamine.

Oluline aspekt õigeks võrdlemiseks on samad tugitingimused. Ütleme, et Oracle'i tugi maksab aastas 22% litsentsihinnast, kuid PostgreSQL-i toe eest ei pea maksma. Kas on korrektne nii võrrelda? Ei, kuna veateate tagajärjed, mida ei saa iseseisvalt lahendada, on täiesti erinevad: esimeses olukorras aitavad toe spetsialistid probleemi kiiresti lahendada, teises olukorras on oht projekti viivitamiseks või valmis süsteemi seiskamiseks määramatuks ajaks.

Hindamise tingimusi on võimalik ühtlustada kolme viisi:

1. Kasutada Oracle'i ilma toetusteta (reaalsuses ei juhtu seda).
2. Osta PostgreSQL-i toetus – näiteks ettevõttelt Postgres Professional.
3. Arvestada riske, mis on seotud toe puudumisega.

Näiteks võivad riskide arvutused välja näha nii: kui andmebaasi tõrge pole lahendatav, siis seisak aega koos süsteemiga kestab 1 tööpäeva. Planeeritud kasum süsteemi kasutamisest on 40 miljardit Mongoolia tugrikut aastas, avarii sagedus on hinnatud 1/400, seega on toetuse puudumisega seotud risk hinnanguliselt umbes 100 miljonit Mongoolia tugrikut aastas. Ilmselgelt on "planeeritud kasum" ja "hindeline avariide sagedus" virtuaalsed suurused, kuid palju parem on selline mudel kui selle puudumine.

Tegelikult võib süsteem olla liiga oluline ja pikaajalise seiskumise mainekaotused võivad olla vastuvõetamatud, seega on tugi vajalik. Kui siiski seiskumine on lubatud, võib toe loobumine mõnikord olla hea viis raha säästa.

Oletame, et kõikide arvutuste järel on platvormi A ekspluatatsioonikulu 5 aasta jooksul 800 miljonit Mongoolia tugrikut, platvormi B 650 miljonit tugrikut ja platvormi C 600 miljonit tugrikut. Platvorm C võitjana teenib täispunkti kulutuste põhjal, ning platvormid A ja B saavad veidi vähem, proportsionaalselt nende hindadega. Antud juhul on need vastavalt 0.75 ja 0.92 punkti.

Võimaluste hindamine

Võimaluste hindamine jaguneb mitmeks gruppideks, mille arvu piiravad vaid hindaja fantaasia. Optimaalseks variandiks tundub võimaluste jaotamine tiimide järgi, kes neid võimalusi kasutavad; meie näites oleksid need arendajad, administraatorid ja infotehnoloogia ametnikud. Oletame, et nende funktsioonide kaalu jaotatakse nagu 40:40:20.

Arendamise funktsioonideks võivad olla:

• andmete manipuleerimise mugavus;
• skaalautuvus;
• teisejärguliste indeksite olemasolu.

Kriteeriumide nimekiri, nagu ka nende kaalud, on väga subjektiivne. Isegi sama ülesande lahendamisel võivad need nimekirjad, punktide kaalud ja vastused oluliselt erineda sõltuvalt teie meeskonna koosseisust. Näiteks kasutab Facebook andmete salvestamiseks MySQL-i, samas kui Instagram põhineb Cassandra-l. Tõenäoliselt ei ole nende rakenduste arendajad selliseid tabeleid täitnud. Võib vaid oletada, et Mark Zuckerberg valis täieliku relaatsiooni mudeli, makstes selle eest rakenduste shardimise vajadusega, samas kui Kevin Systrom pani skaleeritavuse platvormi vahenditega, ohverdades andmete mugava ligipääsu.

Haldusfunktsioonide hulka kuuluvad:

• varundamise süsteemi võimalused;
• monitoorimise mugavus;
• võimekuse – ketaste ja sõlmede – haldamise mugavus;
• andmete replikatsiooni võimalused.

Pöörake tähelepanu, et küsitavate küsimuste sõnastus peaks võimaldama kvantitatiivset hindamist. Võime isegi kokku leppida, kuidas hinnata mõnda funktsiooni. Proovime näiteks hinnata varundustööriistu, kasutades Oracle'i andmebaasi jaoks tarnitud tööriistu:

Tööriist
Kommentaar
Hindamine

imp/exp
Andmete eksport ja import
0.1

varundamise algus/lõpp
Failide kopeerimine
0.3

RMAN
Inkrementaalse kopeerimise võimalus
0.7

ZDLRA
Ainult inkrementeeriv kopeerimine, kiireim taastumine punktist
1.0

Kui selged hindamiskriteeriumid puuduvad, on mõttekas paluda mitmeid spetsialiste hinda anda ja seejärel keskmistada.

Lõpuks toome lihtsalt välja infotehnoloogia turvafunktsioonid:

• paroolide haldamise poliitikate olemasolu;
• võimalus ühendada väliseid autentimistööriistu (LDAP, Kerberos);
• juurdepääsu rollimudel;
• auditeerimisvõimalused;
• andmete krüpteerimine kettal;
• andmete krüpteerimine edastamisel üle võrgu (TLS);
• andmete kaitse administraatori eest.

Tootlikkuse testimine

Tahaksin eraldi hoiatada, et ärge kasutage mingite koormustestide tulemusi, mida te ise ei juhtinud, argumendina.

Esiteks võivad testitavate rakenduste andmestructuur ja koormusprofiil oluliselt erineda probleemist, mida te kavatsete lahendada. 10-15 aastat tagasi meeldis andmebaasi tootjatele uhkeldada TPC-testide tulemustega, kuid praegu ei näi keegi neid tulemusi tõsiselt võtvat.

Teiseks sõltub süsteemi jõudlus oluliselt sellest, millise platvormi jaoks on kood algselt kirjutatud ja millisel seadmel test viidi läbi. Olen näinud arvukalt teste, kus Oracle’i võrreldakse PostgreSQL-iga. Tulemused ulatuvad ühe süsteemi selgesse üleolekusse samasuguse selguseni teise üle.

Ja lõpuks, kolmandaks, te ei tea midagi selle kohta, kes testi tegi. Oluline on nii kvalifikatsioon, mis mõjutab operatsioonisüsteemi ja platvormi seadistamise kvaliteeti, kui ka motivatsioon, mis mõjutab testi tulemusi enam kui kõik teised tegurid kokku.

Kui jõudlus on kriitilise tähtsusega tegur, siis testige ise, eelistatavalt koos spetsialistidega, kes seadistavad ja hooldavad tööstussüsteemi.

Tulemus

Lõpuks peab kogu selle töö tulemus olema arvutustabel, kus kõik hinded on kokku kogutud, korrutatud ja summeeritud:

Kuidas te aru saate, saab kaalude muutmise ja hindade korrigeerimisega saavutada igasuguseid soovitud tulemusi, kuid see on juba hoopis teine lugu...

Allikas: habr.com