Was ist besser – Oracle oder Redis oder Wie man die Wahl der Plattform begründet

– Das ist ja etwas, – sagte sie laut, ohne sich an jemanden zu wenden. – Das ist ja etwas! Es steht doch ganz klar geschrieben – die Hauptaufgabe der Gesellschaft ist die Gewinnmaximierung im Interesse der Aktionäre. Denken Sie nur mal nach! Sie haben überhaupt keine Angst!

Julij Dubov, „Das geringere Übel“

Wenn Sie so eine Überschrift sehen, haben Sie sicher schon entschieden, dass der Artikel entweder dumm oder provokativ ist. Aber warten Sie mit Ihren Schlussfolgerungen: Die Mitarbeiter großer Unternehmen, insbesondere der Unternehmen mit staatlicher Beteiligung, müssen ziemlich häufig verschiedene Plattformen vergleichen, darunter auch völlig unterschiedliche – zum Beispiel die, die in der Überschrift genannt werden.

Natürlich werden Datenbankmanagementsysteme so nicht verglichen, denn ihre Stärken und Schwächen sind gut bekannt. In der Regel werden Plattformen verglichen, die eine bestimmte Anwendungsaufgabe lösen. In diesem Artikel zeige ich Ihnen die Methodik, die dabei verwendet wird, am Beispiel von Datenbanken, die den Lesern von Habr nicht unbekannt sein dürften. Also,

Motivation

Wenn Sie ein Lernprojekt oder ein Hobbyprojekt starten, können die Motivationen für die Wahl der Plattform sehr unterschiedlich sein: „Diese Plattform kenne ich am besten“, „Mit der hier möchte ich mich näher beschäftigen“, „Hier gibt es die beste Dokumentation“… Im Falle eines kommerziellen Unternehmens gibt es nur ein Kriterium: Wie viel muss ich bezahlen und was erhalte ich dafür?

Natürlich möchte man weniger bezahlen und mehr erhalten. Allerdings muss entschieden werden, was wichtiger ist – weniger zu bezahlen oder mehr zu bekommen, und jedem Kriterium ein Gewicht zugeordnet werden. Angenommen, uns ist eine qualitativ hochwertige Lösung wichtiger als eine günstige, dann vergeben wir dem Kriterium „Kosten“ ein Gewicht von 40% und dem Kriterium „Funktionen“ 60%.

In großen Unternehmen ist es normalerweise umgekehrt – das Gewicht der Kosten fällt selten unter 50% und kann sogar über 60% betragen. Im modellhaften Beispiel ist nur wichtig, dass das gesamte Gewicht der Unterkriterien eines übergeordneten Kriteriums 100% betragen muss.

Ausschlusskriterien

Website db-engines.com Es sind etwa 500 Datenbankmanagementsysteme bekannt. Natürlich, wenn man die Zielplattform aus so vielen Optionen auswählt, kann es sich um einen Überblicksartikel handeln, aber nicht um ein kommerzielles Projekt. Um den Auswahlraum zu verkleinern, werden Ausschlusskriterien formuliert, und wenn eine Plattform diese Kriterien nicht erfüllt, wird sie nicht in Betracht gezogen.

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

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

Es können allgemeine Kriterien sein:

• das Vorhandensein kommerzieller Unterstützung in Russland;
• offener Quellcode;
• das Vorhandensein der Plattform im Register des Ministeriums für digitale Entwicklung;
• das Vorhandensein der Plattform in einem Ranking (zum Beispiel in den ersten Hundert des Rankings db-engines.com);
• das Vorhandensein von Experten auf dem Markt (z. B. basierend auf den Ergebnissen der Suche nach dem Plattformnamen in Lebensläufen auf der Website hh.ru).

Schließlich können es unternehmensspezifische Kriterien geben:

• das Vorhandensein von Fachkräften im Unternehmen;
• die Kompatibilität mit dem Überwachungssystem X oder dem Backup-System Y, auf das die gesamte Unterstützung angewiesen ist...

