„Þetta er nauðsynlegt,“ sagði hún hátt og ávarpaði engan. — Þetta er nauðsynlegt! Þetta er nákvæmlega það sem segir: Meginverkefni fyrirtækis er að græða í þágu hluthafa. Jæja, hugsaðu málið! Þeir eru ekki hræddir við neitt!
Yuliy Dubov, „Lesser Evil“
Eftir að hafa séð slíka fyrirsögn ertu líklega búinn að ákveða að greinin sé annað hvort heimska eða ögrun. En ekki flýta sér að draga ályktanir: starfsmenn stórra fyrirtækja, sérstaklega fyrirtækja með ríkisþátttöku, þurfa oft að bera saman mismunandi vettvang, þar á meðal gjörólíka - til dæmis þá sem eru í titlinum.
Auðvitað ber enginn DBMS saman á þennan hátt, því styrkleikar og veikleikar þeirra eru vel þekktir. Að jafnaði eru pallar sem leysa sum forritsvandamál háð samanburði. Í greininni mun ég sýna aðferðafræðina sem notuð er í þessu tilfelli, með dæmi um gagnagrunna sem viðfangsefni sem lesendur Habr þekkja af eigin raun. Svo,
Hvatning
Þegar þú byrjar á fræðsluverkefni eða áhugamálsverkefni getur hvatningin fyrir því að velja vettvang verið mjög fjölbreytt: „þetta er sá vettvangur sem ég þekki best“, „ég hef áhuga á að skilja þetta“, „hér er besta skjölin“ ... Þegar um viðskiptafyrirtæki er að ræða er valviðmiðunin sú sama: hversu mikið þarf ég að borga og hvað fæ ég fyrir þennan pening.
Þú vilt náttúrulega borga minna og fá meira. Hins vegar þarftu að ákveða hvað er mikilvægara - að borga minna eða fá meira og úthluta hverjum hnút þyngd. Gerum ráð fyrir að hágæða lausn sé mikilvægari fyrir okkur en ódýr og við gefum 40% vægi á "Kostnað" hnútinn og 60% á "Tækifæri" hnútinn.
Í stórum fyrirtækjum er þessu venjulega öfugt farið - kostnaðarvægið fer ekki niður fyrir 50% og kannski meira en 60%. Í líkanadæminu er allt sem skiptir máli að heildarþyngd undirhnúta hvers móðurhnúts verður að vera 100%.
Skilyrði fyrir lokun
Vefsíða Um 500 gagnagrunnsstjórnunarkerfi eru þekkt. Auðvitað, ef þú velur markvettvang úr svo mörgum valkostum, gætirðu endað með yfirlitsgrein, en ekki viðskiptaverkefni. Til að draga úr valrými eru mótuð niðurskurðarviðmið og ef vettvangurinn uppfyllir ekki þessi skilyrði kemur hann ekki til greina.
Viðmiðunarmörk geta tengst tæknilegum eiginleikum, til dæmis:
- SÚRU ábyrgðir;
- venslagagnalíkan;
- SQL tungumálastuðningur (athugið að þetta er ekki það sama og „tengslalíkanið“);
- möguleiki á láréttri mælingu.
Það geta verið almenn viðmið:
- framboð á viðskiptalegum stuðningi í Rússlandi;
- opinn uppspretta;
- framboð á vettvangi í skrá fjarskipta- og fjöldasamskiptaráðuneytisins;
- tilvist pallsins í einhverri einkunn (til dæmis á fyrstu hundrað db-engines.com einkunnarinnar);
- tilvist sérfræðinga á markaðnum (til dæmis byggt á niðurstöðum leitarinnar að nafni vettvangsins í ferilskrá á vefsíðunni hh.ru).
Þegar öllu er á botninn hvolft geta verið sérstök viðmið fyrir fyrirtæki:
- framboð á sérfræðingum á starfsfólki;
- samhæfni við vöktunarkerfi X eða varakerfi Y, sem allur stuðningur byggist á...
Mikilvægast er að það sé til listi yfir viðmiðunarmörk. Annars verður örugglega einhver sérfræðingur (eða „sérfræðingur“) sem nýtur sérstaks trausts frá stjórnendum sem mun segja „af hverju valdirðu ekki vettvang Z, ég veit að hann er bestur.“
Kostnaðaráætlun
Kostnaður við lausnina samanstendur augljóslega af kostnaði við leyfi, kostnaði við stuðning og kostnaði við búnað.
Ef kerfin eru um það bil sami flokkur (til dæmis Microsoft SQL Server og PostgreSQL), þá má til einföldunar gera ráð fyrir að magn búnaðar fyrir báðar lausnirnar verði um það bil það sama. Þetta gerir þér kleift að meta ekki búnaðinn og sparar þar með mikinn tíma og fyrirhöfn. Ef þú þarft að bera saman gjörólík kerfi (t.d. Oracle vs. Redis) þá er augljóst að fyrir rétt mat þarf að gera stærðargreiningu (útreikningur á magni búnaðar). Það er mjög vanþakklátt verkefni að stærð kerfis sem ekki er til, svo þeir reyna samt að forðast slíkan samanburð. Þetta er auðvelt að gera: í stöðvunarskilyrðum er núll gagnatap og venslalíkan skrifað, eða öfugt - 50 þúsund færslur á sekúndu.
Til að meta leyfi er nóg að biðja seljanda eða samstarfsaðila hans um kostnað við leyfi fyrir fastan fjölda kjarna og stuðning í ákveðinn tíma. Fyrirtæki eru að jafnaði nú þegar í sterkum tengslum við hugbúnaðarframleiðendur og ef rekstrardeild gagnagrunns getur ekki svarað kostnaðarspurningunni ein og sér þá nægir einn stafur til að fá þessar upplýsingar.
Mismunandi söluaðilar geta haft mismunandi leyfismælikvarða: eftir fjölda kjarna, gagnamagn eða fjölda hnúta. Biðstöðin getur verið ókeypis, eða hún getur fengið leyfi á sama hátt og aðalstöðin. Ef einhver munur á mælingum kemur í ljós verður þú að lýsa fyrirmyndarbásnum í smáatriðum og reikna út kostnað við leyfi fyrir standinn.
Mikilvægur punktur fyrir réttan samanburð eru sömu stuðningsskilyrði. Til dæmis kostar Oracle stuðningur 22% af leyfisverði á ári, en þú þarft ekki að borga fyrir PostgreSQL stuðning. Er rétt að bera svona saman? Nei, vegna þess að villa sem ekki er hægt að laga á eigin spýtur hefur allt aðrar afleiðingar: í fyrra tilvikinu munu stuðningssérfræðingar hjálpa þér fljótt að laga hana, en í öðru tilvikinu er hætta á að verkefnið tefjist eða stöðvun þess fullunnar. kerfi um óákveðinn tíma.
Þú getur jafnað útreikningsskilyrðin á þrjá vegu:
- Notaðu Oracle án stuðnings (í raun og veru gerist þetta ekki).
- Kauptu stuðning fyrir PostgreSQL - til dæmis frá Postgres Professional.
- Taktu tillit til áhættunnar sem fylgir skorti á stuðningi.
Til dæmis gæti áhættuútreikningur litið svona út: ef banvæn bilun í gagnagrunni verður, þá væri niðurtími kerfisins 1 virkur dagur. Áætlaður hagnaður af notkun kerfisins er 40 milljarðar MNT á ári, slysatíðni er talin vera 1/400, þannig að hættan á skorti á stuðningi er áætluð um 100 milljónir MNT á ári. Augljóslega eru „fyrirhugaður hagnaður“ og „áætluð slysatíðni“ sýndargildi, en það er miklu betra að hafa slíkt líkan en ekki.
Í raun og veru getur kerfið verið of mikilvægt til að orðsporskostnaður við langtíma niður í miðbæ sé óviðunandi, þannig að þörf er á stuðningi. Ef niður í miðbæ er leyfður getur það stundum verið góð leið til að spara peninga að neita aðstoð.
Gerum ráð fyrir að eftir alla útreikninga reynist kostnaður við að reka vettvang A í 5 ár vera 800 milljónir MNT, kostnaður við að reka vettvang B er 650 milljónir MNT og kostnaður við að reka vettvang C er 600 milljónir MNT. Platur C, sem sigurvegari, fær fullt stig fyrir verðið, en pallar A og B fá aðeins minna, í hlutfalli við hversu oft þeir eru dýrari. Í þessu tilviki - 0.75 og 0.92 stig, í sömu röð.
Tækifærismat
Mat á tækifærum er skipt í marga hópa, fjöldi þeirra takmarkast aðeins af hugmyndaauðgi þess sem matið er. Ákjósanlegasti kosturinn virðist vera að skipta getu í teymi sem munu nota þessa getu; í okkar dæmi eru þetta forritarar, stjórnendur og upplýsingaöryggisfulltrúar. Gerum ráð fyrir að vægi þessara falla sé dreift sem 40:40:20.
Þróunaraðgerðir fela í sér:
- auðveld meðferð gagna;
- mælikvarði;
- tilvist aukavísitölu.
Viðmiðunarlistinn, sem og vægi þeirra, er mjög huglægur. Jafnvel þegar verið er að leysa sama vandamálið munu þessir listar, þyngd hlutar og svör vera verulega mismunandi eftir samsetningu teymisins þíns. Til dæmis notar Facebook MySQL til að geyma gögn og Instagram er byggt á Cassöndru. Það er ólíklegt að verktaki þessara forrita hafi fyllt út slíkar töflur. Maður getur aðeins giskað á að Mark Zuckerberg hafi valið fullkomið venslalíkan, borgað fyrir það með þörfinni fyrir beitt sharding, á meðan Kevin Systrom smíðaði mælikvarða með því að nota vettvanginn og fórnaði auðveldum aðgangi að gögnum.
Stjórnunaraðgerðir fela í sér:
- afritunarkerfisgetu;
- auðveld eftirlit;
- auðveld afkastagetustjórnun - diskar og hnútar;
- gagnaafritunargetu.
Athugið að spurningar verða að vera orðaðar á megindlegan hátt. Þú getur jafnvel komið þér saman um hvernig eigi að meta tiltekna aðgerð. Við skulum, til dæmis, reyna að gefa öryggisafritunarverkfæri einkunn með því að nota dæmið um verkfæri sem fylgja Oracle DBMS:
Tól
Athugasemd
Mat
imp/exp
Hlaða upp og hlaða gögnum
0.1
byrja / enda öryggisafrit
Að afrita skrár
0.3
RMAN
Stigvaxandi afritunargeta
0.7
ZDLRA
Aðeins stigvaxandi afritun, hraðasta endurheimt til að benda á
1.0
Ef það eru engin skýr matsviðmið er skynsamlegt að biðja nokkra sérfræðinga um að gefa einkunnir og síðan meðaltal þeirra.
Að lokum listum við einfaldlega upp upplýsingaöryggisaðgerðirnar:
- framboð á lykilorðastjórnunarstefnu;
- getu til að tengja ytri auðkenningarverkfæri (LDAP, Kerberos);
- fyrirmynd aðgengis;
- endurskoðunargetu;
- dulkóðun gagna á diski;
- dulkóðun meðan á sendingu stendur yfir netið (TLS);
- gagnavernd frá stjórnanda.
Frammistöðuprófun
Sérstaklega vil ég vara við því að nota niðurstöður álagsprófa sem ekki voru gerðar af þér sem rök.
Í fyrsta lagi getur gagnauppbygging og álagssnið forritanna sem verið er að prófa verið verulega frábrugðin vandamálinu sem þú ætlar að leysa. Fyrir um 10-15 árum elskuðu gagnagrunnsframleiðendur að flagga þeim árangri sem náðst hefur í TPC prófunum, en nú virðist enginn taka þessar niðurstöður alvarlega.
Í öðru lagi fer frammistaða kerfisins mjög eftir því fyrir hvaða vettvang kóðinn var upphaflega skrifaður og af hvaða búnaði prófunin var framkvæmd. Ég hef séð mörg próf þar sem Oracle var borið saman við PostgreSQL. Niðurstöðurnar eru allt frá skilyrðislausum yfirburðum eins kerfis til jafn skilyrðislausra yfirburða annars.
Og að lokum, í þriðja lagi, þú veist ekkert um hver gerði prófið. Báðar hæfniskröfurnar eru mikilvægar, hafa áhrif á gæði uppsetningar stýrikerfisins og vettvangsins, sem og hvatning, sem hefur meiri áhrif á niðurstöður prófanna en allir aðrir þættir samanlagt.
Ef árangur er mikilvægur þáttur skaltu framkvæma prófið sjálfur, helst með hjálp þeirra sem munu stilla og viðhalda framleiðslukerfinu.
Niðurstaðan
Að lokum ætti niðurstaða allrar vinnunnar að vera töflureikni þar sem allar áætlanir eru sameinaðar, margfaldaðar og teknar saman:
Eins og þú skilur geturðu náð hvaða árangri sem þú vilt með því að breyta kvarðanum og stilla einkunnirnar, en það er allt önnur saga...
Heimild: www.habr.com