– See, she said loudly without addressing anyone. – Can you believe it? It’s written right here – the main goal of society is to extract profit in the interests of shareholders. Just think about it! They fear nothing!
Juli Dubov, «The Lesser Evil»
Upon seeing such a headline, you've probably already decided that the article is either nonsense or a provocation. But don’t rush to conclusions: employees of large corporations, especially those with state participation, frequently have to compare different platforms, including quite distinct ones – for example, those mentioned in the headline.
Of course, no one compares DBMSs, as their strengths and weaknesses are well known. Usually, it’s platforms that address a specific task that are compared. In this article, I will show the methodology used for this, using databases as a subject familiar to the readers of Habr. So,
Motivatsioon
Kui alustate õppeprojekti või hobi projekti, võivad platvormi valimise motivatsioonid olla väga erinevad: "seda platvormi tunnen kõige paremini", "see tundub põnev", "siin on parim dokumentatsioon"... Äriettevõtte puhul on valikukriteerium üks: kui palju peab maksma ja mida selle eest saab.
Muidugi tahaks maksta vähem, kuid saada rohkem. Siiski tuleb otsustada, mis on olulisem – vähem maksta või rohkem saada ning igale põhimõttele omistada kaal. Oletame, et me hindame kvaliteetset lahendust rohkem kui odavat ning anname mõistele "Hind" kaalu 40% ning mõistele "Võimalused" 60%.
Suurtes ettevõtetes on tavaliselt kõik vastupidi – hinna kaal ei lange alla 50% ja võib ulatuda isegi 60% või enamgi. Mudel näitab, et kõigi vanemate sõlmede kogukaal peab olema 100%.
Lõike tingimused
Veebileht tuntud umbes 500 andmebaasi haldussüsteemi. Loomulikult, kui valida sihtplatvorm sellisest valikust, võib tulemusena olla ülevaatlik artikkel, mitte kommertstöö. Valiku piiramiseks formuleeritakse välistavad kriteeriumid, ja kui platvorm ei vasta nendele kriteeriumidele, siis ei vaatata seda.
Välistavad kriteeriumid võivad puudutada tehnoloogilisi omadusi, näiteks:
- ACID-garanteeringud;
- relatsiooniline andmemudel;
- SQL keele toetus (pange tähele, et see ei ole sama, mis "relatsiooniline mudel");
- horisontaalse skaleerituse võimalus.
Võivad olla ka üldise iseloomuga kriteeriumid:
- kaubanduslik toetus Venemaal;
- avatud lähtekood;
- platvormi olemasolu Kommunikatsiooniministeeriumi registris;
- platvormi olemasolu mingisuguses edetabelis (näiteks db-engines.com esimese saja hulgas);
- ekspertide olemasolu turul (näiteks platvormi nime otsingul CVs saidil hh.ru).
Lõpuks võivad olla ka ettevõtte spetsiifilised kriteeriumid:
- spetsialistide olemasolu töötajate seas;
- ühilduvus X järelevalvesüsteemiga või varundussüsteemiga Y, millele kogu teenindus toetub…
Peamine on, et oleks olemas välistavad kriteeriumid. Vastasel juhul leiab alati mõne eksperdi (või „eksperdi“), kellel on juhtkonna eriline usaldus, kes ütleb: „Miks te ei valinud platvormi Z? Ma tean, et see on parim.“
Hinna hindamine
Lahenduse maksumus koosneb ilmselgelt litsentside, teeninduse ja seadmete maksumusest.
Kui süsteemid on enam-vähem samas klassis (näiteks Microsoft SQL Server ja PostgreSQL), võib lihtsuse tõttu arvata, et seadmete arv mõlema lahenduse jaoks on ligikaudu sama. See saves aega ja vaeva seadmete hindamisel. Kui aga tuleb võrrelda täiesti erinevaid süsteeme (näiteks Oracle vs. Redis), siis on ilmne, et korrektse hindamise jaoks on vajalik teha mahutavushinnang (seadmete arvu arvutamine). Mitteeksisteeriva süsteemi mahutavushinnang on väga tänamatu ülesanne, seega püüavad selliseid võrdlusi vältida. Seda on lihtne teha: piirangutingimustes märgitakse nullandmete kaotus ja relaatsioonimudel või vastupidi – koormus 50 000 tehingut sekundis.
Litsentside hindamiseks piisab, kui küsida müüjalt või tema partneritelt litsentsi hinda kindla arvu tuumade ja fikseeritud ajaga toetuse kohta. Üldiselt on ettevõtetel juba tugevad suhted tarkvara müüjatega ning kui andmebaasi halduskeskus ei saa iseseisvalt hinnaküsimusele vastata, siis piisab selle teabe saamiseks ühest e-kirjast.
Erinevatel müüjatel võivad olla erinevad litsentsimise mõõdikud: tuumade arvu, andmemahtu või sõlmede arvu järgi. Standby-andmebaas võib olla tasuta või litsentseerida nagu põhiversioon. Kui ilmnevad erinevused mõõdikutes, tuleb mudelistendi üksikasjalikult kirjeldada ja arvutada litsentside maksumus stendi jaoks.
Oluline punkt korrektseks võrdlemiseks on samad toetuse tingimused. Näiteks, Oracle'i tugi maksab 22% litsentsihinnast aastas, samas kui PostgreSQL toetuse eest ei pea maksma. Kas on korrektne nii võrrelda? Ei, sest veal, mida ei saa oma jõududega lahendada, on täiesti erinevad tagajärjed: esimeses juhus toetuse spetsialistid aitavad selle kiiresti lahendada, samas kui teisel juhul on oht projekti viivituseks või valmis süsteemi seiskamiseks määramatuks ajaks.
Toetuse arvestamise tingimusi saab võrdsustada kolmel viisil:
- Kasutada Oracle'it ilma toeta (reaalsuses midagi sellist ei juhtu).
- Osta PostgreSQL jaoks tugi - näiteks ettevõttelt Postgres Professional.
- Arvesse võtta riske, mis on seotud toe puudumisega.
Näiteks võivad riskide arvutused välja näha sellised: kui andmebaasi süsteem tõrgeb, kulub selle taastamiseks 1 tööpäev. Süsteemi kasutamisest plaanitud kasum on 40 miljardit Mongoolia tugrikut aastas, õnnetuste esinemissagedus on hinnanguliselt 1/400, seega on hoolduse puudumise risk umbes 100 miljonit Mongoolia tugrikut aastas. On selge, et "plaanitud kasum" ja "hindatud õnnetuste esinemissagedus" on virtuaalsed väärtused, kuid parem on omada sellist mudelit kui mitte mingit.
Tegelikult võib süsteem olla liiga oluline ning mainekaotused pikaajalise seismise korral oleksid vastuvõetamatud, seega on tugi vajalik. Kui aga seiskamine on lubatud, võib mõnikord toetuse katkestamine olla hea viis kulude kokkuhoiuks.
Oletame, et pärast kõiki arvutusi on platvormi A kasutuskulud 5 aastaks kokku 800 miljonit Mongoolia tugrikit, platvormi B kasutuskulud 650 miljonit tugrikit ja platvormi C kasutuskulud 600 miljonit tugrikit. Platvorm C võidab ning teenib täispunkti, samas kui platvormid A ja B saavad veidi vähem, proportsionaalselt sellele, kui palju nad kallimad on. Antud juhul – 0.75 ja 0.92 punkti vastavalt.
Võimaluste hindamine
Võimaluste hindamine jaguneb paljudeks gruppideks, mille arv on piiratud ainult selle inimese kujutlusvõimega, kes hindamist läbi viib. Optimaalse lahendusena tundub selle jagamine tiimide kaupa, kes neid võimalusi kasutavad; meie näites on see arendajad, administraatorid ja infosüsteemide ametnikud. Oletame, et nende funktsioonide kaalud jagunevad järgnevalt: 40:40:20.
Arendamise funktsioonide alla kuuluvad:
- andmete töötlemise mugavus;
- skaalautuvus;
- teisejärguliste indeksite olemasolu.
Kriteeriumide nimekiri ja nende kaalud on väga subjektiivsed. Isegi sama ülesande lahendamisel võivad need nimekirjad, punktide kaalud ja vastused märgatavalt erineda sõltuvalt teie meeskonna koosseisust. Näiteks kasutab Facebook andmete salvestamiseks MySQL-i, samas kui Instagram põhineb Cassandra-l. On kaheldav, et nende rakenduste arendajad oleksid selliseid tabeleid täitnud. Saame vaid oletada, et Mark Zuckerberg valis täieliku relatsioonilise mudeli, makstes selle eest rakenduste sharding’u vajadusega, samas kui Kevin Systrom kavandas skaleerimise platvormi vahenditega, ohverdades andmete ligipääsetavuse.
Haldusfunktsioonide hulka kuuluvad:
- varundamise süsteemi võimalused;
- jälgimise mugavus;
- võimsuste – ketaste ja sõlmede – haldamise mugavus;
- andmete replikatsiooni võimalused.
Pange tähele, et küsimuste sõnastused peavad võimaldama kvantitatiivset hindamist. Saame isegi kokku leppida, kuidas teatud funktsioone hinnata. Proovime näiteks hinnata varundamise tööriistu Oracle DB-ga kaasasolevate tööriistade näitel:
Tööriista
Kommentaar
Hinne
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 inkrementaalne kopeerimine, kiireim taastamine punktis
1.0
Kui selged hindamiskriteeriumid puuduvad, on mõttekas küsida mitmelt ekspertidelt hinnangut ja seejärel need keskmistada.
Lõpuks loetleme lihtsalt infosüsteemide turvafunktsioonid:
- paroolihalduse poliitikate olemasolu;
- välist autentimisvahendite (LDAP, Kerberos) ühendamise võimalus;
- rollipõhine ligipääsude mudel;
- auditivõimalused;
- andmete krüpteerimine kettal;
- krüpteerimine andmete edastamisel võrgus (TLS);
- andmete kaitse administraatori eest.
Jõudluse testimine
Eraldi sooviksin hoiatada, et ärge kasutage mitte teie enda tehtud koormustestide tulemusi argumentidena.
Esiteks, katsetatavate rakenduste andmestruktuur ja koormusprofiil võivad oluliselt erineda ülesandest, mille te kavatsete lahendada. 10-15 aastat tagasi meeldis andmebaasitootjatele uhkeldada TPC-testide käigus saavutatud tulemustega, kuid nüüdseks tundub, et keegi ei võta neid tulemusi enam tõsiselt.
Teiseks, süsteemi jõudlus sõltub märkimisväärselt sellest, millisele platvormile kood algselt kirjutatud on ja millisel riistvaral katsetati. Olen näinud mitmeid teste, kus Oracle'it võrreldakse PostgreSQL-iga. Tulemused ulatuvad ühe süsteemi ühemõttelisest ülevusest teise süsteemi sama ühemõttelisest ülevusest.
Ja lõpuks, kolmandaks, te ei tea midagi sellest, kes katse läbi viis. Oluline on nii spetsialiseerumine, mis mõjutab operatsioonisüsteemi ja platvormi seadistamise kvaliteeti, kui ka motivatsioon, mis mõjutab katsete tulemusi rohkem kui kõik teised tegurid kokku.
Kui jõudlus on kriitiliselt oluline, tehke test ise, eelistatavalt spetsialistide osalusel, kes seadistavad ja hooldavad tööstuslikku süsteemi.
Tulemus
Lõpuks peaks kogu tehtud töö tulemuseks olema elektrooniline tabel, kus kõik hinnangud on kokku toodud, korrutatud ja liidetud:
Nagu te mõistate, saab kaalude muutmise ja hinnangute kohandamisega saavutada mistahes soovitud tulemuse, kuid see on juba hoopis teine lugu…
Allikas: habr.com
