"Ĉi tio estas necesa," ŝi diris laŭte, alparolante neniun. - Ĉi tio estas necesa! Ĝuste ĉi tio diras: la ĉefa tasko de kompanio estas profiti je la intereso de la akciuloj. Nu, pripensu! Ili nenion timas!
Yuliy Dubov, "Malgranda Malico"
Vidinte tian titolon, vi verŝajne jam decidis, ke la artikolo estas aŭ stulteco aŭ provoko. Sed ne rapidu al konkludoj: dungitoj de grandaj korporacioj, precipe korporacioj kun ŝtata partopreno, sufiĉe ofte devas kompari malsamajn platformojn, inkluzive de tute malsamaj - ekzemple tiuj en la titolo.
Kompreneble, neniu komparas DBMS-ojn tiamaniere, ĉar iliaj fortoj kaj malfortoj estas bone konataj. Kiel regulo, platformoj, kiuj solvas iun aplikproblemon, estas kompareblaj. En la artikolo mi montros la metodikon kiu estas uzata en ĉi tiu kazo, uzante la ekzemplon de datumbazoj kiel temo kiu estas konata al Habr-legantoj propraokule. Do,
Motivacio
Kiam vi komencas edukan projekton aŭ hobian projekton, la instigo por elekti platformon povas esti tre diversa: "ĉi tiu estas la platformo, kiun mi plej bone konas", "mi interesiĝas kompreni ĉi tiun", "jen la plej bona dokumentaro" ... En la kazo de komerca kompanio, la elekta kriterio estas la sama: kiom mi devos pagi kaj kion mi ricevos por ĉi tiu mono.
Nature, vi volas pagi malpli kaj akiri pli. Tamen, vi devas decidi kio estas pli grava - pagi malpli aŭ ricevi pli, kaj atribui pezon al ĉiu nodo. Ni supozu, ke altkvalita solvo estas pli grava por ni ol malmultekosta, kaj ni atribuas pezon de 40% al la nodo "Kosto", kaj 60% al la nodo "Oportunoj".
En grandaj korporacioj kutime estas la malo - la kosto-pezo ne falas sub 50%, kaj eble pli ol 60%. En la modelekzemplo, ĉio grava estas, ke la totala pezo de la infanaj nodoj de iu ajn gepatra nodo devas esti 100%.
Tranĉaj kondiĉoj
Retejo Estas proksimume 500 datumbazaj administradsistemoj konataj. Kompreneble, se vi elektas celplatformon el tiom da ebloj, vi povas fini kun revizia artikolo, sed ne komerca projekto. Por redukti la elektan spacon, detranĉaj kriterioj estas formulitaj, kaj se la platformo ne kontentigas ĉi tiujn kriteriojn, tiam ĝi ne estas konsiderata.
Detranĉkriterioj povas rilati al teknologiaj ecoj, ekzemple:
- ACIDO-garantioj;
- interrilata datummodelo;
- SQL-lingva subteno (notu, ĉi tio ne samas kiel la "rilata modelo");
- ebleco de horizontala skalo.
Povas ekzisti ĝeneralaj kriterioj:
- havebleco de komerca subteno en Rusio;
- malferma fonto;
- havebleco de la platformo en la Registro de la Ministerio de Telekomunikado kaj Amasaj Komunikadoj;
- ĉeesto de la platformo en iu takso (ekzemple, en la unua cento de la db-engines.com rating);
- la ĉeesto de spertuloj en la merkato (ekzemple, surbaze de la rezultoj de serĉado de la nomo de la platformo en vivresumo en la retejo hh.ru).
Post ĉio, povas ekzisti entreprenaj specifaj kriterioj:
- havebleco de specialistoj sur dungitaro;
- kongruo kun monitora sistemo X aŭ rezerva sistemo Y, sur kiu baziĝas ĉiu subteno...
La plej grava afero estas, ke ekzistas listo de detranĉaj kriterioj. Alie, certe estos iu fakulo (aŭ "fakulo"), kiu ĝuas specialan fidon de administrado, kiu diros "kial vi ne elektis platformon Z, mi scias, ke ĝi estas la plej bona."
Kosta takso
La kosto de la solvo evidente konsistas el la kosto de licencoj, la kosto de subteno kaj la kosto de ekipaĵo.
Se la sistemoj estas proksimume la sama klaso (ekzemple, Microsoft SQL Server kaj PostgreSQL), tiam por simpleco ni povas supozi, ke la kvanto de ekipaĵo por ambaŭ solvoj estos proksimume la sama. Ĉi tio permesos al vi ne taksi la ekipaĵon, tiel ŝparante multan tempon kaj penadon. Se vi devas kompari tute malsamajn sistemojn (ekzemple, Oracle vs. Redis), tiam estas evidente, ke por ĝusta takso necesas fari grandecon (kalkulon de la kvanto de ekipaĵo). Dimensigi neekzistantan sistemon estas tre sendanka tasko, do ili ankoraŭ provas eviti tiajn komparojn. Ĉi tio estas facile fari: en la detranĉaj kondiĉoj, nula perdo de datumoj kaj interrilata modelo estas skribitaj, aŭ inverse - ŝarĝo de 50 mil transakcioj por sekundo.
Por taksi licencojn, sufiĉas peti la vendiston aŭ ĝiajn partnerojn pri la kosto de permesilo por fiksa nombro da kernoj kaj subteno por fiksa periodo. Kiel regulo, kompanioj jam havas fortajn rilatojn kun softvarvendistoj, kaj se la datumbaza operacia fako ne povas respondi la kostan demandon per si mem, tiam unu letero sufiĉas por akiri ĉi tiun informon.
Malsamaj vendistoj povas havi malsamajn licencajn metrikojn: laŭ nombro da kernoj, datumvolumeno aŭ nombro da nodoj. La standby bazo povas esti libera, aŭ ĝi povas esti licencita en la sama maniero kiel la ĉefa. Se iuj diferencoj en metrikoj estas malkovritaj, vi devos priskribi la modelstandon detale kaj kalkuli la koston de permesiloj por la stando.
Grava punkto por ĝusta komparo estas la samaj subtenkondiĉoj. Ekzemple, Oracle-subteno kostas 22% de la licenca prezo jare, sed vi ne devas pagi por PostgreSQL-subteno. Ĉu estas ĝuste kompari tiel? Ne, ĉar eraro, kiu ne povas esti riparita memstare, havas tute malsamajn konsekvencojn: en la unua kazo, subtenaj specialistoj rapide helpos vin ripari ĝin, sed en la dua kazo, estas risko prokrasti la projekton aŭ malfunkcion de la finita. sistemo por nedifinita periodo.
Vi povas egaligi la kalkulkondiĉojn en tri manieroj:
- Uzu Oracle sen subteno (en realeco tio ne okazas).
- Aĉetu subtenon por PostgreSQL - ekzemple de Postgres Professional.
- Konsideru la riskojn asociitajn kun manko de subteno.
Ekzemple, riskokalkulo povus aspekti jene: en la okazaĵo de mortiga datumbazo fiasko, la sistemo malfunkcio estus 1 labortago. La projektita profito de uzado de la sistemo estas 40 miliardoj da MNT jare, la akcidenta indico estas taksita esti 1/400, tiel la risko de manko de subteno estas taksita je proksimume 100 milionoj da MNT jare. Evidente, "planita profito" kaj "taksa ofteco de akcidento" estas virtualaj valoroj, sed estas multe pli bone havi tian modelon ol ne havi.
En realeco, la sistemo povas esti tro grava por ke la reputacia kosto de longtempa malfunkcio estu neakceptebla, do subteno estos postulata. Se malfunkcio estas permesita, tiam rifuzi subtenon foje povas esti bona maniero ŝpari monon.
Ni supozu, ke post ĉiuj kalkuloj, la kosto de operaciumo A dum 5 jaroj rezultas esti 800 milionoj da MNT, la kosto de operacia platformo B estas 650 milionoj da MNT, kaj la kosto de operaciumo C estas 600 milionoj da MNT. Platformo C, kiel la gajnanto, ricevas plenan poenton por la prezo, dum platformoj A kaj B ricevas iom malpli, proporcie al kiom da fojoj ili estas pli multekostaj. En ĉi tiu kazo - 0.75 kaj 0.92 poentoj, respektive.
Takso de Ŝanco
La taksado de ŝancoj estas dividita en multajn grupojn, kies nombro estas limigita nur de la imago de la persono, kiu faras la taksadon. La optimuma opcio ŝajnas esti dividi la kapablojn en teamojn, kiuj uzos ĉi tiujn kapablojn; en nia ekzemplo, ĉi tiuj estas programistoj, administrantoj kaj informsekurecaj oficistoj. Ni supozu, ke la pezoj de ĉi tiuj funkcioj estas distribuitaj kiel 40:40:20.
Evoluaj funkcioj inkluzivas:
- facileco de manipulado de datumoj;
- grimpi;
- ĉeesto de malĉefaj indeksoj.
La listo de kriterioj, same kiel iliaj pezoj, estas tre subjektivaj. Eĉ kiam vi solvas la saman problemon, ĉi tiuj listoj, eroj pezoj kaj respondoj signife varias depende de la konsisto de via teamo. Ekzemple, Facebook uzas MySQL por stoki datumojn, kaj Instagram estas konstruita sur Cassandra. Estas neverŝajne, ke la programistoj de ĉi tiuj aplikoj plenigis tiajn tabelojn. Oni povas nur konjekti, ke Mark Zuckerberg elektis plenkreskan interrilatan modelon, pagante por ĝi kun la bezono de aplikata sharding, dum Kevin Systrom konstruis skaladon uzante la platformon, oferante facilecon de aliro al datumoj.
Administraj funkcioj inkluzivas:
- sekurkopiaj sistemo-kapabloj;
- facileco de monitorado;
- facileco de kapacita administrado - diskoj kaj nodoj;
- reproduktadkapabloj de datumoj.
Bonvolu noti, ke demandoj devas esti vortigitaj en kvanta maniero. Vi eĉ povas konsenti pri kiel taksi apartan funkcion. Ni, ekzemple, provu taksi rezervajn ilojn uzante la ekzemplon de iloj liveritaj kun la Oracle DBMS:
Ilo
komento
pritakso
imp/eksp
Alŝuto kaj ŝarĝo de datumoj
0.1
komenci/finon sekurkopion
Kopiante dosierojn
0.3
RMAN
Pliiga kopikapablo
0.7
ZDLRA
Nur pliiga kopiado, plej rapida reakiro al punkto
1.0
Se ne ekzistas klaraj pritaksaj kriterioj, estas senco peti plurajn fakulojn doni taksojn kaj poste averaĝi ilin.
Fine, ni simple listigas la funkciojn pri informa sekureco:
- havebleco de pasvortadministradaj politikoj;
- la kapablo konekti eksterajn aŭtentigajn ilojn (LDAP, Kerberos);
- rolmodelo de aliro;
- reviziaj kapabloj;
- ĉifrado de datumoj sur disko;
- ĉifrado dum transdono tra la reto (TLS);
- protekto de datumoj de la administranto.
Elfara testado
Aparte, mi ŝatus averti kontraŭ uzi la rezultojn de iuj ŝarĝaj provoj, kiuj ne estis faritaj de vi, kiel argumentojn.
Unue, la datumstrukturo kaj ŝarĝa profilo de la testataj aplikaĵoj povas signife diferenci de la problemo, kiun vi solvos. Antaŭ Ĉirkaŭ 10-15 jaroj, datumbazaj vendistoj ŝatis fanfaroni pri la rezultoj atingitaj en TPC-testoj, sed nun, ŝajnas, neniu prenas ĉi tiujn rezultojn serioze.
Due, sistema rendimento dependas sufiĉe forte de kia platformo la kodo estis origine skribita kaj de kia ekipaĵo la testo estis farita. Mi vidis multajn testojn kie Oracle estis komparita kun PostgreSQL. La rezultoj intervalas de la senkondiĉa supereco de unu sistemo ĝis la same senkondiĉa supereco de alia.
Kaj fine, trie, vi scias nenion pri kiu faris la teston. Ambaŭ kvalifikoj estas gravaj, influante la kvaliton de agordo de la OS kaj platformo, same kiel instigo, kiu influas la testrezultojn pli ol ĉiuj aliaj faktoroj kombinitaj.
Se agado estas kritika faktoro, faru la teston mem, prefere kun la helpo de homoj, kiuj agordos kaj konservos la produktadsistemon.
rezulto
Fine, la rezulto de la tuta laboro farita devus esti kalkultabelo kie ĉiuj taksoj estas kombinitaj, multoblaj kaj resumitaj:
Kiel vi komprenas, ŝanĝante la skalojn kaj ĝustigante la taksojn vi povas atingi ajnan deziratan rezulton, sed tio estas tute alia rakonto...
fonto: www.habr.com