Was ist besser – Oracle oder Redis? Oder wie man die Wahl der Plattform rechtfertigt.

– Das ist doch unglaublich, – sagte sie laut, ohne sich an jemanden zu wenden. – Das ist doch unglaublich! So steht es geschrieben – die Hauptaufgabe der Gesellschaft besteht darin, Gewinn im Interesse der Aktionäre zu erwirtschaften. Denken Sie mal nach! Sie haben ja gar keine Angst!

Julij Dubov, "Das kleinere Übel"

Wenn Sie solchen Titel sehen, haben Sie sicherlich schon beschlossen, dass der Artikel entweder Unsinn oder Provokation ist. Aber urteilen Sie nicht zu schnell: Mitarbeiter großer Unternehmen, besonders solchen mit staatlicher Beteiligung, müssen oft verschiedene Plattformen vergleichen, sogar sehr unterschiedliche – wie die, die im Titel erwähnt werden.

Natürlich werden DBMS nicht verglichen, da ihre Stärken und Schwächen gut bekannt sind. In der Regel werden Plattformen miteinander verglichen, die eine bestimmte Anwendungsaufgabe lösen. In diesem Artikel werde ich die Methodik zeigen, die dabei verwendet wird, am Beispiel von Datenbanken, die den Lesern von Habr nicht unbekannt sein sollten. Also,

Motivation

Wenn Sie ein Lernprojekt oder ein Hobbyprojekt starten, können die Motivationen für die Wahl einer Plattform vielfältig sein: „Diese Plattform kenne ich am besten“, „Hier möchte ich mehr erfahren“, „Die Dokumentation ist hier am besten“… In einem kommerziellen Unternehmen gibt es nur ein Auswahlkriterium: Wie viel muss ich bezahlen und was bekomme ich dafür?

Natürlich möchte man möglichst wenig bezahlen und dafür viel bekommen. Allerdings müssen Sie entscheiden, was wichtiger ist – weniger zu bezahlen oder mehr zu erhalten. Jeder Kriterium sollte ein Gewicht zugewiesen werden. Angenommen, uns ist eine qualitativ hochwertige Lösung wichtiger als eine kostengünstige, dann geben wir dem Kriterium „Kosten“ ein Gewicht von 40 % und dem Kriterium „Möglichkeiten“ 60 %.

In großen Unternehmen ist es normalerweise genau umgekehrt – das Gewicht der Kosten sinkt nicht unter 50 %, in vielen Fällen sogar über 60 %. Im Modellbeispiel ist wichtig, dass das Gesamtgewicht der untergeordneten Kriterien eines jeden übergeordneten Kriteriums 100 % betragen muss.

Ausschlusskriterien

Der Website db-engines.com Es sind ungefähr 500 Datenbankverwaltungssysteme bekannt. Natürlich kann, wenn man aus so vielen Optionen eine Zielplattform auswählt, eine Übersicht entstehen, aber kein kommerzielles Projekt. Um den Auswahlraum zu reduzieren, werden Ausschlusskriterien formuliert, und wenn die Plattform diese Kriterien nicht erfüllt, wird sie nicht in Betracht gezogen.

Die Ausschlusskriterien können sich auf technologische Eigenschaften beziehen, zum Beispiel:

• ACID-Garantien;
• relationale Datenmodelle;
• Unterstützung der SQL-Sprache (beachten Sie, dass dies nicht dasselbe ist wie das „relationale Modell“);
• Möglichkeit der horizontalen Skalierung.

Es können auch allgemeinere Kriterien vorliegen:

• vorhandene kommerzielle Unterstützung in Deutschland;
• Open Source;
• vorhandene Plattform im Register des Ministeriums für digitale Entwicklung;
• vorhandene Plattform in irgendeinem Ranking (zum Beispiel in den ersten hundert des Rankings von db-engines.com);
• vorhandene Experten auf dem Markt (zum Beispiel basierend auf der Suche nach dem Namen der Plattform in Lebensläufen auf der Website hh.ru).

Schließlich können auch unternehmensspezifische Kriterien relevant sein:

• Vorhandensein von Fachkräften im Unternehmen;
• Kompatibilität mit dem X-Überwachungssystem oder dem Y-Backup-System, auf das die gesamte Betreuung basiert...

Das Wichtigste ist, dass eine Liste der Ausschlusskriterien vorhanden ist. Andernfalls wird es mit Sicherheit einen Experten (oder „Experten“) geben, der besonderes Vertrauen beim Management genießt und sagt: „Warum habt ihr nicht die Plattform Z gewählt? Ich weiß, dass sie die beste ist.“

Kostenschätzung

Die Kosten der Lösung setzen sich offensichtlich aus den Lizenzkosten, den Betreuungskosten und den Kosten der Hardware zusammen.

