– Kështu duhet, – tha ajo me zë të lartë, pa iu drejtuar askujt. – Kështu duhet! Kështu është shkruar – detyra kryesore e shoqërisë është nxjerrja e fitimeve në interes të aksionarëve. Mendoni pak! Nuk kanë frikë nga asgjë!
Yuli Dubov, «E keqja më e vogël»
Duke parë një titull të tillë, ju me siguri keni vendosur se artikulli është ose budallallëk, ose provokim. Por mos nxitojini përfundimet: punonjësit e korporatave të mëdha, veçanërisht të atyre me pjesëmarrje shtetërore, shpesh kanë nevojë të krahasojnë platforma të ndryshme, përfshirë edhe ato krejtësisht të ndryshme – si ato që janë të përmendura në titull.
Sigurisht, askush nuk e krahasohet DBMS në këtë mënyrë, pasi fuqitë dhe dobësitë e saj janë të njohura. Zakonisht, platforma që krahasohet janë ato që zgjidhin një problem praktik. Në këtë artikull do të tregoj metodologjinë që përdoret në këtë rast, duke përdorur shembuj të bazave të të dhënave si një temë, e cila është shumë e njohur për lexuesit e Habrës. Pra,
Motivimi
Kur filloni një projekt mësimor ose një projekt si hob, motivet për të zgjedhur një platformë mund të jenë shumë të ndryshme: "kjo platformë është më e njohur për mua", "kam dëshirë të eksploroj këtë", "këtu është dokumentacioni më i mirë"... Në rastin e një kompanie komerciale, kriteri i zgjedhjes është një: sa do të paguaj dhe çfarë do të marr për këto para.
Natyrisht, dëshirojmë të paguajmë sa më pak, por të marrim sa më shumë. Megjithatë, është e nevojshme të vendosim se çfarë është më e rëndësishme – të paguajmë më pak ose të marrim më shumë, dhe t'i japim secilës nod në peshën e saj. Le të supozojmë se na intereson një zgjidhje cilësore më shumë sesa një të lirë, prandaj i japim nodës "Kosto" një peshë prej 40%, ndërsa nodës "Aftësitë" një peshë prej 60%.
Në korporatat e mëdha, zakonisht ndodh e kundërta – pesha e kostos nuk bie nën 50%, dhe ndoshta është edhe më shumë se 60%. Në shembullin model, e rëndësishme është vetëm se pesha totale e nodëve fëmijë të çdo nodi prind duhet të jetë 100%.
Kushtet përjashtuese
Websajti Sot janë të njohura rreth 500 sisteme menaxhimi të bazave të të dhënave. Natyrisht, nëse zgjedhim një platformë të destinuar nga kaq shumë mundësi, mund të përfundojmë me një artikull përmbledhës, por jo një projekt komercial. Për të ngushtuar hapësirën e zgjedhjes, formulohen kritere përjashtuese, dhe nëse një platformë nuk i përmbush këto kritere, atëherë ajo nuk merret parasysh.
Kriteret përjashtuese mund të lidhen me veçoritë teknologjike, për shembull:
- garancitë ACID;
- modeli relacional i të dhënave;
- mbështetja e gjuhës SQL (kushtojini vëmendje, kjo nuk është e njëjtë me "modelin relacional");
- mundësia e shkallëzimit horizontal.
Mund të ketë kritere të natyrshme të përgjithshme:
- prania e mbështetjes komerciale në Rusi;
- kod i hapur;
- prania e platformës në Regjistrin e Ministrisë së Komunikimeve;
- prania e platformës në ndonjë renditje (për shembull, në njëqindshin më të mirën e renditjes db-engines.com);
- prania e ekspertëve në treg (për shembull, në përfundimet e kërkimit të emrit të platformës në rezumatë në faqen hh.ru).
Në fund, mund të ketë kritere të veçanta për ndërmarrjen:
- prania e specialistëve në personel;
- kompatibiliteti me sistemin e monitorimit X ose me sistemin e backup Y, mbi të cilin mbështetet e gjithë mbështetja…
E rëndësishmja është që të ketë një listë kriteresh përjashtuese. Ndryshe, patjetër do të dalë ndonjë ekspert (ose "ekspert"), që gëzon një besim të veçantë nga drejtuesit, i cili do të thotë "po çfarë nuk e zgjodhët platformën Z, e di, ajo është më e mira."
Vlerësimi i kostos
Kostoja e zgjidhjes përbëhet qartë nga kostoja e licencave, kostoja e mbështetjes dhe kostoja e pajisjeve.
Nëse sistemet janë përafërsisht të njëjtë (p.sh., Microsoft SQL Server dhe PostgreSQL), atëherë për thjeshtësi mund të mendohet se sasia e pajisjeve për të dyja zgjidhjet do të jetë përafërsisht e njëjtë. Kjo do të lejojë që të mos vlerësojmë pajisjet, duke kursyer kështu një sasi të madhe kohe dhe përpjekjeje. Nëse megjithatë duhet të krahasohen sisteme krejtësisht të ndryshme (p.sh., Oracle vs. Redis), është e qartë se për një vlerësim të saktë është e nevojshme të bëhet sizing (llogaria e sasisë së pajisjeve). Sizingu i një sistemi që nuk ekziston është një veprim për të cilin nuk ka shumë vlerë, prandaj krahasimi i tillë zakonisht shmangesh. Kjo është e lehtë për t'u bërë: në kushtet e prerjes shkruhen humbja zero e të dhënave dhe modeli relacional ose e kundërta – ngarkesa prej 50 mijë transaksionesh në sekondë.
Për të vlerësuar licencat, mjafton të kërkoni nga ofruesi ose partnerët e tij çmimin e licencës për një numër të caktuar bërthamash dhe mbështetje për një periudhë të caktuar. Për zakonisht, kompanitë kanë ndërtuar marrëdhënie të forta me ofruesit e softuerit, dhe nëse departamenti i operacioneve të DB nuk mund të përgjigjet për çmimin vetë, një letër e vetme është e mjaftueshme për të marrë këtë informacion.
Ofrues të ndryshëm mund të kenë metrika të ndryshme për licencimin: në bazë të numrit të bërthamave, volumit të të dhënave ose numrit të node-ve. Baza Standby mund të jetë falas, ose mund të licencohet ashtu si baza kryesore. Nëse vetëm janë gjetur ndonjë dallim në metrika, do të duhet të përshkruani në detaje modelin e stendës dhe të llogarisni kostot e licencave për stendën.
Një pikë e rëndësishme për një krahasim të saktë janë kushtet e njëjta të mbështetjes. Për shembull, mbështetja për Oracle kushton 22% të çmimit të licencës për vit, ndërsa për mbështetje të PostgreSQL nuk është e nevojshme të paguash. A është e drejtë të krahasohet kështu? Jo, sepse pasojat e një gabimi që nuk mund të zgjidhet nga forcat e veta janë krejtësisht të ndryshme: në rastin e parë, specialistët e mbështetjes do t'iu ndihmojnë shpejt ta zgjidhni, ndërsa në rastin e dytë ka rrezik për vonesën e projektit ose pezullimin e sistemit të gatshëm për një periudhë të pacaktuar.
Kushtet e llogaritjes mund të nxirren nëpërmjet tri mënyrave:
- Të përdorësh Oracle pa mbështetje (në realitet, kjo nuk ndodh).
- Të blish mbështetje për PostgreSQL – për shembull, nga kompania Postgres Professional.
- Të marrësh parasysh rreziqet e lidhura me mungesën e mbështetjes.
Për shembull, llogaritja e riskut mund të duket kështu: në rast të një dështimi të paevitueshëm të bazës së të dhënave, koha e pezullimit të sistemit do të jetë 1 ditë pune. Fitimi i planifikuar nga përdorimi i sistemit është 40 miliardë tugrikë mongole në vit, frekuenca e aksidenteve vlerësohet si 1/400, kështu që rreziku i mungesës së mbështetjes vlerësohet në rreth 100 milion tugrikë mongole në vit. Është e qartë se "fitimi i planifikuar" dhe "frekuenca e vlerësuar e aksidenteve" janë sajesa, por është shumë më mirë të kemi një model të tillë sesa të mos kemi asnjë.
Në realitet, sistemi mund të jetë shumë i rëndësishëm dhe humbjet reputacionale nga një pezullim i gjatë do të ishin të papranueshme, prandaj mbështetja do të nevojitet. Nëse pezullimi lejohet, heqja dorë nga mbështetja ndonjëherë mund të jetë një mënyrë e mirë për të kursyer.
Supozoni se që pas të gjitha llogarive, kostoja e operimit të platformës A për 5 vjet është 800 milion tugrikë mongole, kostoja e operimit të platformës B është 650 milion tugrikë, ndërsa kostoja e operimit të platformës C është 600 milion tugrikë. Platforma C si fituese merr pikë maksimale për koston, ndërsa platformat A dhe B marrin pak më pak, proporcionalisht me sa herë ato janë më të shtrenjta. Në këtë rast, ato fitoni 0.75 dhe 0.92 pikë përkatësisht.
Vlerësimi i mundësive
Vlerësimi i mundësive ndahet në shumë grupe, numri i të cilave është i kufizuar vetëm nga imagjinata e atij që bënë vlerësimin. Një opsion optimal duket të jetë ndarja e mundësive sipas ekipeve që do t'i përdorin ato; në shembullin tonë, këto janë zhvilluesit, administratorët dhe oficerët e sigurisë së informacionit. Supozoni se pesha e këtyre funksioneve shpërndahet si 40:40:20.
Funksionet e zhvillimit mund të përfshijnë:
- lehtësia në manipulimin e të dhënave;
- shkallëzimi;
- prania e indeksi dytësor.
Lista e kritereve, si dhe pesha e tyre, është shumë subjektive. Edhe kur zgjidhet e njëjta problematikë, këto lista, peshat e pikëve dhe përgjigjet do të ndryshojnë ndjeshëm në varësi të përbërjes së ekipit tuaj. Për shembull, Facebook për ruajtjen e të dhënave përdor MySQL, ndërsa Instagram është ndërtuar mbi bazën e Cassandra. Ka gjasa shumë të ulëta që zhvilluesit e këtyre aplikacioneve kanë plotësuar këto tabela. Mund të supozohet vetëm se Mark Zuckerberg zgjodhi një model relacional të plotë, duke paguar për këtë me nevojën për sharding aplikativ, ndërsa Kevin Systrom vendosi të përdorë skalimin e platformës, duke sakrifikuar lehtësinë e qasjes në të dhëna.
Funksionet e administratës përfshijnë:
- mundësitë e sistemit të kopjimit;
- lehtësinë e monitorimit;
- lehtësinë e menaxhimit të burimeve – disqeve dhe nyjeve;
- mundësitë e replikimit të të dhënave.
Kujdes, formulimet e pyetjeve duhet të lejojnë vlerësimin në mënyrë të kuantifikuar. Mund të bien dakord edhe si të vlerësohet një funksion i caktuar. Le të provoni, për shembull, të vlerësojmë mjetet e kopjimit duke përdorur mjetet e ofruara me DBMS-në Oracle:
Instrument
Komentari
Vlerësimi
imp/exp
Shkarkimi dhe ngarkimi i të dhënave
0.1
fillim/fund backup
Kopjimi i skedarëve
0.3
RMAN
Mundësia për kopjime në inkrementale
0.7
ZDLRA
Kopjim vetëm inkremental, rikuperim më të shpejtë në pikën e dëshiruar
1.0
Nëse nuk ka kritere të qarta vlerësimi, është e arsyeshme të kërkoni nga disa ekspertë të bëjnë vlerësime dhe më pas t'i mesatarizoni ato.
Në fund, le të rendisim funksionet e sigurisë së informacionit:
- prania e politikave për menaxhimin e fjalëkalimeve;
- mundësia e lidhjes me mjete të jashtme autentikimi (LDAP, Kerberos);
- modeli i rolit të aksesit;
- mundësitë për auditim;
- kriptimi i të dhënave në disk;
- kriptimi gjatë transmetimit në rrjet (TLS);
- mbrojtja e të dhënave nga administratori.
Testimi i performancës
Veçmas, do të doja të paralajmëroja kundër përdorimit si argumente të rezultateve të ndonjë testi ngarkese të kryer nga ju.
Së pari, struktura e të dhënave dhe profili i ngarkesës së aplikacioneve të testuara mund të ndryshojnë ndjeshëm nga detyra që dëshironi të zgjidhni. Para 10-15 viteve, prodhuesit e bazave të të dhënave i pëlqente të shfaqnin rezultatet e arritura në testet TPC, por tani duket se askush nuk i merr seriozisht ato rezultate.
Së pari, performanca e sistemit varet mjaft nga platforma për të cilën është shkruar kodin dhe cilat pajisje janë përdorur për testim. Kam parë shumë teste ku Oracle është krahasuar me PostgreSQL. Rezultatet — nga superioriteti absolut i një sistemi deri në superioritetin po aq absolut të tjetrit.
Dhe përfundimisht, në të tretën, nuk dini asgjë rreth asaj kush e kryen testin. Ajo që ka rëndësi është si kualifikimi që ndikon në cilësinë e konfigurimit të OS dhe platformës, ashtu edhe motivimi, i cili ka ndikim në rezultatet më shumë se çdo faktor tjetër së bashku.
Nëse performanca është një faktor kritik, kryeni testin vetë, me pjesëmarrjen e specialistëve që do të konfigurojnë dhe mbajnë sistemin industrial.
Rezultati
Në fund, rezultati i gjithë këtij procesi duhet të jetë një tabelë elektronike, ku të gjitha vlerësimet janë përmbledhur, shumëzuar dhe mbledhur:
Siç e kuptoni, duke ndryshuar peshat dhe duke rregulluar vlerësimet, mund të arrini çdo rezultat të kërkuar, por kjo është një histori krejt tjetër…
Burimi: habr.com
