„Tai būtina“, – garsiai pasakė ji, į nieką nesikreipdama. - Tai būtina! Kaip tik taip ir sakoma: pagrindinė įmonės užduotis – akcininkų labui gauti pelną. Na, pagalvok apie tai! Jie nieko nebijo!
Julijus Dubovas, „Mažesnis blogis“
Pamatę tokią antraštę tikriausiai jau nusprendėte, kad straipsnis yra arba kvailystė, arba provokacija. Tačiau neskubėkite daryti išvadų: didelių korporacijų, ypač korporacijų, kuriose dalyvauja valstybė, darbuotojams gana dažnai tenka lyginti skirtingas platformas, įskaitant visiškai skirtingas – pavyzdžiui, pavadinime.
Žinoma, DBVS taip niekas nelygina, nes jų stipriosios ir silpnosios pusės yra gerai žinomos. Paprastai platformos, kurios išsprendžia kai kurias programų problemas, yra palyginamos. Straipsnyje parodysiu šiuo atveju naudojamą metodiką, naudodamas duomenų bazių pavyzdį kaip dalyką, kuris Habr skaitytojams yra žinomas iš pirmų lūpų. Taigi,
Motyvacija
Pradėjus edukacinį projektą ar pomėgių projektą, motyvacija rinktis platformą gali būti labai įvairi: „šią platformą aš geriausiai išmanau“, „Man įdomu tai suprasti“, „čia yra geriausia dokumentacija“ ... Komercinės įmonės atveju atrankos kriterijus yra tas pats: kiek turėsiu mokėti ir ką gausiu už šiuos pinigus.
Natūralu, kad norite mokėti mažiau ir gauti daugiau. Tačiau reikia nuspręsti, kas svarbiau – mokėti mažiau ar gauti daugiau, ir kiekvienam mazgui priskirti svorį. Tarkime, kad kokybiškas sprendimas mums svarbesnis nei pigus, o mazgui „Kaina“ priskiriame 40%, o „Galimybių“ – 60%.
Didelėse korporacijose dažniausiai būna atvirkščiai – išlaidų svoris nenukrenta žemiau 50%, o gal ir daugiau nei 60%. Modelio pavyzdyje svarbu tik tai, kad bendras bet kurio pirminio mazgo antrinių mazgų svoris turi būti 100%.
Atjungimo sąlygos
Interneto svetainė Yra žinoma apie 500 duomenų bazių valdymo sistemų. Natūralu, kad jei pasirinksite tikslinę platformą iš daugybės variantų, galite gauti apžvalgos straipsnį, bet ne komercinį projektą. Siekiant sumažinti pasirinkimo erdvę, suformuluojami ribiniai kriterijai, o jei platforma šių kriterijų neatitinka, į ją neatsižvelgiama.
Ribiniai kriterijai gali būti susiję su technologinėmis savybėmis, pavyzdžiui:
- ACID garantijos;
- reliacinis duomenų modelis;
- SQL kalbos palaikymas (atkreipkite dėmesį, kad tai nėra tas pats, kas „santykinis modelis“);
- horizontalaus mastelio galimybė.
Gali būti bendri kriterijai:
- komercinės paramos prieinamumas Rusijoje;
- atviro kodo;
- platformos prieinamumas Telekomunikacijų ir masinių ryšių ministerijos registre;
- platformos buvimas tam tikrame reitinge (pavyzdžiui, pirmajame db-engines.com reitingo šimte);
- ekspertų buvimas rinkoje (pavyzdžiui, remiantis platformos pavadinimo paieškos rezultatais gyvenimo aprašyme svetainėje hh.ru).
Galų gale, gali būti konkrečiai įmonei taikomi kriterijai:
- specialistų prieinamumas personalui;
- suderinamumas su stebėjimo sistema X arba atsargine sistema Y, kuria grindžiamas visas palaikymas...
Svarbiausia, kad būtų ribinių kriterijų sąrašas. Priešingu atveju tikrai atsiras koks nors ekspertas (arba „ekspertas“), kuriam patiks ypatingas vadovybės pasitikėjimas ir kuris pasakys: „Kodėl nepasirinkote Z platformos, aš žinau, kad ji yra geriausia“.
Išlaidų sąmata
Akivaizdu, kad sprendimo kaina susideda iš licencijų, palaikymo ir įrangos kainos.
Jei sistemos yra maždaug tos pačios klasės (pavyzdžiui, Microsoft SQL Server ir PostgreSQL), tai dėl paprastumo galime manyti, kad abiejų sprendimų įrangos kiekis bus maždaug toks pat. Tai leis neįvertinti įrangos, taip sutaupant daug laiko ir pastangų. Jeigu tenka lyginti visiškai skirtingas sistemas (tarkim, Oracle vs. Redis), tai akivaizdu, kad teisingam įvertinimui būtina atlikti dydžių (įrangos kiekio skaičiavimą). Neegzistuojančios sistemos dydžio nustatymas yra labai nedėkingas darbas, todėl jie vis tiek stengiasi vengti tokių palyginimų. Tai padaryti nesunku: ribinėmis sąlygomis įrašomas nulinis duomenų praradimas ir reliacinis modelis arba atvirkščiai – 50 tūkstančių operacijų per sekundę apkrova.
Norint įvertinti licencijas, užtenka pardavėjo ar jo partnerių paklausti licencijos kainos fiksuotam branduolių skaičiui ir palaikymo nustatytam laikotarpiui. Paprastai įmonės jau palaiko tvirtus ryšius su programinės įrangos pardavėjais, o jei duomenų bazės operacijų skyrius pats negali atsakyti į išlaidų klausimą, tai šiai informacijai gauti pakanka vieno laiško.
Skirtingi tiekėjai gali turėti skirtingą licencijavimo metriką: pagal branduolių skaičių, duomenų kiekį arba mazgų skaičių. Budėjimo bazė gali būti nemokama arba licencijuota taip pat, kaip ir pagrindinė. Jei aptiksite kokių nors metrikų skirtumų, turėsite detaliai aprašyti pavyzdinį stendą ir apskaičiuoti stendo licencijų kainą.
Svarbus teisingo palyginimo momentas yra tos pačios paramos sąlygos. Pavyzdžiui, Oracle palaikymas kainuoja 22% licencijos kainos per metus, tačiau jums nereikia mokėti už PostgreSQL palaikymą. Ar teisinga taip lyginti? Ne, nes klaida, kurios nepavyks ištaisyti savarankiškai, turi visiškai kitokias pasekmes: pirmuoju atveju pagalbos specialistai greitai padės ją ištaisyti, tačiau antruoju atveju kyla rizika, kad projektas bus atidėtas arba baigtas prastovos. sistema neribotam laikui.
Skaičiavimo sąlygas galite išlyginti trimis būdais:
- Naudokite „Oracle“ be palaikymo (iš tikrųjų tai neįvyksta).
- Įsigykite „PostgreSQL“ palaikymą, pavyzdžiui, iš „Postgres Professional“.
- Atsižvelkite į riziką, susijusią su paramos trūkumu.
Pavyzdžiui, rizikos apskaičiavimas gali atrodyti taip: mirtinai sugedus duomenų bazei, sistemos prastovos laikas būtų 1 darbo diena. Prognozuojamas pelnas naudojant sistemą – 40 mlrd. MNT per metus, avaringumas – 1/400, taigi paramos trūkumo rizika vertinama apie 100 mln. MNT per metus. Akivaizdu, kad „planuotas pelnas“ ir „apskaičiuotas avarijų dažnis“ yra virtualios reikšmės, tačiau daug geriau turėti tokį modelį nei jo neturėti.
Tiesą sakant, sistema gali būti per daug svarbi, kad ilgalaikės prastovos reputacijos išlaidos būtų nepriimtinos, todėl reikės pagalbos. Jei prastovos yra leidžiamos, tada pagalbos atsisakymas kartais gali būti geras būdas sutaupyti pinigų.
Darykime prielaidą, kad atlikus visus skaičiavimus, platformos A veiklos kaina 5 metams pasirodo 800 mln. MNT, B platformos – 650 mln. MNT, o C platformos – 600 mln. Platforma C, kaip laimėtoja, gauna pilną tašką už kainą, o platformos A ir B – šiek tiek mažiau, proporcingai tam, kiek kartų brangiau. Šiuo atveju – atitinkamai 0.75 ir 0.92 balo.
Galimybių vertinimas
Galimybių vertinimas skirstomas į daugybę grupių, kurių skaičių riboja tik vertinančiojo vaizduotė. Atrodo, kad optimaliausias variantas yra padalinti pajėgumus į komandas, kurios naudosis šiomis galimybėmis; mūsų pavyzdyje tai yra kūrėjai, administratoriai ir informacijos saugos pareigūnai. Tarkime, kad šių funkcijų svoriai yra paskirstyti 40:40:20.
Plėtros funkcijos apima:
- duomenų tvarkymo paprastumas;
- mastelio keitimas;
- antrinių indeksų buvimas.
Kriterijų sąrašas ir jų svoriai yra labai subjektyvūs. Net ir sprendžiant tą pačią problemą, šie sąrašai, elementų svoriai ir atsakymai labai skirsis priklausomai nuo jūsų komandos sudėties. Pavyzdžiui, „Facebook“ naudoja „MySQL“ duomenims saugoti, o „Instagram“ yra sukurta „Cassandra“. Mažai tikėtina, kad šių programų kūrėjai užpildė tokias lenteles. Galima tik spėlioti, kad Markas Zuckerbergas pasirinko visavertį reliacinį modelį, už jį mokėdamas pritaikant dalijimąsi, o Kevinas Systromas sukūrė mastelio keitimą naudodamas platformą, paaukodamas lengvą prieigą prie duomenų.
Administravimo funkcijos apima:
- atsarginės sistemos galimybės;
- stebėjimo paprastumas;
- pajėgumų valdymo paprastumas – diskai ir mazgai;
- duomenų replikavimo galimybes.
Atkreipkite dėmesį, kad klausimai turi būti suformuluoti kiekybiškai. Jūs netgi galite susitarti, kaip įvertinti tam tikrą funkciją. Pavyzdžiui, pabandykime įvertinti atsarginių kopijų kūrimo įrankius naudodami įrankių, pateiktų kartu su Oracle DBVS, pavyzdį:
Įrankis
Komentuoti
Vertinimas
imp/exp
Duomenų įkėlimas ir įkėlimas
0.1
pradėti / pabaigti atsarginę kopiją
Failų kopijavimas
0.3
RMAN
Laipsniško kopijavimo galimybė
0.7
ZDLRA
Tik laipsniškas kopijavimas, greičiausias atkūrimas iki taško
1.0
Jei nėra aiškių vertinimo kriterijų, prasminga paprašyti kelių ekspertų, kad jie suteiktų įvertinimus ir tada juos suvidurkuotų.
Galiausiai tiesiog išvardijame informacijos saugos funkcijas:
- slaptažodžių valdymo politikos prieinamumas;
- galimybė prijungti išorinius autentifikavimo įrankius (LDAP, Kerberos);
- prieigos pavyzdys;
- audito galimybės;
- duomenų šifravimas diske;
- šifravimas perdavimo tinkle metu (TLS);
- duomenų apsauga nuo administratoriaus.
Veikimo testavimas
Atskirai norėčiau perspėti, kad nenaudotumėte jokių apkrovos bandymų rezultatų, kurių nepateikėte kaip argumentus.
Pirma, bandomų programų duomenų struktūra ir apkrovos profilis gali labai skirtis nuo problemos, kurią ketinate išspręsti. Maždaug prieš 10-15 metų duomenų bazių pardavėjai mėgo puikuotis TPC testuose pasiektais rezultatais, o dabar, panašu, niekas į šiuos rezultatus nežiūri rimtai.
Antra, sistemos veikimas gana stipriai priklauso nuo to, kokiai platformai iš pradžių buvo parašytas kodas ir kokia įranga buvo atliktas testas. Mačiau daug testų, kuriuose „Oracle“ buvo lyginamas su „PostgreSQL“. Rezultatai svyruoja nuo besąlygiško vienos sistemos pranašumo iki tokios pat besąlygiško kitos sistemos pranašumo.
Ir galiausiai, trečia, jūs nieko nežinote apie tai, kas atliko testą. Abi kvalifikacijos yra svarbios, turinčios įtakos OS ir platformos nustatymo kokybei, taip pat motyvacijai, kuri įtakoja testo rezultatus labiau nei visi kiti veiksniai kartu paėmus.
Jei našumas yra kritinis veiksnys, atlikite testą patys, pageidautina su žmonėmis, kurie sukonfigūruos ir prižiūrės gamybos sistemą.
Rezultatas
Galiausiai, visų atliktų darbų rezultatas turėtų būti skaičiuoklė, kurioje visi įverčiai yra sujungiami, padauginami ir sumuojami:
Kaip suprantate, pakeitus skales ir koreguojant įvertinimus galima pasiekti bet kokį norimą rezultatą, bet tai visai kita istorija...
Šaltinis: www.habr.com
