Cila është më e mirë - Oracle ose Redis ose Si të justifikoni zgjedhjen e platformës

"Kjo është e nevojshme," tha ajo me zë të lartë, duke mos iu drejtuar askujt. - Kjo është e nevojshme! Kjo është pikërisht ajo që thotë: detyra kryesore e një kompanie është të bëjë një fitim në interes të aksionerëve. Epo, mendoni për këtë! Ata nuk kanë frikë nga asgjë!

Yuliy Dubov, "E keqja më e vogël"

Duke parë një titull të tillë, me siguri keni vendosur tashmë që artikulli është ose marrëzi ose provokim. Por mos nxitoni në përfundime: punonjësit e korporatave të mëdha, veçanërisht korporatat me pjesëmarrje shtetërore, mjaft shpesh duhet të krahasojnë platforma të ndryshme, duke përfshirë ato krejtësisht të ndryshme - për shembull, ato në titull.

Cila është më e mirë - Oracle ose Redis ose Si të justifikoni zgjedhjen e platformës

Sigurisht, askush nuk i krahason DBMS-të në këtë mënyrë, sepse pikat e forta dhe të dobëta të tyre janë të njohura mirë. Si rregull, platformat që zgjidhin disa probleme aplikimi i nënshtrohen krahasimit. Në artikull do të tregoj metodologjinë që përdoret në këtë rast, duke përdorur shembullin e bazave të të dhënave si një temë e njohur për lexuesit e Habrit. Kështu që,

motivimi

Kur filloni një projekt edukativ ose një projekt hobi, motivimi për të zgjedhur një platformë mund të jetë shumë i larmishëm: "kjo është platforma që unë e njoh më mirë", "Unë jam i interesuar ta kuptoj këtë", "këtu është dokumentacioni më i mirë" ... Në rastin e një shoqërie tregtare, kriteri i përzgjedhjes është i njëjtë: sa do të duhet të paguaj dhe çfarë do të marr për këto para.

Natyrisht, ju dëshironi të paguani më pak dhe të merrni më shumë. Megjithatë, ju duhet të vendosni se çfarë është më e rëndësishme - të paguani më pak ose të merrni më shumë, dhe t'i caktoni një peshë çdo nyjeje. Le të supozojmë se një zgjidhje me cilësi të lartë është më e rëndësishme për ne sesa një e lirë, dhe ne caktojmë një peshë prej 40% për nyjen "Kosto" dhe 60% për nyjen "Mundësitë".

Cila është më e mirë - Oracle ose Redis ose Si të justifikoni zgjedhjen e platformës

Në korporatat e mëdha, zakonisht e kundërta është e vërtetë - pesha e kostos nuk bie nën 50%, dhe ndoshta më shumë se 60%. Në shembullin e modelit, gjithçka që është e rëndësishme është që pesha totale e nyjeve të fëmijëve të çdo nyjeje mëmë duhet të jetë 100%.

Kushtet e ndërprerjes

Faqja e internetit db- motorë.com Janë të njohura rreth 500 sisteme të menaxhimit të bazës së të dhënave. Natyrisht, nëse zgjidhni një platformë të synuar nga kaq shumë opsione, mund të përfundoni me një artikull rishikimi, por jo një projekt komercial. Për të zvogëluar hapësirën e zgjedhjes, formulohen kriteret e ndërprerjes dhe nëse platforma nuk i plotëson këto kritere, atëherë nuk merret parasysh.

Kriteret e ndërprerjes mund të lidhen me veçoritë teknologjike, për shembull:

  • Garancitë ACID;
  • modeli i të dhënave relacionale;
  • Mbështetja e gjuhës SQL (vini re, ky nuk është i njëjtë me "modelin relacional");
  • mundësia e shkallëzimit horizontal.

Mund të ketë kritere të përgjithshme:

  • disponueshmëria e mbështetjes tregtare në Rusi;
  • burim i hapur;
  • disponueshmëria e platformës në Regjistrin e Ministrisë së Telekomit dhe Komunikimeve Masive;
  • prania e platformës në disa vlerësime (për shembull, në qindëshin e parë të vlerësimit db-engines.com);
  • prania e ekspertëve në treg (për shembull, bazuar në rezultatet e kërkimit të emrit të platformës në një rezyme në faqen e internetit hh.ru).

Në fund të fundit, mund të ketë kritere specifike të ndërmarrjes:

  • disponueshmëria e specialistëve në staf;
  • pajtueshmëria me sistemin e monitorimit X ose sistemin rezervë Y, mbi të cilin bazohet e gjithë mbështetja...

Gjëja më e rëndësishme është se ekziston një listë e kritereve të ndërprerjes. Përndryshe, do të ketë patjetër një ekspert (ose "ekspert") që gëzon besim të veçantë nga menaxhmenti, i cili do të thotë "pse nuk zgjodhët platformën Z, e di që është më e mira".

Vlerësimi i kostos