Das Wichtigste ist, dass es eine Liste von ausschließenden Kriterien gibt. Andernfalls wird es immer einen 'Experten' geben, der ein besonderes Vertrauen des Managements genießt und sagt: 'Warum haben Sie nicht die Plattform Z gewählt, ich weiß, dass sie die beste ist.'

Kostenbewertung

Die Kosten für die Lösung ergeben sich offensichtlich aus den Lizenzkosten, den Unterstützungsgebühren und den Hardwarekosten.

Wenn die Systeme ungefähr derselben Klasse angehören (zum Beispiel Microsoft SQL Server und PostgreSQL), kann man zur Vereinfachung annehmen, dass die Anzahl der benötigten Hardware für beide Lösungen ungefähr gleich sein wird. Dies spart Zeit und Mühe, da die Hardware nicht bewertet werden muss. Wenn jedoch völlig unterschiedliche Systeme (zum Beispiel Oracle vs. Redis) verglichen werden müssen, ist es offensichtlich, dass für eine korrekte Bewertung ein Sizing (Berechnung der Hardwareanforderungen) durchgeführt werden muss. Das Sizing einer nicht existierenden System ist eine sehr undankbare Aufgabe, daher versucht man, solche Vergleiche zu vermeiden. Es ist einfach: In den ausschließlichen Bedingungen werden null Datenverluste und ein relationales Modell oder umgekehrt – eine Last von 50.000 Transaktionen pro Sekunde – festgelegt.

Für die Bewertung von Lizenzen reicht es aus, beim Anbieter oder dessen Partnern den Preis für eine feste Anzahl von Kernen und eine feste Supportdauer anzufragen. In der Regel haben Unternehmen bereits stabile Beziehungen zu Softwareanbietern, und wenn die Datenbankbetriebsabteilung die Kostenfrage nicht selbst beantworten kann, genügt ein einziges Schreiben, um diese Informationen zu erhalten.

Bei verschiedenen Anbietern können unterschiedliche Lizenzierungsmetriken gelten: nach Anzahl der Kerne, Datenvolumen oder Anzahl der Knoten. Eine Standby-Datenbank kann kostenlos sein oder auch lizenziert werden wie die Hauptdatenbank. Wenn nur Unterschiede in den Metriken festgestellt werden, muss das Modelltestumfeld detailliert beschrieben und die Lizenzkosten für das Testumfeld berechnet werden.

Ein wichtiger Punkt für einen korrekten Vergleich sind die gleichen Supportbedingungen. Angenommen, der Support von Oracle kostet 22 % des Lizenzpreises pro Jahr, während für den Support von PostgreSQL keine Gebühren anfallen. Ist es so korrekt zu vergleichen? Nein, denn die Konsequenzen eines Fehlers, der nicht eigenständig behoben werden kann, sind völlig unterschiedlich: Im ersten Fall helfen die Support-Spezialisten schnell bei der Behebung, während im zweiten Fall das Risiko eines Projektverzugs oder eines unbestimmten Stillstands des fertigen Systems besteht.

Die Bedingungen für die Berechnung können auf drei Arten angeglichen werden:

1. Oracle ohne Support nutzen (was in der Realität nicht vorkommt).
2. Support für PostgreSQL kaufen – zum Beispiel bei der Firma Postgres Professional.
3. Risiken einberechnen, die mit dem Fehlen von Support verbunden sind.

Ein Risikoabrechnungsbeispiel könnte so aussehen: Im Falle eines nicht lösbaren Datenbankausfalls beträgt der Stillstand des Systems 1 Arbeitstag. Der geplante Gewinn aus der Nutzung des Systems beträgt 40 Milliarden mongolische Tugrik pro Jahr, die Ausfallrate wird als 1/400 eingeschätzt, was das Risiko des Fehlens von Unterstützung auf etwa 100 Millionen mongolische Tugrik pro Jahr schätzt. Offensichtlich sind 'geplanter Gewinn' und 'geschätzte Ausfallrate' virtuelle Größen, aber es ist viel besser, ein solches Modell zu haben, als gar keines.