Wenn die Systeme etwa der gleichen Klasse sind (zum Beispiel Microsoft SQL Server und PostgreSQL), kann man der Einfachheit halber davon ausgehen, dass die Menge an Hardware für beide Lösungen ungefähr gleich sein wird. Dies spart Zeit und Mühe, da eine Bewertung der Hardware nicht erforderlich ist. Wenn jedoch ganz unterschiedliche Systeme miteinander verglichen werden müssen (zum Beispiel Oracle vs. Redis), ist es offensichtlich, dass für eine korrekte Bewertung ein Sizing (Berechnung der Hardware-Anforderungen) nötig ist. Das Sizing eines nicht existierenden Systems ist eine wenig dankbare Aufgabe, weshalb solche Vergleiche oft vermieden werden. Es ist einfach: In den ausschließenden Bedingungen werden nulldatenverluste und das relationale Modell oder umgekehrt – eine Last von 50.000 Transaktionen pro Sekunde – festgelegt.

Um Lizenzen zu bewerten, genügt es, beim Anbieter oder dessen Partnern den Preis für eine feste Anzahl von Kernen und Support über einen bestimmten Zeitraum anzufragen. In der Regel haben Unternehmen bereits stabile Beziehungen zu Softwareanbietern aufgebaut. Wenn die Datenbankabteilung die Kosten nicht selbstständig ermitteln kann, reicht eine E-Mail aus, um diese Informationen zu erhalten.

Verschiedene Anbieter können unterschiedliche Lizenzierungsmetriken verwenden: nach Anzahl der Kerne, Datenvolumen oder Anzahl der Knoten. Eine Standby-Datenbank kann kostenlos sein oder genauso lizenziert werden wie die Hauptdatenbank. Wenn Unterschiede in den Metriken festgestellt werden, ist es notwendig, das Modellsetup detailliert zu beschreiben und die Lizenzkosten für das Setup zu berechnen.

Ein wichtiger Aspekt für einen fairen Vergleich sind identische Supportbedingungen. Zum Beispiel kostet der Support für Oracle 22 % der Lizenzkosten pro Jahr, während für PostgreSQL keine Gebühren anfallen. Ist es korrekt, so zu vergleichen? Nein, denn die Auswirkungen eines Fehlers, der nicht selbst behoben werden kann, sind völlig unterschiedlich: Im ersten Fall helfen die Support-Spezialisten schnell, das Problem zu lösen, während im zweiten Fall das Risiko besteht, dass das Projekt verzögert wird oder das fertige System unbestimmte Zeit stillsteht.

Die Bedingungen für die Berechnung kann man auf drei Arten angleichen:

1. Oracle ohne Support nutzen (in der Realität kommt das nicht vor).
2. Support für PostgreSQL erwerben – beispielsweise bei der Firma Postgres Professional.
3. Die Risiken einberechnen, die mit fehlendem Support verbunden sind.

Beispielsweise könnte die Berechnung der Risiken so aussehen: Im Falle eines irreparablen Datenbankausfalls beträgt die Ausfallzeit des Systems einen Arbeitstag. Der geplante Gewinn aus der Nutzung des Systems liegt bei 40 Milliarden mongolischen Tugrik pro Jahr, die Ausfallhäufigkeit wird auf 1 zu 400 geschätzt. Somit wird das Risiko eines fehlenden Supports auf etwa 100 Millionen mongolische Tugrik pro Jahr geschätzt. Offensichtlich sind sowohl der „geplante Gewinn“ als auch die „geschätzte Ausfallhäufigkeit“ virtuelle Größen. Es ist jedoch weitaus besser, ein solches Modell zu haben, als keines.

In der Realität könnte das System von zu großer Bedeutung sein, und die reputationsschädigenden Verluste durch längere Ausfallzeiten könnten unakzeptabel sein, weshalb Unterstützung erforderlich wird. Wenn jedoch Ausfallzeiten toleriert werden können, kann der Verzicht auf Support manchmal eine sinnvolle Möglichkeit zur Kostensenkung sein.

Angenommen, die Betriebskosten der Plattform A betragen über einen Zeitraum von 5 Jahren 800 Millionen mongolische Tögrigs, die von Plattform B 650 Millionen Tögrigs und die von Plattform C 600 Millionen Tögrigs. Plattform C erhält als Sieger den vollen Punkt für die Kosten, während die Plattformen A und B entsprechend ihrer höheren Kosten etwas weniger Punkte erhalten: 0,75 und 0,92 Punkte respektive.

Bewertung der Möglichkeiten

Die Bewertung der Möglichkeiten lässt sich in zahlreiche Gruppen unterteilen, deren Anzahl nur durch die Fantasie des Bewertenden begrenzt ist. Eine optimale Option scheint die Aufteilung nach den Teams zu sein, die diese Möglichkeiten nutzen werden; in unserem Beispiel handelt es sich um Entwickler, Administratoren und Mitarbeiter der Informationssicherheit. Angenommen, das Gewicht dieser Funktionen verteilt sich wie folgt: 40:40:20.

