»To je nujno,« je rekla glasno in ni nikogar ogovorila. - To je potrebno! Prav to pravi: glavna naloga podjetja je ustvarjanje dobička v interesu delničarjev. No, pomisli! Ničesar se ne bojijo!
Yuliy Dubov, "Manjše zlo"
Ko ste videli takšen naslov, ste se verjetno že odločili, da je članek bodisi neumnost bodisi provokacija. Vendar ne hitite s sklepi: zaposleni v velikih korporacijah, zlasti v korporacijah z državno udeležbo, morajo pogosto primerjati različne platforme, vključno s popolnoma različnimi - na primer tistimi v naslovu.
Seveda DBMS nihče ne primerja na ta način, saj so njihove prednosti in slabosti dobro znane. Praviloma so predmet primerjave platforme, ki rešujejo nek aplikacijski problem. V prispevku bom prikazal metodologijo, ki je v tem primeru uporabljena, na primeru podatkovnih baz kot teme, ki jo bralci Habra poznajo iz prve roke. Torej,
Motivacija
Ko začnete z izobraževalnim projektom ali hobi projektom, je motivacija za izbiro platforme lahko zelo raznolika: »to je platforma, ki jo najbolje poznam«, »to me zanima razumeti«, »tukaj je najboljša dokumentacija« ... Pri gospodarski družbi je kriterij izbire enak: koliko bom moral plačati in kaj bom za ta denar dobil.
Seveda želite plačati manj in dobiti več. Vendar se morate odločiti, kaj je bolj pomembno - plačati manj ali dobiti več, in vsakemu vozlišču dodelite težo. Predpostavimo, da nam je kakovostnejša rešitev pomembnejša od poceni, in vozlišču »Cost« dodelimo utež 40%, vozlišču »Opportunities« pa 60%.
V velikih korporacijah je navadno ravno obratno – stroškovna utež ne pade pod 50 %, lahko pa tudi več kot 60 %. V primeru modela je pomembno le to, da mora biti skupna teža podrejenih vozlišč katerega koli nadrejenega vozlišča 100 %.
Pogoji rezanja
Spletna stran Znanih je približno 500 sistemov za upravljanje baz podatkov. Seveda, če med toliko možnostmi izberete ciljno platformo, lahko na koncu dobite pregledni članek, ne pa komercialnega projekta. Da bi zmanjšali izbirni prostor, so oblikovani mejni kriteriji in če platforma tem kriterijem ne ustreza, potem se ne upošteva.
Mejna merila se lahko nanašajo na tehnološke značilnosti, na primer:
- garancije ACID;
- relacijski podatkovni model;
- Podpora za jezik SQL (upoštevajte, da to ni isto kot "relacijski model");
- možnost horizontalnega skaliranja.
Obstajajo lahko splošna merila:
- razpoložljivost komercialne podpore v Rusiji;
- odprtokodno;
- dostopnost platforme v registru Ministrstva za telekomunikacije in množične komunikacije;
- prisotnost platforme v neki oceni (na primer v prvih sto ocenah db-engines.com);
- prisotnost strokovnjakov na trgu (na primer na podlagi rezultatov iskanja imena platforme v življenjepisu na spletnem mestu hh.ru).
Navsezadnje lahko obstajajo merila, specifična za podjetje:
- razpoložljivost strokovnjakov v osebju;
- združljivost z nadzornim sistemom X ali rezervnim sistemom Y, na katerem temelji vsa podpora...
Najpomembnejša stvar je, da obstaja seznam mejnih meril. V nasprotnem primeru se zagotovo najde kakšen strokovnjak (ali »strokovnjak«), ki uživa posebno zaupanje vodstva, ki bo rekel »zakaj nisi izbral platforme Z, vem, da je najboljša«.
Ocena stroškov
Strošek rešitve je seveda sestavljen iz stroškov licenc, stroškov podpore in stroškov opreme.
Če gre za sisteme približno istega razreda (na primer Microsoft SQL Server in PostgreSQL), lahko za poenostavitev domnevamo, da bo količina opreme za obe rešitvi približno enaka. To vam bo omogočilo, da ne boste ocenili opreme, s čimer boste prihranili veliko časa in truda. Če morate primerjati popolnoma različne sisteme (recimo Oracle vs. Redis), potem je očitno, da je za pravilno oceno potrebno narediti dimenzioniranje (izračun količine opreme). Dimenzioniranje neobstoječega sistema je zelo nehvaležno opravilo, zato se tovrstnim primerjavam vseeno poskušajo izogniti. To je enostavno narediti: v mejnih pogojih je zapisana ničelna izguba podatkov in relacijski model ali obratno - obremenitev 50 tisoč transakcij na sekundo.
Za ovrednotenje licenc je dovolj, da prodajalca ali njegove partnerje vprašate za stroške licence za določeno število jeder in podporo za določeno obdobje. Podjetja imajo praviloma že močne odnose s ponudniki programske opreme in če oddelek za upravljanje podatkovnih baz ne more sam odgovoriti na vprašanje o stroških, je za pridobitev tega podatka dovolj ena črka.
Različni prodajalci imajo lahko različne metrike licenciranja: glede na število jeder, količino podatkov ali število vozlišč. Pripravljena baza je lahko brezplačna ali pa je licencirana na enak način kot glavna. Če odkrijete kakršne koli razlike v meritvah, boste morali podrobno opisati stojalo modela in izračunati stroške licenc za stojalo.
Pomembna točka za pravilno primerjavo so enaki pogoji podpore. Na primer, podpora za Oracle stane 22 % cene licence na leto, ni pa vam treba plačati podpore za PostgreSQL. Je pravilna taka primerjava? Ne, saj ima napaka, ki je ne morete odpraviti sami, povsem drugačne posledice: v prvem primeru vam jo bodo strokovnjaki za podporo hitro pomagali odpraviti, v drugem primeru pa obstaja nevarnost zakasnitve projekta ali izpada dokončanega. sistem za nedoločen čas.
Pogoje izračuna lahko izenačite na tri načine:
- Uporabite Oracle brez podpore (v resnici se to ne zgodi).
- Kupite podporo za PostgreSQL - na primer pri Postgres Professional.
- Upoštevajte tveganja, povezana s pomanjkanjem podpore.
Na primer, izračun tveganja bi lahko izgledal takole: v primeru usodne okvare baze podatkov bi bil čas nedelovanja sistema 1 delovni dan. Predvideni dobiček od uporabe sistema je 40 milijard MNT na leto, stopnja nesreč je ocenjena na 1/400, tako da je tveganje pomanjkanja podpore ocenjeno na približno 100 milijonov MNT na leto. Očitno sta »načrtovani dobiček« in »ocenjena pogostost nesreč« virtualni vrednosti, vendar je veliko bolje imeti takšen model, kot pa ga nimati.
V resnici je sistem morda preveč pomemben, da bi bili stroški ugleda zaradi dolgotrajnih izpadov nesprejemljivi, zato bo potrebna podpora. Če so izpadi dovoljeni, je lahko zavrnitev podpore včasih dober način za prihranek denarja.
Predpostavimo, da se po vseh izračunih stroški delovanja platforme A za 5 let izkažejo za 800 milijonov MNT, stroški delovanja platforme B so 650 milijonov MNT, stroški delovanja platforme C pa 600 milijonov MNT. Platforma C kot zmagovalka prejme polno točko za ceno, platformi A in B pa nekaj manj, sorazmerno s tem, kolikokrat sta dražji. V tem primeru – 0.75 oziroma 0.92 točke.
Ocena priložnosti
Ocena priložnosti je razdeljena na številne skupine, katerih število je omejeno le z domišljijo ocenjevalca. Optimalna možnost se zdi razdelitev zmogljivosti na ekipe, ki bodo te zmogljivosti uporabljale; v našem primeru so to razvijalci, skrbniki in uradniki za informacijsko varnost. Predpostavimo, da so uteži teh funkcij porazdeljene kot 40:40:20.
Razvojne funkcije vključujejo:
- enostavnost obdelave podatkov;
- skaliranje;
- prisotnost sekundarnih indeksov.
Seznam kriterijev in njihove teže so zelo subjektivni. Tudi pri reševanju istega problema se bodo ti seznami, uteži postavk in odgovori močno razlikovali glede na sestavo vaše ekipe. Facebook na primer uporablja MySQL za shranjevanje podatkov, Instagram pa je zgrajen na Cassandri. Malo verjetno je, da so razvijalci teh aplikacij izpolnili takšne tabele. Lahko samo ugibamo, da je Mark Zuckerberg izbral polnopravni relacijski model in ga plačal s potrebo po uporabnem razčlenjevanju, medtem ko je Kevin Systrom zgradil skaliranje z uporabo platforme in žrtvoval enostaven dostop do podatkov.
Upravne funkcije vključujejo:
- zmogljivosti varnostnega sistema;
- enostavnost spremljanja;
- enostavnost upravljanja zmogljivosti - diski in vozlišča;
- zmožnosti replikacije podatkov.
Upoštevajte, da morajo biti vprašanja ubesedena na kvantitativni način. Lahko se celo dogovorite, kako ovrednotiti določeno funkcijo. Poskusimo na primer oceniti orodja za varnostno kopiranje na primeru orodij, ki so priložena Oracle DBMS:
Orodje
Komentar
Vrednotenje
imp/exp
Nalaganje in nalaganje podatkov
0.1
začetek/konec varnostnega kopiranja
Kopiranje datotek
0.3
RMAN
Možnost postopnega kopiranja
0.7
ZDLRA
Samo postopno kopiranje, najhitrejša obnovitev do točke
1.0
Če ni jasnih kriterijev ocenjevanja, je smiselno zaprositi več strokovnjakov za ocene in jih nato povprečiti.
Nazadnje preprosto naštejemo funkcije informacijske varnosti:
- razpoložljivost politik upravljanja gesel;
- možnost povezovanja zunanjih orodij za preverjanje pristnosti (LDAP, Kerberos);
- vzor dostopa;
- revizijske zmogljivosti;
- šifriranje podatkov na disku;
- šifriranje med prenosom po omrežju (TLS);
- varstvo podatkov pri skrbniku.
Testiranje delovanja
Ločeno bi rad posvaril pred uporabo rezultatov kakršnih koli testov obremenitve, ki jih niste naredili vi, kot argumentov.
Prvič, struktura podatkov in profil obremenitve aplikacij, ki se preskušajo, se lahko bistveno razlikujejo od težave, ki jo nameravate rešiti. Pred približno 10-15 leti so se prodajalci podatkovnih baz radi bahali z rezultati, doseženimi v testih TPC, zdaj pa se zdi, da teh rezultatov nihče ne jemlje resno.
Drugič, delovanje sistema je precej odvisno od platforme, za katero je bila koda prvotno napisana in od opreme, ki je bila izvedena. Videl sem veliko testov, kjer so Oracle primerjali s PostgreSQL. Rezultati segajo od brezpogojne superiornosti enega sistema do prav tako brezpogojne superiornosti drugega.
In končno, tretjič, ne veste ničesar o tem, kdo je naredil test. Pomembne so tako kvalifikacije, ki vplivajo na kakovost postavitve OS in platforme, kot tudi motivacija, ki vpliva na rezultate testiranja bolj kot vsi drugi dejavniki skupaj.
Če je zmogljivost kritičen dejavnik, izvedite test sami, po možnosti s pomočjo ljudi, ki bodo konfigurirali in vzdrževali proizvodni sistem.
Rezultat
Končno mora biti rezultat vsega opravljenega dela preglednica, v kateri so vse ocene združene, pomnožene in seštete:
Kot razumete, lahko s spreminjanjem lestvic in prilagajanjem ocen dosežete poljuben rezultat, vendar je to povsem druga zgodba ...
Vir: www.habr.com