In der Tat kann ein System zu wichtig sein, und die reputativen Verluste durch längere Ausfallzeiten könnten inakzeptabel sein, weshalb Unterstützung erforderlich ist. Wenn jedoch Ausfallzeiten toleriert werden, kann der Verzicht auf Unterstützung manchmal eine gute Möglichkeit sein, um Kosten zu sparen.

Nehmen wir an, dass die Betriebskosten der Plattform A über 5 Jahre hinweg 800 Millionen mongolische Tögriks betrugen, die Betriebskosten der Plattform B – 650 Millionen Tögriks, und die Betriebskosten der Plattform C – 600 Millionen Tögriks. Plattform C erhält als Sieger den vollen Punkt für die Kosten, während die Plattformen A und B entsprechend weniger Punkte erhalten, proportional zu dem, um wieviel teurer sie sind. In diesem Fall – 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 Lösung scheint die Unterteilung der Möglichkeiten nach den Teams zu sein, die diese nutzen werden; in unserem Beispiel sind das Entwickler, Administratoren und Informationssicherheitsbeauftragte. Nehmen wir an, die Gewichte dieser Funktionen verteilen sich wie 40:40:20.

Zu den Entwicklungsfunktionen gehören:

• vorhandene Datenmanipulation;
• Skalierbarkeit;
• Vorhandensein von Sekundärindizes.

Die Liste der Kriterien sowie deren Gewichte ist sehr subjektiv. Selbst bei der Lösung derselben Aufgabe werden diese Listen, das Gewicht der Punkte und die Antworten erheblich variieren, abhängig von der Zusammensetzung Ihres Teams. So verwendet Facebook beispielsweise MySQL zur Datenspeicherung, 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 ein vollständiges relationales Modell gewählt hat, was ihm die Notwendigkeit des Anwendungs-Shardings einbrachte, während Kevin Systrom die Skalierbarkeit zugunsten des Datenzugangs opferte.

Zu den Verwaltungsfunktionen gehören:

• Möglichkeiten des Backupsystems;
• Benutzerfreundlichkeit des Monitorings;
• Benutzerfreundlichkeit der Leistungsverwaltung – Festplatten und Knoten;
• Möglichkeiten der Datenreplikation.

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

Tool
Kommentar
Bewertung

imp/exp
Datenexport und -import
0.1

Backup beginnen/beenden
Dateikopie
0.3

RMAN
Möglichkeit des inkrementellen Kopierens
0.7

ZDLRA
Nur inkrementelles Kopieren, schnellste Wiederherstellung zu einem bestimmten Zeitpunkt
1.0

Wenn klare Bewertungskriterien fehlen, macht es Sinn, mehrere Experten um eine Bewertung zu bitten und diese dann zu mitteln.

Lassen Sie uns schließlich einfach 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 beim Übertragen über das Netzwerk (TLS);
• Datenschutz vor Administratoren.

Leistungstest

Ich möchte ausdrücklich davor warnen, Ergebnisse von Lasttests, die nicht von Ihnen durchgeführt wurden, als Argumente zu verwenden.

Erstens können die Struktur der Daten und das Lastprofil der getesteten Anwendungen erheblich von dem abweichen, was Sie zu lösen beabsichtigen. Vor 10-15 Jahren haben Datenbankhersteller gerne mit Ergebnissen aus TPC-Tests geprahlt, aber heute scheint niemand diese Ergebnisse ernst zu nehmen.

Zweitens hängt die Leistung des Systems stark 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 unbestrittenem Überlegen sein einer Plattform bis hin zu ebenso unbestrittenem Überlegen sein der anderen.

Und schließlich, drittens, wissen Sie 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 wichtig.

Wenn Leistung ein entscheidender Faktor ist, führen Sie den Test selbst durch, idealerweise mit der Beteiligung von Fachleuten, die das industrielle System konfigurieren und unterstützen werden.

Ergebnis

Schließlich sollte das Ergebnis all der geleisteten Arbeit eine Tabelle sein, in der alle Bewertungen zusammengefasst, multipliziert und addiert sind:

Wie Sie verstehen, kann man durch die Änderung der Gewichtungen und Anpassung der Bewertungen jedes gewünschte Ergebnis erzielen, aber das ist eine ganz andere Geschichte...

Quelle: habr.com