– Det var dog utroligt, – sagde hun højt uden at henvende sig til nogen. – Det var dog utroligt! Der står rent ud skrevet – hovedopgaven for samfundet er at skabe profit til aktionærerne. Tænk over det! De er ikke bange for noget!
Juli DUBOV, 'Det mindste onde'
Når du ser en sådan overskrift, har du sikkert allerede besluttet, at artiklen er enten dumb eller provokerende. Men skynd dig ikke at konkludere: medarbejderne i store virksomheder, især de med statslige interesser, skal ofte sammenligne forskellige platforme, også helt forskellige – for eksempel som dem nævnt i overskriften.
Selvfølgelig sammenligner ingen databaser, da deres styrker og svagheder er velkendte. Som regel er det platforme, der løser en eller anden praktisk opgave, der sammenlignes. I artiklen vil jeg vise metoden, der anvendes i denne forbindelse, med eksemplet af databaser som emne, som ikke er ny for læserne af Habr. Så,
Motivation
Når du starter et skoleprojekt eller et hobbyprojekt, kan motivationen for at vælge platformen være meget forskellig: 'denne platform kender jeg bedst', 'med denne er jeg interesseret i at finde ud af mere', 'her er den bedste dokumentation'… I tilfælde af en kommerciel virksomhed er der kun ét kriterium for valg: hvor meget vil det koste, og hvad får jeg for de penge.
Det er selvfølgelig ønskeligt at betale mindre og få mere. Men det er nødvendigt at beslutte, hvad der er vigtigere – at betale mindre eller at få mere – og give hver node en vægt. Lad os antage, at vi vægter kvalitetsløsningen højere end den billige, og giver noden 'Omkostninger' en vægt på 40%, mens noden 'Muligheder' får 60%.
I store virksomheder er det normalt omvendt – vægten for omkostningerne falder sjældent under 50%, og kan måske endda være over 60%. I det hypotetiske eksempel er den vigtigste pointe, at den samlede vægt af de underordnede noder til enhver overordnet node skal være 100%.
Udelukkende betingelser
Webstedet kender omkring 500 databasestyringssystemer. Det er klart, at hvis man skal vælge en målrettet platform ud fra et så stort antal muligheder, så kan det blive til en oversigt, men ikke et kommercielt projekt. For at indsnævre valgmulighederne formuleres udelukkelseskriterier, og hvis platformen ikke opfylder disse kriterier, så overvejes den ikke.
Afspejlingskriterier kan relateres til teknologiske egenskaber, for eksempel:
- ACID-garantier;
- relationel datamodel;
- understøttelse af SQL-sprog (vær opmærksom på, at dette ikke er det samme som 'relationel model');
- mulighed for horisontal skalering.
Der kan også være generelle kriterier:
- tilgængelighed af kommerciel støtte i Danmark;
- åben kildekode;
- tilgængelighed af platformen i Ministeriet for Indenrigsanliggendes register;
- tilgængelighed af platformen i et eller andet rangering (for eksempel i top 100 på db-engines.com);
- tilgængelighed af eksperter på markedet (for eksempel baseret på resultater fra søgning efter platformens navn i CV'er på hh.dk).
Til sidst kan der være kriterier, der er specifikke for virksomheden:
- tilgængelighed af specialister i staben;
- kompatibilitet med overvågningssystem X eller backupsystem Y, som alle vedligeholdelsesopgaver afhænger af…
Det vigtigste er, at der findes en liste over afspejlingskriterier. 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 I ikke platform Z? Jeg ved, den er den bedste.'
Vurdering af omkostninger
Omkostningen ved løsningen består tydeligvis af omkostningerne ved licenser, vedligeholdelse og hardware.
Hvis systemerne er af nogenlunde samme klasse (for eksempel Microsoft SQL Server og PostgreSQL), kan man for enkelhedens skyld antage, at mængden af hardware til begge løsninger vil være nogenlunde den samme. Dette vil spare en del tid og kræfter ved ikke at vurdere hardware. Hvis derimod sammenlignes helt forskellige systemer (for eksempel Oracle vs. Redis), er det klart, at en korrekt vurdering kræver en sizing (beregning af mængden af hardware). Sizing af et ikke-eksisterende system er en ret taknemmelig opgave, så sådanne sammenligninger undgås dog stadig. Det er enkelt: i kravene skrives ingen datatab og en relationel model eller omvendt - belastning fra 50.000 transaktioner pr. sekund.
For evaluating licenses, it is sufficient to request from the vendor or its partners the cost of the license for a fixed number of cores and support for a fixed period. As a rule, companies already have established strong relationships with software vendors, and if the database operations department cannot answer the cost question independently, it is enough to send one email to obtain this information.
Different vendors may have different licensing metrics: based on the number of cores, data volume, or the number of nodes. A standby database may be free, or it may be licensed just like the primary one. If some differences in metrics are discovered, it will be necessary to describe the model stand in detail and calculate the license costs for the stand.
An important point for accurate comparison is the same support conditions. For example, Oracle support costs 22% of the license price per year, while PostgreSQL support can be free. Is it correct to compare this way? No, because errors that cannot be resolved by oneself have completely different consequences: in the first case, support specialists will quickly help resolve it, while in the second case, there is a risk of project delays or the system being idle for an indefinite period.
There are three ways to equalize the calculation conditions:
- Use Oracle without support (which is not really possible in reality).
- Purchase support for PostgreSQL – for example, from Postgres Professional.
- Factor in the risks associated with the lack of support.
For example, the risk calculation might look like this: in case of an unresolvable database failure, the downtime of the system will be 1 working day. The projected profit from using the system is 40 billion Mongolian tugriks per year, and the failure frequency is estimated at 1/400; thus, the risk of lacking support is approximately 100 million Mongolian tugriks per year. Clearly, the 'projected profit' and 'estimated failure frequency' are virtual quantities, but it is much better to have such a model than to have none.
I virkeligheden kan systemet være for vigtigt, og tab af omdømme fra langvarig nedetid vil være uacceptabelt, så support er nødvendig. Hvis nedetid er acceptabel, kan afvisning af support nogle gange være en god måde at spare penge på.
Lad os antage, at efter alle beregninger viste omkostningerne ved at drifte platform A i 5 år sig at være 800 millioner mongolske tugrik, omkostningerne ved platform B – 650 millioner tugrik, og omkostningerne ved platform C – 600 millioner tugrik. Platform C, som vinder, får et fuldt point for omkostningerne, mens platformerne A og B får lidt mindre, proportionelt med hvor meget dyrere de er. I dette tilfælde – 0,75 og 0,92 point henholdsvis.
Vurdering af muligheder
Vurderingen af muligheder deles op i mange grupper, hvis antal kun er begrænset af den, der laver vurderingen. Den optimale løsning synes at være at opdele mulighederne efter de teams, der vil bruge dem; i vores eksempel er det udviklere, administratorer og informationssikkerhedsofficerer. Lad os antage, at vægtene af disse funktioner fordeles som 40:40:20.
Udviklingsfunktioner kan omfatte:
- brugervenlig manipulation af data;
- skalerbarhed;
- tilgængelighed af sekundære indekser.
Listen over kriterier, ligesom deres vægte, er meget subjektiv. Selv ved løsning af den samme opgave vil disse lister, vægtning af punkter og svar variere betydeligt afhængigt af sammensætningen af dit team. For eksempel bruger Facebook MySQL til datalagring, mens Instagram er bygget på Cassandra. Det er usandsynligt, at udviklerne af disse applikationer har udfyldt sådanne tabeller. Man kan kun gætte på, at Mark Zuckerberg valgte en fuldgyldig relationel model, hvilket medførte behovet for anvendt sharding, mens Kevin Systrom indlagde skalerbarhed gennem platformen, på bekostning af brugervenlighed i datatilgang.
Administrationsfunktioner inkluderer:
- backup-systemmuligheder;
- brugervenlig overvågning;
- brugervenlig styring af ressourcer – diske og noder;
- muligheder for datareplication.
Bemærk, at spørgsmålene skal kunne kvantitativt vurderes. Man kan endda blive enige om, hvordan man vurderer en bestemt funktion. Lad os for eksempel prøve at give karakterer til backupværktøjer på baggrund af de værktøjer, der leveres med Oracle-databaseadministrationssystemet:
Værktøj
Kommentar
Vurdering
imp/exp
Eksport og import af data
0.1
begin/end backup
Filkopiering
0.3
RMAN
Mulighed for inkrementel sikkerhedskopi
0.7
ZDLRA
Kun inkrementel sikkerhedskopi, hurtigere gendannelse til punkt
1.0
Hvis der ikke er klare vurderingskriterier, kan det give mening at bede flere eksperter om at give vurderinger og derefter beregne gennemsnittet.
Endelig lad os blot opregne funktionerne i informationssikkerhed:
- tilstedeværelse af politikker for adgangskoder;
- mulighed for tilslutning af eksterne autentificeringsmidler (LDAP, Kerberos);
- rollebaseret adgangsmodel;
- auditmuligheder;
- kryptering af data på disk;
- kryptering under transmission over netværket (TLS);
- beskyttelse af data mod administratoren.
Skrivehastighed for beskeder på 1KB med 9 producenter samtidigt — 1300000 begivenheder i sekundet.
Jeg vil gerne advare mod at bruge resultaterne fra eventuelle belastningstest, som ikke er udført af dig.
For det første kan datastukturen og profilspecifikationerne for de testede applikationer adskille sig betydeligt fra den opgave, du har tænkt dig at løse. For 10-15 år siden kunne databaseproducenter godt lide at prale med resultaterne fra TPC-tests, men nu virker det til, at ingen tager disse resultater alvorligt.
For det andet afhænger systemets ydeevne meget af, hvilken platform koden oprindeligt blev skrevet til, og hvilket udstyr testen blev udført på. Jeg har set mange tests, hvor Oracle blev sammenlignet med PostgreSQL. Resultaterne spænder fra uafhængigt overlegenhed af det ene system til lige så uafhængig overlegenhed af det andet.
Og endelig, for det tredje, ved du ikke, hvem der har udført testen. Både kvalifikationen, der påvirker kvaliteten af OS- og platformkonfigurationen, og motivationen, der påvirker testresultaterne mere end alle andre faktorer tilsammen, er vigtige.
Hvis ydeevne er en kritisk faktor, så udfør testen selv, helst med deltagelse af specialister, der skal konfigurere og vedligeholde et industrielt system.
Resultat
Endelig skal resultatet af det udførte arbejde være et regneark, hvor alle vurderinger er opsummeret, multipliceret og adderet:
Som du forstår, kan ændring af vægte og justering af vurderinger give ethvert ønsket resultat, men det er en helt anden historie…
Kilde: habr.com
