"Detta är nödvändigt," sa hon högt och vände sig inte till någon. – Det här är nödvändigt! Det är precis vad det står: ett företags huvuduppgift är att göra vinst i aktieägarnas intresse. Nåväl, tänk på det! De är inte rädda för någonting!
Yuliy Dubov, "Lesser Evil"
Efter att ha sett en sådan rubrik har du säkert redan bestämt dig för att artikeln antingen är dumhet eller en provokation. Men skynda dig inte att dra slutsatser: anställda i stora företag, särskilt företag med statligt deltagande, måste ganska ofta jämföra olika plattformar, inklusive helt olika - till exempel de i titeln.
Naturligtvis är det ingen som jämför DBMS på detta sätt, eftersom deras styrkor och svagheter är välkända. Som regel är plattformar som löser vissa applikationsproblem föremål för jämförelse. I artikeln kommer jag att visa metodiken som används i detta fall, med hjälp av exemplet med databaser som ett ämne som är bekant för Habr-läsare från första hand. Så,
Motivation
När du startar ett utbildningsprojekt eller ett hobbyprojekt kan motivationen för att välja en plattform vara väldigt varierande: "det här är den plattform jag känner bäst", "Jag är intresserad av att förstå den här", "här är den bästa dokumentationen" ... När det gäller ett kommersiellt företag är urvalskriteriet detsamma: hur mycket måste jag betala och vad får jag för dessa pengar.
Naturligtvis vill du betala mindre och få mer. Du måste dock bestämma vad som är viktigare - att betala mindre eller få mer, och tilldela en vikt till varje nod. Låt oss anta att en högkvalitativ lösning är viktigare för oss än en billig, och vi tilldelar noden "Kostnad" en vikt på 40 % och 60 % till noden "Möjligheter".
I stora företag är det vanligtvis tvärtom - kostnadsvikten faller inte under 50 %, och kanske mer än 60 %. I modellexemplet är allt som är viktigt att den totala vikten av de underordnade noderna för en överordnad nod måste vara 100 %.
Avskärningsvillkor
Webbplats Det finns cirka 500 databashanteringssystem kända. Naturligtvis, om du väljer en målplattform från så många alternativ, kan du sluta med en recensionsartikel, men inte ett kommersiellt projekt. För att minska valutrymmet formuleras cut-off-kriterier och om plattformen inte uppfyller dessa kriterier så beaktas den inte.
Avgränsningskriterier kan relatera till tekniska egenskaper, till exempel:
- SYRA-garantier;
- relationsdatamodell;
- SQL-språkstöd (observera att detta inte är detsamma som "relationsmodellen");
- möjlighet till horisontell skalning.
Det kan finnas allmänna kriterier:
- tillgång till kommersiellt stöd i Ryssland;
- öppen källa;
- tillgängligheten av plattformen i registret för ministeriet för telekom och masskommunikation;
- närvaron av plattformen i vissa betyg (till exempel i de första hundra av db-engines.com-betyget);
- närvaron av experter på marknaden (till exempel baserat på resultaten av att söka efter namnet på plattformen i ett CV på webbplatsen hh.ru).
När allt kommer omkring kan det finnas företagsspecifika kriterier:
- tillgång till specialister på personal;
- kompatibilitet med övervakningssystem X eller backupsystem Y, på vilket allt stöd är baserat...
Det viktigaste är att det finns en lista med cut-off kriterier. Annars kommer det definitivt att finnas någon expert (eller "expert") som åtnjuter särskilt förtroende från ledningen som kommer att säga "varför valde du inte plattform Z, jag vet att den är den bästa."
Kostnadsberäkning
Kostnaden för lösningen består självklart av kostnaden för licenser, kostnaden för support och kostnaden för utrustning.
Om systemen är ungefär samma klass (till exempel Microsoft SQL Server och PostgreSQL) så kan vi för enkelhetens skull anta att mängden utrustning för båda lösningarna blir ungefär densamma. Detta gör att du inte kan utvärdera utrustningen, vilket sparar mycket tid och ansträngning. Om man ska jämföra helt olika system (säg Oracle vs Redis) så är det uppenbart att för en korrekt bedömning är det nödvändigt att göra dimensionering (beräkning av mängden utrustning). Att dimensionera ett icke-existerande system är en mycket otacksam uppgift, så de försöker ändå undvika sådana jämförelser. Detta är lätt att göra: under avgränsningsförhållandena skrivs noll dataförlust och en relationsmodell, eller vice versa - en belastning på 50 tusen transaktioner per sekund.
För att utvärdera licenser räcker det att fråga leverantören eller dess partners om kostnaden för en licens för ett fast antal kärnor och support under en bestämd period. Som regel har företag redan starka relationer med mjukvaruleverantörer, och om databasdriftsavdelningen inte kan svara på kostnadsfrågan på egen hand, räcker det med en bokstav för att få denna information.
Olika leverantörer kan ha olika licensmätningar: efter antal kärnor, datavolym eller antal noder. Standbybasen kan vara gratis, eller så kan den licensieras på samma sätt som huvudbasen. Om några skillnader i mått upptäcks måste du beskriva modellmontern i detalj och beräkna kostnaden för licenser för montern.
En viktig poäng för en korrekt jämförelse är samma stödvillkor. Till exempel kostar Oracle-support 22 % av licenspriset per år, men du behöver inte betala för PostgreSQL-support. Är det korrekt att jämföra så här? Nej, eftersom ett fel som inte kan åtgärdas på egen hand har helt andra konsekvenser: i det första fallet hjälper supportspecialister dig snabbt att fixa det, men i det andra fallet finns det risk för att försena projektet eller driftstopp för det färdiga systemet på obestämd tid.
Du kan utjämna beräkningsvillkoren på tre sätt:
- Använd Oracle utan support (i verkligheten händer det inte).
- Köp support för PostgreSQL – till exempel från Postgres Professional.
- Ta hänsyn till riskerna med bristande stöd.
Till exempel kan en riskberäkning se ut så här: i händelse av ett fatalt databasfel skulle systemets driftstopp vara 1 arbetsdag. Den beräknade vinsten från att använda systemet är 40 miljarder MNT per år, olycksfrekvensen uppskattas till 1/400, därmed uppskattas risken för bristande stöd till cirka 100 miljoner MNT per år. Uppenbarligen är ”planerad vinst” och ”beräknad olycksfrekvens” virtuella värden, men det är mycket bättre att ha en sådan modell än att inte ha någon.
I verkligheten kan systemet vara för viktigt för att anseendekostnaden för långvarig driftstopp ska vara oacceptabel, så support kommer att krävas. Om driftstopp tillåts kan det ibland vara ett bra sätt att spara pengar att tacka nej till support.
Låt oss anta att efter alla beräkningar visar sig kostnaden för att driva plattform A under 5 år vara 800 miljoner MNT, kostnaden för att driva plattform B är 650 miljoner MNT och kostnaden för att driva plattform C är 600 miljoner MNT. Plattform C, som vinnare, får en hel poäng för priset, medan plattformar A och B får lite mindre, i proportion till hur många gånger de är dyrare. I det här fallet – 0.75 respektive 0.92 poäng.
Möjlighet bedömning
Bedömningen av möjligheter är uppdelad i många grupper, vars antal begränsas endast av fantasin hos den som gör bedömningen. Det optimala alternativet verkar vara att dela upp förmågorna i team som kommer att använda dessa förmågor; i vårt exempel är dessa utvecklare, administratörer och informationssäkerhetsansvariga. Låt oss anta att vikterna för dessa funktioner är fördelade som 40:40:20.
Utvecklingsfunktioner inkluderar:
- enkel datamanipulering;
- skalning;
- förekomst av sekundära index.
Listan över kriterier, liksom deras vikter, är mycket subjektiva. Även när man löser samma problem, kommer dessa listor, objektvikter och svar att variera avsevärt beroende på sammansättningen av ditt team. Till exempel använder Facebook MySQL för att lagra data, och Instagram är byggt på Cassandra. Det är osannolikt att utvecklarna av dessa applikationer fyllde i sådana tabeller. Man kan bara gissa att Mark Zuckerberg valde en fullfjädrad relationsmodell och betalade för den med behovet av tillämpad sharding, medan Kevin Systrom byggde skalning med hjälp av plattformen och offrade enkel åtkomst till data.
Administrationsfunktioner inkluderar:
- kapacitet för säkerhetskopieringssystem;
- enkel övervakning;
- enkel kapacitetshantering - diskar och noder;
- datareplikeringsmöjligheter.
Observera att frågor måste formuleras på ett kvantitativt sätt. Du kan till och med komma överens om hur du ska utvärdera en viss funktion. Låt oss till exempel försöka betygsätta säkerhetskopieringsverktyg med hjälp av exemplet på verktyg som levereras med Oracle DBMS:
Verktyg
Kommentar
Utvärdering
imp/exp
Ladda upp och ladda data
0.1
starta/sluta säkerhetskopiering
Kopiera filer
0.3
RMAN
Inkrementell kopieringsmöjlighet
0.7
ZDLRA
Endast inkrementell kopiering, snabbaste återställning till punkt
1.0
Om det inte finns några tydliga utvärderingskriterier är det vettigt att be flera experter att ge betyg och sedan ta ett medelvärde.
Slutligen listar vi helt enkelt informationssäkerhetsfunktionerna:
- tillgänglighet av policyer för lösenordshantering;
- möjligheten att ansluta externa autentiseringsverktyg (LDAP, Kerberos);
- förebild för tillgång;
- revisionsförmåga;
- kryptering av data på disk;
- kryptering under överföring över nätverket (TLS);
- dataskydd från administratören.
Prestandatester
Separat vill jag varna för att använda resultaten av eventuella belastningstester som inte gjorts av dig som argument.
För det första kan datastrukturen och belastningsprofilen för de applikationer som testas skilja sig betydligt från det problem du ska lösa. För ungefär 10-15 år sedan älskade databasleverantörer att visa upp de resultat som uppnåddes i TPC-tester, men nu verkar det som om ingen tar dessa resultat på allvar.
För det andra beror systemets prestanda ganska starkt på vilken plattform koden ursprungligen skrevs för och på vilken utrustning testet utfördes. Jag har sett många tester där Oracle jämfördes med PostgreSQL. Resultaten sträcker sig från ett systems ovillkorliga överlägsenhet till ett annats lika ovillkorliga överlägsenhet.
Och slutligen, för det tredje, du vet ingenting om vem som gjorde testet. Båda kvalifikationerna är viktiga, de påverkar kvaliteten på installationen av operativsystemet och plattformen, samt motivationen, vilket påverkar testresultaten mer än alla andra faktorer tillsammans.
Om prestanda är en kritisk faktor, genomför testet själv, helst med hjälp av de personer som ska konfigurera och underhålla produktionssystemet.
Resultat
Slutligen bör resultatet av allt arbete vara ett kalkylblad där alla uppskattningar kombineras, multipliceras och summeras:
Som du förstår kan du uppnå vilket resultat du vill genom att ändra skalorna och justera betygen, men det är en helt annan historia...
Källa: will.com