Vad är bäst – Oracle eller Redis eller Hur man motiverar plattformsvalet

– Det är ju fantastiskt, – sa hon högt utan att vända sig till någon. – Det är ju fantastiskt! Det står ju där klart och tydligt – det främsta syftet med samhället är att generera vinst i aktieägarnas intresse. Tänk efter! De har inga rädslor!

Julij Dubov, "Det minsta ondskan"

När du ser en sådan rubrik har du säkert redan beslutat att artikeln är antingen dum eller provokativ. Men skynda dig inte att döma: anställda på stora bolag, särskilt statligt ägda företag, tvingas ganska ofta jämföra olika plattformar, inklusive helt olika sådana – som de som nämns i rubriken.

Självklart jämförs databashanteringssystem sällan, eftersom deras styrkor och svagheter är välkända. Vanligtvis är det plattformar som löser en viss tillämpning som går till jämförelse. I artikeln kommer jag att visa metoden som används, genom exemplet av databaser, som läsarna på Habr säkert känner till. Så,

Motivation

När du startar ett utbildningsprojekt eller ett hobbyprojekt kan motivationen till val av plattform vara mycket varierande: "den här plattformen känner jag till bäst", "jag vill lära mig mer om denna", "här finns den bästa dokumentationen"... I ett kommersiellt företag är kriteriet för val ett: hur mycket jag måste betala och vad jag får för pengarna.

Självklart vill man betala mindre och få mer. Men man måste bestämma vad som är viktigast – att betala mindre eller att få mer, och tilldela varje nod en vikt. Anta att vi värderar en kvalitativ lösning högre än en billig, och vi ger noden "Kostnad" vikten 40%, medan noden "Möjligheter" får 60%.

I stora företag är det oftast tvärtom – kostnadsvikten sjunker sällan under 50%, och kan vara mer än 60%. I det modellfall som presenteras är det viktigt att den sammanlagda vikten av underordnade noder till vilken som helst överordnad nod alltid måste vara 100%.

Uteslutande kriterier

The website db-engines.com det finns cirka 500 databashanteringssystem. Självklart, om man väljer en målplattform bland så många alternativ kan man få en översiktsartikel, men inte ett kommersiellt projekt. För att minska urvalet formuleras uteslutande kriterier, och om en plattform inte uppfyller dessa kriterier, betrakta den inte.

Uteslutande kriterier kan relatera till teknologiska egenskaper, till exempel:

• ACID-garantier;
• relationsdatamodell;
• stöd för SQL-språk (observera, detta är inte samma sak som 'relationsmodell');
• möjlighet till horisontell skalning.

Det kan finnas allmänna kriterier:

• tillgång till kommersiellt stöd i Sverige;
• öppen källkod;
• plattformens närvaro i registren från Min Kommunikation;
• plattformens rang i något betyg (till exempel bland de första hundra på db-engines.com);
• tillgång till experter på marknaden (till exempel baserat på sökresultat för plattformens namn i CV:n på hh.ru).

Slutligen kan det finnas kriterier som är specifika för företaget:

• tillgång till personal med nödvändig kompetens;
• kompatibilitet med övervakningssystem X eller backup-system Y, som allt stöd är kopplat till...

Det viktigaste är att det finns en lista med avsnittskriterier. Annars kommer det alltid att finnas någon expert (eller 'expert') som åtnjuter särskilt förtroende från ledningen, som säger 'varför valde ni inte plattform Z, jag vet att den är bäst'.

Kostnadsbedömning

Kostnaden för lösningen består tydligt av kostnaden för licenser, kostnaden för stöd och kostnaden för utrustning.

Om systemen är av ungefär samma klass (till exempel Microsoft SQL Server och PostgreSQL), kan man för enkelhetens skull anta att mängden utrustning för båda lösningarna kommer att vara ungefär densamma. Detta gör att man kan undvika att bedöma utrustning, vilket sparar en massa tid och arbete. Men när man jämför helt olika system (säg Oracle vs. Redis), är det uppenbart att en noggrann bedömning kräver en sizing (beräkning av mängden utrustning). Att göra en sizing av ett icke-existerande system är en ganska otacksam uppgift, så man försöker undvika sådana jämförelser. Det är enkelt att skriva: i avsnittskriterierna anges noll dataförlust och relationsmodell, eller omvänt - en belastning av 50 000 transaktioner per sekund.

För att bedöma licenser räcker det att begära priset för en licens för ett fast antal kärnor och support under en fast tidsperiod från leverantören eller deras partners. I allmänhet har företagen redan etablerade goda relationer med mjukvaruleverantörerna, och om DB-driftsavdelningen inte kan svara på kostnadsfrågan själva, räcker det med ett enda mail för att få fram denna information.

Olika leverantörer kan ha olika licensieringsmetoder: baserat på antal kärnor, datavolym eller antal noder. En standby-databas kan vara gratis, eller så kan den licensieras på samma sätt som den primära. Om det upptäcks några skillnader i metoderna måste den modellstand som används beskrivas i detalj och kostnaden för licenserna beräknas för denna stånd.

En viktig punkt för en korrekt jämförelse är att ha samma villkor för support. Låt oss säga att Oracle-support kostar 22% av licenspriset per år, medan PostgreSQL-support kan vara kostnadsfri. Är det korrekt att jämföra på detta sätt? Nej, eftersom konsekvenserna av ett fel som inte kan lösas av interna resurser är helt olika: i det första fallet kommer support-specialister snabbt att hjälpa till att åtgärda det, medan det i det andra fallet finns en risk för förseningar i projektet eller driftstillestånd för det färdiga systemet under en obestämd tid.

