â 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