Kostoja e zgjidhjes padyshim përbëhet nga kostoja e licencave, kostoja e mbështetjes dhe kostoja e pajisjeve.

Nëse sistemet janë afërsisht të njëjtën klasë (për shembull, Microsoft SQL Server dhe PostgreSQL), atëherë për thjeshtësi mund të supozojmë se sasia e pajisjeve për të dy zgjidhjet do të jetë afërsisht e njëjtë. Kjo do t'ju lejojë të mos vlerësoni pajisjet, duke kursyer kështu shumë kohë dhe përpjekje. Nëse duhet të krahasoni sisteme krejtësisht të ndryshme (të themi, Oracle vs. Redis), atëherë është e qartë se për një vlerësim të saktë është e nevojshme të bëhet madhësia (llogaritja e sasisë së pajisjeve). Përcaktimi i madhësisë së një sistemi që nuk ekziston është një detyrë shumë e pafalshme, kështu që ata ende përpiqen të shmangin krahasime të tilla. Kjo është e lehtë për t'u bërë: në kushtet e ndërprerjes, shkruhet humbja zero e të dhënave dhe një model relacional, ose anasjelltas - një ngarkesë prej 50 mijë transaksionesh në sekondë.

Për të vlerësuar licencat, mjafton të pyesni shitësin ose partnerët e tij për koston e një licence për një numër fiks bërthamash dhe mbështetje për një periudhë të caktuar. Si rregull, kompanitë tashmë kanë marrëdhënie të forta me shitësit e softuerit dhe nëse departamenti i operacioneve të bazës së të dhënave nuk mund t'i përgjigjet pyetjes së kostos vetë, atëherë mjafton një shkronjë për të marrë këtë informacion.

Shitës të ndryshëm mund të kenë metrika të ndryshme licencimi: sipas numrit të bërthamave, vëllimit të të dhënave ose numrit të nyjeve. Baza e gatishmërisë mund të jetë e lirë, ose mund të licencohet në të njëjtën mënyrë si ajo kryesore. Nëse zbulohen ndonjë ndryshim në metrikë, do t'ju duhet të përshkruani në detaje modelin e stendës dhe të llogarisni koston e licencave për stendën.

Një pikë e rëndësishme për një krahasim të saktë janë të njëjtat kushte mbështetëse. Për shembull, mbështetja e Oracle kushton 22% të çmimit të licencës në vit, por nuk duhet të paguani për mbështetjen e PostgreSQL. A është e drejtë krahasimi i tillë? Jo, sepse një gabim që nuk mund të rregullohet vetë ka pasoja krejtësisht të ndryshme: në rastin e parë, specialistët e mbështetjes do t'ju ndihmojnë shpejt ta rregulloni atë, por në rastin e dytë, ekziston rreziku i vonimit të projektit ose joprodukteve të përfunduara. sistem për një periudhë të pacaktuar.

Ju mund të barazoni kushtet e llogaritjes në tre mënyra:

  1. Përdorni Oracle pa mbështetje (në realitet kjo nuk ndodh).
  2. Blini mbështetje për PostgreSQL - për shembull, nga Postgres Professional.
  3. Merrni parasysh rreziqet që lidhen me mungesën e mbështetjes.

Për shembull, një llogaritje e rrezikut mund të duket kështu: në rast të një dështimi fatal të bazës së të dhënave, koha e ndërprerjes së sistemit do të ishte 1 ditë pune. Fitimi i parashikuar nga përdorimi i sistemit është 40 miliardë MNT në vit, shkalla e aksidenteve vlerësohet të jetë 1/400, kështu që rreziku i mungesës së mbështetjes vlerësohet në afërsisht 100 milion MNT në vit. Natyrisht, "fitimi i planifikuar" dhe "frekuenca e parashikuar e aksidenteve" janë vlera virtuale, por është shumë më mirë të kesh një model të tillë sesa të mos kesh asnjë.

Në realitet, sistemi mund të jetë shumë i rëndësishëm që kostoja e reputacionit të joproduktive afatgjatë të jetë e papranueshme, kështu që do të kërkohet mbështetje. Nëse lejohet pushimi, atëherë refuzimi i mbështetjes ndonjëherë mund të jetë një mënyrë e mirë për të kursyer para.

Le të supozojmë se pas të gjitha llogaritjeve, kostoja e platformës operative A për 5 vjet rezulton të jetë 800 milion MNT, kostoja e platformës operative B është 650 milion MNT dhe kostoja e platformës operative C është 600 milion MNT. Platforma C, si fituese, merr një pikë të plotë për çmimin, ndërsa platformat A dhe B marrin pak më pak, në raport me sa herë janë më të shtrenjta. Në këtë rast - 0.75 dhe 0.92 pikë, respektivisht.

Vlerësimi i Mundësisë