Zu den Funktionen der Entwicklung gehören:

• Benutzerfreundlichkeit bei der Datenmanipulation;
• Skalierbarkeit;
• Vorhandensein sekundärer Indizes.

Die Liste der Kriterien sowie deren Gewichtungen ist sehr subjektiv. Selbst bei der Lösung derselben Aufgabe können diese Listen, die Gewichtungen der Punkte und die Antworten stark variieren, abhängig von der Zusammensetzung Ihres Teams. So verwendet Facebook für die Datenspeicherung MySQL, während Instagram auf Cassandra basiert. Es ist unwahrscheinlich, dass die Entwickler dieser Anwendungen solche Tabellen ausgefüllt haben. Man kann nur vermuten, dass Mark Zuckerberg sich für ein vollwertiges relationales Modell entschieden hat, was die Notwendigkeit der angewandten Shardierung mit sich brachte, während Kevin Systrom das Skalierungspotenzial der Plattform nutzte und dabei den Zugang zu den Daten opferte.

Zu den Verwaltungsfunktionen gehören:

• Backup-Systemmöglichkeiten;
• Benutzerfreundliches Monitoring;
• Einfaches Management der Kapazitäten – Disk und Nodes;
• Datenreplikationsmöglichkeiten.

Bitte beachten Sie, dass die Formulierungen der Fragen eine quantitative Bewertung ermöglichen sollten. Man kann sogar vereinbaren, wie eine bestimmte Funktion bewertet wird. Lassen Sie uns beispielsweise versuchen, die Backup-Tools am Beispiel der mit der Oracle-Datenbank gelieferten Tools zu bewerten:

Ein Tool
Kommentar
Bewertung

imp/exp
Datenexport und -import
0.1

Backup starten/abschließen
Dateien kopieren
0.3

RMAN
Möglichkeit zur inkrementellen Sicherung
0.7

ZDLRA
Nur inkrementelle Sicherung, schnellere Wiederherstellung zu einem bestimmten Zeitpunkt
1.0

Wenn klare Bewertungskriterien fehlen, kann es sinnvoll sein, mehrere Experten um ihre Bewertungen zu bitten und diese dann zu mitteln.

Lassen Sie uns schließlich die Funktionen der Informationssicherheit auflisten:

• Vorhandensein von Passwortverwaltungspolitiken;
• Möglichkeit der Anbindung externer Authentifizierungsmittel (LDAP, Kerberos);
• Rollenbasiertes Zugriffsmodell;
• Auditmöglichkeiten;
• Verschlüsselung der Daten auf der Festplatte;
• Verschlüsselung während der Übertragung über das Netzwerk (TLS);
• Schutz der Daten vor dem Administrator.

Leistungstest

Ich möchte ausdrücklich davon abraten, Ergebnisse von Lasttests, die nicht von Ihnen durchgeführt wurden, als Argumente zu nutzen.

Zunächst einmal können die Datenstruktur und das Lastprofil der getesteten Anwendungen erheblich von der Aufgabe abweichen, die Sie lösen möchten. Vor etwa 10-15 Jahren prahlten Datenbankhersteller gerne mit Ergebnissen aus TPC-Tests, aber heute scheint niemand diese Ergebnisse ernst zu nehmen.

Zweitens hängt die Systemleistung erheblich davon ab, für welche Plattform der Code ursprünglich geschrieben wurde und auf welcher Hardware der Test durchgeführt wurde. Ich habe viele Tests gesehen, in denen Oracle mit PostgreSQL verglichen wurde. Die Ergebnisse reichen von der uneingeschränkten Überlegenheit eines Systems bis hin zur ebenso uneingeschränkten Überlegenheit des anderen.

Und schließlich wissen Sie drittens nichts darüber, wer den Test durchgeführt hat. Sowohl die Qualifikation, die die Qualität der Betriebssystem- und Plattformkonfiguration beeinflusst, als auch die Motivation, die die Testergebnisse stärker beeinflusst als alle anderen Faktoren zusammen, sind entscheidend.

Wenn die Leistung ein kritischer Faktor ist, führen Sie den Test selbst durch, idealerweise unter Beteiligung von Fachleuten, die das industrielle System konfigurieren und warten werden.

Ergebnis

Letztendlich sollte das Ergebnis all dieser Arbeit eine Tabelle sein, in der alle Bewertungen zusammengefasst, multipliziert und addiert sind.

Wie Sie verstehen, können Sie durch die Anpassung der Gewichte und die Korrektur der Bewertungen jedes gewünschte Ergebnis erzielen, aber das ist eine ganz andere Geschichte…

Quelle: habr.com