"Det her er nødvendigt," sagde hun højt og henvendte sig ikke til nogen. - Det er nødvendigt! Det er præcis, hvad der står: en virksomheds hovedopgave er at skabe overskud i aktionærernes interesse. Tænk over det! De er ikke bange for noget!
Yuliy Dubov, "Lesser Evil"
Efter at have set sådan en overskrift, har du sikkert allerede besluttet, at artiklen enten er dumhed eller en provokation. Men skynd dig ikke med konklusioner: ansatte i store virksomheder, især virksomheder med statsdeltagelse, skal ganske ofte sammenligne forskellige platforme, inklusive helt forskellige - for eksempel dem i titlen.
Selvfølgelig er der ingen, der sammenligner DBMS'er på denne måde, fordi deres styrker og svagheder er velkendte. Som regel er platforme, der løser nogle applikationsproblemer, genstand for sammenligning. I artiklen vil jeg vise den metode, der bruges i dette tilfælde, ved at bruge eksemplet med databaser som et emne, der er velkendt for Habr-læsere. Så,
Motivation
Når du starter et uddannelsesprojekt eller et hobbyprojekt, kan motivationen for at vælge en platform være meget forskelligartet: "det er den platform, jeg kender bedst", "Jeg er interesseret i at forstå denne", "her er den bedste dokumentation" ... I tilfælde af en kommerciel virksomhed er udvælgelseskriteriet det samme: hvor meget skal jeg betale, og hvad får jeg for disse penge.
Naturligvis vil du betale mindre og få mere. Du skal dog beslutte, hvad der er vigtigere - at betale mindre eller få mere, og tildele en vægt til hver node. Lad os antage, at en højkvalitetsløsning er vigtigere for os end en billig, og vi tildeler en vægt på 40% til "Cost"-knuden og 60% til "Opportunities"-knuden.
I store selskaber er det modsatte normalt tilfældet - omkostningsvægten falder ikke under 50%, og måske mere end 60%. I modeleksemplet er alt, hvad der er vigtigt, at den samlede vægt af de underordnede noder af enhver overordnet node skal være 100 %.
Afskæringsbetingelser
Internet side Der er omkring 500 databasestyringssystemer kendt. Hvis du vælger en målplatform blandt så mange muligheder, kan du naturligvis ende med en anmeldelsesartikel, men ikke et kommercielt projekt. For at reducere valgpladsen formuleres afskæringskriterier, og hvis platformen ikke opfylder disse kriterier, så tages den ikke i betragtning.
Afskæringskriterier kan relatere til teknologiske funktioner, for eksempel:
- SYRE-garantier;
- relationel datamodel;
- SQL-sprogunderstøttelse (bemærk, dette er ikke det samme som "relationsmodellen");
- mulighed for horisontal skalering.
Der kan være generelle kriterier:
- tilgængelighed af kommerciel støtte i Rusland;
- åben kildekode;
- tilgængeligheden af platformen i registeret for ministeriet for telekommunikation og massekommunikation;
- tilstedeværelse af platformen i en eller anden rating (for eksempel i de første hundrede af db-engines.com-vurderingen);
- tilstedeværelsen af eksperter på markedet (for eksempel baseret på resultaterne af at søge efter navnet på platformen i et CV på webstedet hh.ru).
Der kan trods alt være virksomhedsspecifikke kriterier:
- tilgængelighed af specialister på personale;
- kompatibilitet med overvågningssystem X eller backupsystem Y, som al support er baseret på...
Det vigtigste er, at der er en liste over afskæringskriterier. Ellers vil der helt sikkert være en eller anden ekspert (eller "ekspert"), der nyder særlig tillid fra ledelsen, som vil sige "hvorfor valgte du ikke platform Z, jeg ved, det er den bedste."
Estimerede omkostninger
Omkostningerne ved løsningen består naturligvis af omkostningerne til licenser, omkostningerne til support og omkostningerne til udstyr.
Hvis systemerne er nogenlunde samme klasse (f.eks. Microsoft SQL Server og PostgreSQL), så kan vi for nemheds skyld antage, at mængden af udstyr til begge løsninger vil være nogenlunde den samme. Dette giver dig mulighed for ikke at evaluere udstyret, hvilket sparer en masse tid og kræfter. Hvis man skal sammenligne helt forskellige systemer (f.eks. Oracle vs. Redis), så er det oplagt, at det for en korrekt vurdering er nødvendigt at lave dimensionering (beregning af udstyrsmængden). At dimensionere et ikke-eksisterende system er en meget utaknemmelig opgave, så de forsøger stadig at undgå sådanne sammenligninger. Dette er nemt at gøre: i afskæringsbetingelserne skrives nul datatab og en relationel model, eller omvendt - en belastning på 50 tusinde transaktioner i sekundet.
For at evaluere licenser er det nok at spørge leverandøren eller dennes partnere om omkostningerne ved en licens for et fast antal kerner og support i en fast periode. Som regel har virksomheder allerede stærke relationer til softwareleverandører, og hvis databasedriftsafdelingen ikke kan besvare omkostningsspørgsmålet alene, så er ét bogstav nok til at få disse oplysninger.
Forskellige leverandører kan have forskellige licensmålinger: efter antal kerner, datavolumen eller antal noder. Standbybasen kan være gratis, eller den kan licenseres på samme måde som den primære. Hvis der opdages forskelle i metrik, skal du beskrive modelstanden i detaljer og beregne omkostningerne ved licenser til standen.
En vigtig pointe for en korrekt sammenligning er de samme støttebetingelser. For eksempel koster Oracle-support 22% af licensprisen om året, men du skal ikke betale for PostgreSQL-support. Er det korrekt at sammenligne sådan? Nej, fordi en fejl, der ikke kan rettes på egen hånd, har helt andre konsekvenser: i det første tilfælde vil supportspecialister hurtigt hjælpe dig med at rette det, men i det andet tilfælde er der risiko for at forsinke projektet eller nedetid for det færdige system på ubestemt tid.
Du kan udligne beregningsbetingelserne på tre måder:
- Brug Oracle uden support (i virkeligheden sker dette ikke).
- Køb support til PostgreSQL - for eksempel fra Postgres Professional.
- Tag højde for de risici, der er forbundet med manglende støtte.
For eksempel kan en risikoberegning se sådan ud: I tilfælde af en fatal databasefejl vil systemets nedetid være 1 hverdag. Det forventede overskud ved at bruge systemet er 40 milliarder MNT om året, ulykkesraten er estimeret til at være 1/400, således er risikoen for manglende støtte estimeret til cirka 100 millioner MNT om året. Det er klart, at "planlagt fortjeneste" og "estimeret ulykkesfrekvens" er virtuelle værdier, men det er meget bedre at have sådan en model end ikke at have nogen.
I virkeligheden kan systemet være for vigtigt til, at omdømmeomkostningerne ved langvarig nedetid er uacceptabel, så der vil være behov for support. Hvis nedetid er tilladt, kan det nogle gange være en god måde at spare penge på at nægte support.
Lad os antage, at efter alle beregningerne viser omkostningerne ved driften af platform A i 5 år at være 800 millioner MNT, omkostningerne ved driften af platform B er 650 millioner MNT, og omkostningerne ved driften af platform C er 600 millioner MNT. Platform C får som vinder et fuldt point for prisen, mens platform A og B får lidt mindre, i forhold til hvor mange gange de er dyrere. I dette tilfælde – henholdsvis 0.75 og 0.92 point.
Mulighedsvurdering
Vurderingen af muligheder er opdelt i mange grupper, hvis antal kun er begrænset af fantasien hos den person, der foretager vurderingen. Den optimale mulighed synes at være at opdele kapaciteterne i teams, der vil bruge disse kapaciteter; i vores eksempel er disse udviklere, administratorer og informationssikkerhedsansvarlige. Lad os antage, at vægten af disse funktioner er fordelt som 40:40:20.
Udviklingsfunktioner omfatter:
- let datamanipulation;
- skalering;
- tilstedeværelse af sekundære indekser.
Listen over kriterier, såvel som deres vægt, er meget subjektive. Selv når du løser det samme problem, vil disse lister, emnevægte og svar variere betydeligt afhængigt af sammensætningen af dit team. For eksempel bruger Facebook MySQL til at gemme data, og Instagram er bygget på Cassandra. Det er usandsynligt, at udviklerne af disse applikationer udfyldte sådanne tabeller. Man kan kun gætte på, at Mark Zuckerberg valgte en fuldgyldig relationel model, der betalte for den med behovet for anvendt sharding, mens Kevin Systrom byggede skalering ved hjælp af platformen og ofrede let adgang til data.
Administrationsfunktioner omfatter:
- backup system kapaciteter;
- let overvågning;
- let kapacitetsstyring - diske og noder;
- datareplikeringsmuligheder.
Bemærk venligst, at spørgsmål skal formuleres på en kvantitativ måde. I kan endda blive enige om, hvordan man vurderer en bestemt funktion. Lad os for eksempel prøve at bedømme sikkerhedskopieringsværktøjer ved at bruge eksemplet på værktøjer, der leveres med Oracle DBMS:
Tool
Kommentar
Evaluering
imp/exp
Upload og indlæsning af data
0.1
start/slut backup
Kopiering af filer
0.3
RMAN
Inkrementel kopifunktion
0.7
ZDLRA
Kun trinvis kopiering, hurtigste gendannelse til punkt
1.0
Hvis der ikke er klare evalueringskriterier, er det fornuftigt at bede flere eksperter om at give vurderinger og derefter tage et gennemsnit af dem.
Til sidst lister vi blot informationssikkerhedsfunktionerne:
- tilgængelighed af adgangskodestyringspolitikker;
- evnen til at forbinde eksterne autentificeringsværktøjer (LDAP, Kerberos);
- rollemodel for adgang;
- revision kapaciteter;
- kryptering af data på disk;
- kryptering under transmission over netværket (TLS);
- databeskyttelse fra administratoren.
Præstationstest
Separat vil jeg gerne advare mod at bruge resultaterne af belastningstest, som ikke er lavet af dig, som argumenter.
For det første kan datastrukturen og belastningsprofilen for de applikationer, der testes, afvige væsentligt fra det problem, du skal løse. For omkring 10-15 år siden elskede databaseleverandører at fremvise de opnåede resultater i TPC-tests, men nu ser det ud til, at ingen tager disse resultater alvorligt.
For det andet afhænger systemets ydeevne ret stærkt af, hvilken platform koden oprindeligt blev skrevet til, og af hvilket udstyr testen blev udført. Jeg har set mange test, hvor Oracle blev sammenlignet med PostgreSQL. Resultaterne spænder fra et systems ubetingede overlegenhed til et andets lige så ubetingede overlegenhed.
Og endelig, for det tredje, ved du ikke noget om, hvem der har lavet testen. Begge kvalifikationer er vigtige, hvilket påvirker kvaliteten af opsætning af OS og platform, samt motivation, som påvirker testresultaterne mere end alle andre faktorer tilsammen.
Hvis ydeevne er en kritisk faktor, så udfør testen selv, helst med hjælp fra de personer, der skal konfigurere og vedligeholde produktionssystemet.
Outcome
Endelig bør resultatet af alt det udførte arbejde være et regneark, hvor alle estimaterne kombineres, ganges og summeres:
Som du forstår, kan du ved at ændre skalaerne og justere vurderingerne opnå ethvert ønsket resultat, men det er en helt anden historie...
Kilde: www.habr.com
