Thought Leadership
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.
