— Dat moet je toch niet zeggen, — zei ze luid, zonder tegen iemand te praten. — Dat moet je toch niet zeggen! Het staat letterlijk geschreven: de belangrijkste taak van de maatschappij is het behalen van winst in het belang van de aandeelhouders. Denk daar eens over na! Ze hebben nergens angst voor!
Julius Dubov, "Het minste kwaad"
Als je zo’n titel ziet, heb je waarschijnlijk al besloten dat het artikel ofwel onzin, ofwel provocatie is. Maar haast je niet met conclusies: medewerkers van grote bedrijven, vooral bedrijven met staatsdeelname, moeten vaak verschillende platforms vergelijken, inclusief zeer uiteenlopende – bijvoorbeeld diegene die in de titel worden genoemd.
Natuurlijk worden databases niet met elkaar vergeleken, omdat hun sterke en zwakke punten goed bekend zijn. Meestal worden platforms vergeleken die een bepaalde praktische taak oplossen. In dit artikel zal ik de methodologie tonen die daarbij wordt gebruikt, aan de hand van databases als onderwerp, dat lezers van Habr niet onbekend is. Dus,
Motivatie
Wanneer je een leerproject of een hobbyproject begint, kan de motivatie voor de keuze van het platform heel divers zijn: "dit platform ken ik het beste", "met dit wil ik graag aan de slag", "hier is de beste documentatie"… In het geval van een commercieel bedrijf is er slechts één selectiecriteria: hoeveel moet ik betalen en wat krijg ik daarvoor terug.
Natuurlijk wil je zo min mogelijk betalen en zoveel mogelijk krijgen. Maar je moet beslissen wat belangrijker is – minder betalen of meer krijgen – en weeg elke factor af. Stel dat we een kwalitatieve oplossing belangrijker vinden dan een goedkope, dan geven we de factor "Kosten" 40% gewicht en de factor "Mogelijkheden" 60%.
In grote bedrijven is het meestal precies andersom – het gewicht van de kosten daalt niet onder de 50%, en kan zelfs meer dan 60% zijn. In het modelvoorbeeld is het belangrijkste dat het totale gewicht van de subfactoren van elke hoofdfactor 100% moet zijn.
Afkappende voorwaarden
De websitenaam is er ongeveer 500 systemen voor databasebeheer bekend. Natuurlijk, als je een doelplatform uit zoveel opties kiest, kan dit resulteren in een overzichtsartikel, maar niet in een commercieel project. Om de keuze te verkleinen, worden afkappende criteria geformuleerd, en als een platform niet aan die criteria voldoet, wordt het niet overwogen.
Afkappende criteria kunnen betrekking hebben op technologische kenmerken, zoals:
- ACID-garanties;
- relationeel datamodel;
- ondersteuning voor de SQL-taal (let op, dit is niet hetzelfde als het 'relationele model');
- de mogelijkheid tot horizontale schaalbaarheid.
Er kunnen algemene criteria zijn:
- beschikbaarheid van commerciële ondersteuning in Nederland;
- open source;
- de aanwezigheid van het platform in het register van het ministerie van Economische Zaken;
- de aanwezigheid van het platform in een of andere ranking (bijvoorbeeld in de top honderd van db-engines.com);
- de aanwezigheid van experts op de markt (bijvoorbeeld gebaseerd op de resultaten van de zoekopdracht naar de platformnaam in cv's op de site hh.nl).
Uiteindelijk kunnen er criteria zijn die specifiek zijn voor de organisatie:
- de aanwezigheid van specialisten in dienst;
- compatibiliteit met monitoring systeem X of met back-up systeem Y, waarmee al het onderhoud samenhangt…
Het allerbelangrijkste is dat er een lijst van afkappende criteria is. Anders zal er zeker een of andere expert (of ‘expert’) zijn, die bijzonder geloofwaardig is in de ogen van het management, die zegt: 'Waarom hebben jullie platform Z niet gekozen, ik weet dat het de beste is.'
Kostenschatting
De kosten van de oplossing bestaan duidelijk uit de kosten van licenties, de kosten van ondersteuning en de kosten van hardware.
Als de systemen ongeveer van dezelfde klasse zijn (bijvoorbeeld Microsoft SQL Server en PostgreSQL), dan kan men voor de eenvoud aannemen dat het aantal hardware voor beide oplossingen ongeveer gelijk zal zijn. Dit maakt het mogelijk om de hardware niet te beoordelen, wat een hoop tijd en moeite bespaart. Als men echter volledig verschillende systemen moet vergelijken (bijvoorbeeld Oracle versus Redis), dan is het duidelijk dat een juiste beoordeling een sizing (berekening van de hoeveelheid hardware) vereist. Sizing van een niet-bestaand systeem is een uiterst ondankbare taak, daarom probeert men zo’n vergelijking te vermijden. Dit is eenvoudig te doen: in de afkappende voorwaarden wordt geschreven nul dataverlies en een relationeel model, of omgekeerd - een belasting van 50.000 transacties per seconde.
Om licenties te beoordelen, is het voldoende om bij de verkoper of zijn partners de prijs van de licentie voor een vastgesteld aantal kernen en ondersteuning voor een bepaalde periode op te vragen. Over het algemeen hebben bedrijven al sterke relaties met softwareleveranciers, en als de database-exploitatieafdeling niet zelfstandig het antwoord op de vraag naar de kosten kan geven, is het voldoende om slechts één e-mail te sturen om deze informatie te verkrijgen.
Verschillende leveranciers kunnen verschillende metrics voor licentieverlening hanteren: op basis van het aantal kernen, de hoeveelheid gegevens of het aantal knooppunten. Een standby-database kan gratis zijn, of net zo gelicentieerd worden als de hoofddatabase. Als er verschillen in de metrics worden ontdekt, moet het modelstandaard gedetailleerd worden beschreven en de kosten van de licenties voor de standaard worden berekend.
Een belangrijk punt voor een correcte vergelijking zijn dezelfde ondersteuningsvoorwaarden. Zeggen we dat de ondersteuning voor Oracle 22% van de licentiekosten per jaar bedraagt, terwijl voor PostgreSQL geen kosten voor ondersteuning nodig zijn. Is het juist om zo te vergelijken? Nee, omdat de gevolgen van een fout die niet door eigen inspanning kan worden opgelost, heel verschillend zijn: in het eerste geval helpen ondersteuningsspecialisten snel om het probleem op te lossen, terwijl in het tweede geval het risico bestaat op projectvertraging of stilstand van het gereed beschikbare systeem voor een onbepaalde tijd.
De vergelijkingsvoorwaarden kunnen op drie manieren gelijk worden gemaakt:
- Gebruik Oracle zonder ondersteuning (dat komt in de praktijk eigenlijk niet voor).
- Koop ondersteuning voor PostgreSQL - bijvoorbeeld bij het bedrijf Postgres Professional.
- Neem de risico's van het gebrek aan ondersteuning in de berekeningen op.
Bijvoorbeeld, de risicoanalyse kan er als volgt uitzien: in het geval van een onoplosbare storing in de database zal de stilstand van het systeem 1 werkdag bedragen. De verwachte winst van het gebruik van het systeem is 40 miljard Mongoolse tugrik per jaar, en de frequentie van storingen wordt geschat op 1/400, aldus wordt het risico van het ontbreken van ondersteuning geschat op ongeveer 100 miljoen Mongoolse tugrik per jaar. Het is duidelijk dat de 'verwachte winst' en de 'geschatte storingsfrequentie' virtuele grootheden zijn, maar het is veel beter om zo'n model te hebben dan helemaal niets.
In feite kan het systeem te belangrijk zijn en kunnen reputatieschade door langdurige downtime onaanvaardbaar blijken, daarom is ondersteuning nodig. Als downtime echter acceptabel is, kan het soms een goede manier zijn om te besparen om af te zien van ondersteuning.
Laten we aannemen dat na alle berekeningen de kosten voor het draaiende houden van platform A over een periode van 5 jaar 800 miljoen Mongoolse tögrög bedragen, de kosten voor platform B 650 miljoen tögrög, en de kosten voor platform C 600 miljoen tögrög zijn. Platform C ontvangt als winnaar 1 vol punt voor zijn kosten, terwijl platformen A en B iets minder krijgen, evenredig aan hoe veel duurder ze zijn. In dit geval 0.75 en 0.92 punten respectievelijk.
Beoordeling van mogelijkheden
De beoordeling van mogelijkheden kan worden onderverdeeld in tal van groepen, waarbij het aantal slechts beperkt is door de fantasie van degene die de beoordeling uitvoert. Een optimale indeling lijkt te zijn op basis van de teams die deze mogelijkheden zullen gebruiken; in ons voorbeeld zijn dat ontwikkelaars, beheerders en informatieveiligheidsofficieren. Laten we aannemen dat de gewichten van deze functies worden verdeeld als 40:40:20.
De ontwikkelingsfuncties omvatten:
- gemak van gegevensmanipulatie;
- schaalbaarheid;
- de aanwezigheid van secundaire indexen.
De lijst met criteria, evenals hun gewichten, is zeer subjectief. Zelfs bij het oplossen van dezelfde taak zullen deze lijsten, de gewichten van de punten en de antwoorden aanzienlijk verschillen afhankelijk van de samenstelling van uw team. Zo gebruikt Facebook MySQL voor gegevensopslag, terwijl Instagram is gebouwd op Cassandra. Het is onwaarschijnlijk dat de ontwikkelaars van deze applicaties dergelijke tabellen hebben ingevuld. We kunnen slechts gissen dat Mark Zuckerberg voor een volledige relationele model koos, met de noodzakelijkheid van applicatie-sharding als gevolg, terwijl Kevin Systrom schaalbaarheid heeft ingebouwd in de middelen van het platform, ten koste van het gemak van toegang tot gegevens.
De administratie-functies omvatten:
- mogelijkheden voor back-up systemen;
- gemak van monitoring;
- gemak van capaciteitsbeheer – schijven en knooppunten;
- mogelijkheden voor gegevensreplicatie.
Let op dat de formuleringen van de vragen een kwantitatieve beoordeling moeten toelaten. Je kunt zelfs afspraken maken over hoe een bepaalde functie te evalueren. Laten we bijvoorbeeld proberen punten te geven aan back-up hulpmiddelen aan de hand van de tools die worden geleverd met Oracle's DBMS:
Hulpmiddel
Opmerking
Beoordeling
imp/exp
Exporteren en importeren van gegevens
0.1
begin/einde back-up
Bestandscopy
0.3
RMAN
Mogelijkheid voor incrementele back-up
0.7
ZDLRA
Alleen incrementele back-up, snelste herstel naar een punt
1.0
Als er geen duidelijke beoordelingscriteria zijn, is het zinvol om verschillende experts te vragen om beoordelingen te geven en deze vervolgens te middelen.
Laten we tenslotte de functies van informatiebeveiliging opsommen:
- aanwezigheid van wachtwoordbeheerbeleid;
- mogelijkheid om externe authenticatiemiddelen aan te sluiten (LDAP, Kerberos);
- rolgebaseerd toegangsmodel;
- auditmogelijkheden;
- versleuteling van gegevens op de schijf;
- versleuteling tijdens verzending via netwerk (TLS);
- bescherming van gegevens tegen de administrator.
Prestatietests
Ik wil apart waarschuwen tegen het gebruik van resultaten van belastingtests die niet door jou zijn uitgevoerd als argumenten.
Ten eerste kunnen de datastructuur en het belastingprofiel van de geteste applicaties aanzienlijk verschillen van de taak die je van plan bent te realiseren. Ongeveer 10-15 jaar geleden hielden fabrikanten van databases ervan om de resultaten van TPC-tests te laten zien, maar nu lijkt niemand deze resultaten serieus te nemen.
Ten tweede hangt de prestaties van het systeem sterk af van de platform waarvoor de code oorspronkelijk is geschreven en op welke apparatuur de test is uitgevoerd. Ik heb veel tests gezien waarin Oracle met PostgreSQL werd vergeleken. De resultaten lopen van onbetwistbare superioriteit van het ene systeem tot even onbetwistbare superioriteit van het andere.
En ten derde weet je niets over wie de test heeft uitgevoerd. De kwalificatie die de kwaliteit van de OS- en platforminstellingen beïnvloedt, is net zo belangrijk als de motivatie, die een grotere invloed heeft op de testresultaten dan alle andere factoren samen.
Als prestaties een cruciale factor zijn, voer dan de test zelf uit, bij voorkeur met de hulp van specialisten die de industriële systemen zullen configureren en onderhouden.
Resultaat
Uiteindelijk moet het resultaat van al het werk een spreadsheet zijn waarin alle beoordelingen zijn samengevoegd, vermenigvuldigd en opgeteld:
Zoals u begrijpt, kan door het aanpassen van gewichten en het corrigeren van beoordelingen elk gewenst resultaat worden bereikt, maar dat is een heel ander verhaal...
Bron: habr.com
