Anzeige

SQL

Latenzen

Eine verteilte Datenbank hat eine höhere Latenz als eine lokale Festplatte oder eine Client-Server-Datenbank. Trotzdem sollte sie eine Latenz von mindestens zehn Millisekunden bieten, selbst bei Tausenden oder Hunderttausenden von Anfragen pro Sekunde. 

Um die richtige Lösung für verteiltes SQL auszuwählen, müssen Unternehmen die gesamte Antwortzeit als Zeitbudget betrachten. Entscheidend ist die Wartezeit zwischen einem Benutzerklick und der Ankunft der Daten, einschließlich HTML, Grafiken, JSON und anderer Komponenten. Bei alltäglichen Anwendungen sollten Unternehmen mit einer Antwortzeit von drei Sekunden rechnen. Bei Echtzeit-Anwendungen im E-Commerce wird das Budget eher bei einigen Dutzend Millisekunden liegen. 

Die Datenbanklösung selbst sollte nur einen Bruchteil des gesamten Zeitbudgets verbrauchen, damit sie nicht zu einem Nadelöhr wird. Diese Abschätzung der notwendigen Latenz aufgrund der tatsächlichen Anforderung einer Anwendung ist ein wichtiges Beurteilungskriterium für verteiltes SQL.

Verfügbarkeit

Verteilte SQL-Datenbanken bieten eine hohe Ausfallsicherheit, die bei einfachen Client-Server-Datenbanken nicht möglich ist. Besonders hoch ist die Ausfallsicherheit in der Cloud. So kann beispielsweise eine ganze Verfügbarkeitszone ohne Ausfall des Datenbankdienstes verloren gehen.

Kompatibilität

Eine entscheidende Frage bei der Auswahl einer verteilten SQL-Datenbank ist der Aufwand für die Migration bestehender Anwendungen. Verschiedene Lösungen unterstützen unterschiedliche SQL-Dialekte, Datentypen und Semantiken. Die beste Lösung ist hier üblicherweise, innerhalb einer Datenbankfamilie zu bleiben – also beispielsweise von der Client-Server-Edition einer Datenbank zur DBaaS-Variante zu wechseln. 

Bei SQL-Anwendungen, die für andere Datenbanken geschrieben wurden, ist der Aufwand in etwa so groß wie der Wechsel zu einem anderen RDBMS. Unter anderem müssen die Abfragen sowie die in SQL-DDL-Anweisungen verwendeten Typnamen geändert werden.

Kosten

Ein Kostenvergleich unterschiedlicher Lösungen sollte die Aufwendungen für Lizenzen, Cloud-Ressourcen, das Risiko von Ausfällen, Mitarbeiterschulungen und die allgemeine Wartung berücksichtigen. Ohne Berücksichtigung weiterer Kriterien ist ein DBaaS-Angebot meist kosteneffizienter, unter anderem durch verbrauchsabhängige Bezahlung.

Doch manche Unternehmen haben das Problem der irreversiblen Kosten durch Bestandsysteme, die aus unterschiedlichen Gründen nicht abgelöst werden können. In diesem Fall ist die Bereitstellung einer Datenbank vor Ort die bessere Wahl.

Vor der Kaufentscheidung: der Machbarkeitsnachweis

In den meisten Fällen werden anhand der oben genannten Kriterien vielleicht noch zwei oder drei Datenbanksysteme übrigbleiben. Selbst wenn es nur eines ist: Unternehmen sollten auf jeden Fall die Eignung für ihre spezifischen Zwecke in ausführlichen Tests überprüfen. Dafür bieten die meisten Anbieter zeitlich limitierte Testversionen oder Testzugänge an.

Der wichtigste Aspekt bei der Entwicklung eines Machbarkeitsnachweises besteht darin, sich auf alltagstaugliche Daten und Abfragen zu konzentrieren. Es ist wenig sinnvoll, die Grenzen einer Plattform mit unrealistischen Abfragen zu testen – etwa 15 Joins mit 6 Tabellen. Sie sind für typische Datenbanktransaktionen nicht aussagekräftig.

Datenbanktechnologien gehen immer Kompromisse ein und sind für bestimmte Nutzungsmuster optimiert. Bei verteiltem SQL ist das der Durchsatz des Transaktionsvolumens. Beim Entwurf eines Machbarkeitsnachweises sollte also der tatsächliche Produktionsdaten- und Anwendungsverkehr genutzt werden. Am zweitbesten ist eine Simulation mit einem Testsystem, die dem üblichen Nutzungsmuster bei Tabellenstruktur, Abfragekomplexität und Anteil der Lese- und Schreibvorgänge nahekommt. 

Die Tests sollten über die Messung einzelner Faktoren wie Datenbanklatenz hinausgehen. So ist es hilfreich, die Gesamtleistung der Anwendung bei Nenn- und Spitzenlasten zu bewerten und dabei die Spreizung der Latenzwerte zu beachten. Zudem muss bei den Tests sichergestellt werden, dass die Infrastruktur eine ausreichende Last erzeugen kann, damit sie nicht zum Nadelöhr wird und den Test verfälscht.

Am Ende der Tests steht dann eine Entscheidung: verteiltes SQL ist eine gute Option für Systeme, die ein hohes Datenvolumen, eine große Anzahl von Nutzern oder hohe Anforderungen an die Verfügbarkeit und die Notfallwiederherstellung haben. Darüber hinaus eignen sie sich besonders für Systeme, die in die Cloud migriert werden.

Andrew Oliver, Senior Director of Product Marketing
Andrew Oliver
Senior Director of Product Marketing, MariaDB Corporation
Andrew Oliver ist seit 2021 für MariaDB tätig und verfügt aus vorherigen Stationen bei IBM, Cisco, Red Hat, Lucidworks, Couchbase und Yugabyte profunde Kenntnisse sowohl in der Java-Entwicklung als auch im Bereich des technischen Produktmarketings.

Weitere Artikel

Datenanalyse

Analytics bleibt eine Herausforderung

In einer gemeinsamen Studie der Enterprise Strategy Group und InterSystems zum Datenmanagement in Unternehmen gab das Gros der Unternehmen an, das Ziel zu verfolgen, die Bereitstellung von Daten über die gesamte Wertschöpfungskette hinweg voranzutreiben.
Datenmanagement

Nutzung von Echtzeit-Daten und historischen Daten

Hazelcast, Inc., Anbieter der Plattform für intelligente Echtzeitanwendungen, hat eine globale Studie unter Business- und IT-Entscheidern in Einzelhandels- und Finanzdienstleistungsunternehmen veröffentlicht.
Datenanalyse

Wettbewerbsnachteile wegen fehlender Datenkompetenzen

Fehlende Datenkompetenzen in der Breite der Belegschaft werden zu einem zentralen Bremser für die digitale Transformation deutscher Unternehmen. So lautet ein Ergebnis einer repräsentativen Umfrage* unter mehr als 1.000 Mitarbeiterinnen und Mitarbeitern, die…

Anzeige

Jetzt die smarten News aus der IT-Welt abonnieren! 💌

Mit Klick auf den Button "Zum Newsletter anmelden" stimme ich der Datenschutzerklärung zu.