Villkoren för beräkningen kan likställas på tre sätt:

1. Använda Oracle utan support ( vilket i praktiken aldrig förekommer).
2. Köpa support för PostgreSQL – exempelvis från företaget Postgres Professional.
3. Inkludera de risker som är kopplade till avsaknaden av support i beräkningarna.

Till exempel kan riskberäkningarna se ut så här: vid ett oförutsägbart databaskollaps beräknas driftstoppet för systemet bli 1 arbetsdag. Den planerade vinsten från att använda systemet är 40 miljarder mongoliska tugrik per år, och frekvensen av incidenter bedöms till 1/400, därför beräknas riskerna utan support till cirka 100 miljoner mongoliska tugrik per år. Det är uppenbart att "planerad vinst" och "bedömd incidentfrekvens" är 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, och de reputationsförluster som orsakas av långvariga driftstopp kan vara oacceptabla, så support kommer att behövas. Om driftstopp är acceptabelt, kan avstående från support ibland vara ett bra sätt att spara kostnader.

Anta att efter alla beräkningar kostnaden för att driva plattform A under 5 år är 800 miljoner mongoliska tugrik, kostnaden för plattform B är 650 miljoner tugrik, och kostnaden för plattform C är 600 miljoner tugrik. Plattform C får som vinnare ett fullt poäng för kostnaden, medan plattformarna A och B får något lägre poäng, proportionerligt mot hur mycket dyrare de är. I det här fallet – 0,75 och 0,92 poäng respektive.

Bedömning av möjligheter

Bedömning av möjligheter delas in i många grupper, vars antal endast begränsas av fantasien hos den som gör bedömningen. En optimal metod verkar vara att dela möjligheterna efter de team som kommer att använda dem; i vårt exempel är detta utvecklare, administratörer och informationssäkerhetstjänstemän. Anta att vikterna för dessa funktioner fördelas som 40:40:20.

Funktioner relaterade till utveckling inkluderar:

• användarvänlighet vid datamanipulering;
• skalbarhet;
• tillgång till sekundära index.

Listan över kriterier, liksom deras vikter, är mycket subjektiv. Även vid lösning av samma uppgift kommer dessa listor, vikterna för punkterna och svaren att skilja sig avsevärt beroende på sammansättningen av ditt team. Så till exempel använder Facebook MySQL för datalagring, medan Instagram byggs på Cassandra. Det är osannolikt att utvecklarna av dessa program fyllde i sådana tabeller. Man kan bara gissa att Mark Zuckerberg valde en fullständig relationsmodell, och betalade för det med behovet av applikationssharding, medan Kevin Systrom byggde in skalbarhet genom plattformen och offrade bekvämligheten av datatillgång.

Funktioner relaterade till administration inkluderar:

• möjligheter för systembackup;
• användarvänlighet vid övervakning;
• användarvänlighet vid hantering av resurser – diskar och noder;
• möjligheter för dat replication.

Observera att frågeställningarna måste möjliggöra en kvantitativ bedömning. Man kan till och med komma överens om hur man utvärderar en viss funktion. Låt oss till exempel försöka ge betyg åt säkerhetskopieringsverktyg med hjälp av verktyg som tillhandahålls med Oracle-databashanteraren:

Verktyget
Kommentar
Utvärdering

imp/exp
Export och import av data
0.1

börja/sluta backup
Filkopiering
0.3

RMAN
Möjlighet till inkrementell kopiering
0.7

ZDLRA
Endast inkrementell kopiering, snabbaste återställning till en punkt
1.0

Om tydliga bedömningskriterier saknas kan det vara bra att be några experter ge betyg och sedan ta ett genomsnitt.

Till sist, låt oss helt enkelt lista funktionerna för informationssäkerhet:

• existerande policyer för lösenordshantering;
• möjlighet att ansluta externa autentiseringsmedel (LDAP, Kerberos);
• rollbaserad åtkomstmodell;
• revisionsmöjligheter;
• kryptering av data på disk;
• kryptering vid överföring över nätverket (TLS);
• skydd av data från administratören.

Prestandatestning

Separat vill jag varna för att använda resultaten av några stress tester som utförts av någon annan som argument.

För det första kan databasstrukturen och belastningsprofilen för de testade applikationerna skilja sig avsevärt från den uppgift du planerar att lösa. För 10-15 år sedan brukade databasleverantörerna skryta med resultat från TPC-tester, men nu verkar det som om ingen tar dessa resultat på allvar.

För det andra beror systemets prestanda starkt på vilken plattform koden ursprungligen skrivits för och vilken hårdvara testen genomfördes på. Jag har sett många tester där Oracle jämfördes med PostgreSQL. Resultaten varierade från total överlägsenhet för det ena systemet till samma överlägsenhet för det andra.

Och slutligen, för det tredje vet du ingenting om vem som utförde testet. Både kvalifikationen, som påverkar kvaliteten på OS- och plattformsinställningarna, och motivationen, som påverkar testresultaten starkare än alla andra faktorer tillsammans, är viktiga.

Om prestanda är en kritiskt viktig faktor, genomför testet själv, helst med hjälp av specialister som kommer att ställa in och underhålla det industriella systemet.

Resultat

Slutligen ska resultatet av allt arbete vara ett kalkylblad där alla betyg har sammanställts, multiplicerats och summerats:

Som ni förstår kan man genom att ändra vikterna och justera betygen uppnå vilket önskat resultat som helst, men det är en helt annan historia...

Källa: habr.com