Vlerësimi i mundësive ndahet në shumë grupe, numri i të cilave është i kufizuar vetëm nga imagjinata e personit që bën vlerësimin. Opsioni optimal duket të jetë ndarja e aftësive në ekipe që do t'i përdorin këto aftësi; në shembullin tonë, këta janë zhvillues, administratorë dhe oficerë të sigurisë së informacionit. Le të supozojmë se peshat e këtyre funksioneve shpërndahen si 40:40:20.

Funksionet e zhvillimit përfshijnë:

  • lehtësia e manipulimit të të dhënave;
  • shkallëzim;
  • prania e indekseve dytësore.

Lista e kritereve, si dhe pesha e tyre, janë shumë subjektive. Edhe kur zgjidhni të njëjtin problem, këto lista, pesha e artikujve dhe përgjigjet do të ndryshojnë ndjeshëm në varësi të përbërjes së ekipit tuaj. Për shembull, Facebook përdor MySQL për të ruajtur të dhënat, dhe Instagram është ndërtuar në Cassandra. Nuk ka gjasa që zhvilluesit e këtyre aplikacioneve të kenë plotësuar tabela të tilla. Mund të merret me mend vetëm se Mark Zuckerberg zgjodhi një model të plotë relacional, duke e paguar atë me nevojën për ndarje të aplikuar, ndërsa Kevin Systrom ndërtoi shkallëzimin duke përdorur platformën, duke sakrifikuar lehtësinë e aksesit në të dhëna.

Funksionet e administratës përfshijnë:

  • aftësitë e sistemit rezervë;
  • lehtësia e monitorimit;
  • lehtësia e menaxhimit të kapacitetit - disqe dhe nyje;
  • aftësitë e riprodhimit të të dhënave.

Ju lutemi vini re se pyetjet duhet të formulohen në mënyrë sasiore. Ju madje mund të bini dakord se si të vlerësoni një funksion të caktuar. Le të përpiqemi, për shembull, të vlerësojmë mjetet rezervë duke përdorur shembullin e mjeteve të ofruara me Oracle DBMS:

Mjet
Koment
Vlerësim

imp/exp
Ngarkimi dhe ngarkimi i të dhënave
0.1

fillimi/mbarimi i rezervimit
Kopjimi i skedarëve
0.3

RMAN
Aftësia e kopjimit në rritje
0.7

ZDLRA
Vetëm kopjimi në rritje, rikuperimi më i shpejtë në pikë
1.0

Nëse nuk ka kritere të qarta vlerësimi, ka kuptim të kërkosh nga disa ekspertë të japin vlerësimet dhe më pas t'i mesatarizojnë ato.

Së fundi, ne thjesht rendisim funksionet e sigurisë së informacionit:

  • disponueshmëria e politikave të menaxhimit të fjalëkalimeve;
  • aftësia për të lidhur mjete të jashtme të vërtetimit (LDAP, Kerberos);
  • modeli i aksesit;
  • aftësitë e auditimit;
  • kriptimi i të dhënave në disk;
  • enkriptimi gjatë transmetimit në rrjet (TLS);
  • mbrojtjen e të dhënave nga administratori.

Testimi i performancës

Më vete, do të doja të paralajmëroja kundër përdorimit të rezultateve të çdo testi të ngarkesës që nuk u bë nga ju si argumente.

Së pari, struktura e të dhënave dhe profili i ngarkesës së aplikacioneve që testohen mund të ndryshojnë ndjeshëm nga problemi që do të zgjidhni. Rreth 10-15 vjet më parë, shitësve të bazës së të dhënave u pëlqente të tregonin rezultatet e arritura në testet TPC, por tani, duket se askush nuk i merr seriozisht këto rezultate.

Së dyti, performanca e sistemit varet shumë nga ajo platformë për cilën kod është shkruar fillimisht dhe nga çfarë pajisje është kryer testi. Unë kam parë shumë teste ku Oracle u krahasua me PostgreSQL. Rezultatet variojnë nga epërsia e pakushtëzuar e një sistemi në epërsinë po aq të pakushtëzuar të një tjetri.

Dhe së fundi, së treti, nuk dini asgjë se kush e bëri testin. Të dy kualifikimet janë të rëndësishme, duke ndikuar në cilësinë e konfigurimit të OS dhe platformës, si dhe motivimin, i cili ndikon në rezultatet e testit më shumë se të gjithë faktorët e tjerë të kombinuar.

Nëse performanca është një faktor kritik, kryeni vetë testin, mundësisht me ndihmën e njerëzve që do të konfigurojnë dhe mirëmbajnë sistemin e prodhimit.

Result

Së fundi, rezultati i gjithë punës së bërë duhet të jetë një tabelë ku të gjitha vlerësimet kombinohen, shumëzohen dhe përmblidhen:

Cila është më e mirë - Oracle ose Redis ose Si të justifikoni zgjedhjen e platformës

Siç e kuptoni, duke ndryshuar peshoren dhe duke rregulluar vlerësimet mund të arrini çdo rezultat të dëshiruar, por kjo është një histori krejtësisht tjetër...

Burimi: www.habr.com

Shto një koment