Auswahl der richtigen Datenbanken für Microservices

Wenn Ihre Anwendung wie die meisten Anwendungen ist, die gerade in Microservices umgewandelt werden, können wir wahrscheinlich davon ausgehen, dass sie mit einer einzigen, großen relationalen Datenbank arbeitet. Außerdem besteht eine nahezu gleiche Chance, dass diese Datenbank eine Oracle-Datenbank ist – alle anderen relationalen Datenbanken (DB2, SQL Server, Informix oder sogar eine Open Source-Datenbank wie MySQL oder Postgres) teilen sich den restlichen Anteil auf. Tatsächlich ist der Umstieg von der (meist kostspieligen) Unternehmens-Relationaldatenbank einer der Nutzen, die beim Refactoring auf Microservice oft gefördert werden.

Es gibt sehr gute Gründe, andere Arten von Datenbanken zu wählen – entweder NewSQL oder NoSQL für viele Microservices. Es ist jedoch oft eine dumme Entscheidung, Ihre aktuelle relationale Datenbank auf einmal aufzugeben. Stattdessen möchten Sie vielleicht einen schrittweisen Ansatz zur Änderung Ihrer Datenbank in Betracht ziehen, so wie wir einen schrittweisen Ansatz zur Refaktorisierung Ihres bestehenden Java-Codes empfehlen.

Genau wie beim inkrementellen Ansatz für die Codierung, den wir befürwortet haben, besteht das größte Problem bei der Anwendung eines inkrementellen Ansatzes für die Datenbankrefaktorisierung jedoch darin, zu entscheiden, wo man anfangen soll. Die erste Entscheidung, die Sie treffen müssen, wenn Sie sich für einen inkrementellen Ansatz entschieden haben, ist, ob Sie eine große Datenbank oder viele kleine Datenbanken verwenden sollten. Das klingt im ersten Moment nach Unsinn – natürlich will man keine einzige große Datenbank, genau das hat man ja in einem Monolithen! Aber lassen Sie uns zunächst erklären, was wir damit meinen.

Grundsätzlich muss man zunächst zwischen einem Datenbankserver und einem Datenbankschema unterscheiden. Für diejenigen unter Ihnen, die mit Datenbanken im Unternehmensmaßstab wie Oracle oder Db2 vertraut sind, ist dies selbstverständlich, da Unternehmen in der Regel über einen großen Oracle-Server (oder ein RAC, ein großer Server, der aus vielen kleineren Servern besteht) verfügen, auf dem mehrere Teams ihre eigenen separaten Datenbanken hosten (jede wird durch ein separates Schema repräsentiert). Der Grund dafür ist, dass die Lizenzierung oft nach CPU erfolgt und das Unternehmen die Nutzungsmenge maximieren möchte, die es für sein Geld bekommt. Eine Möglichkeit hierfür ist, mehrere Teams auf einem großen Server zusammenzuführen. Für diejenigen unter Ihnen, die mehr mit Open-Source-Datenbanken wie MySQL oder PostgreSQL vertraut sind,ist dies etwas weniger üblich, da die Unterscheidung seltener benötigt wird.

Das ist wichtig, denn wenn wir über den Aufbau von Datenbanken für Microservices sprechen, ist es wichtig, dass wir Coupling in der Datenbank reduzieren oder eliminieren – aber das bedeutet eigentlich Coupling auf Datenbankschema-Ebene. Probleme entstehen, wenn zwei verschiedene Microservices dieselben Informationen verwenden – dieselben Tabellen innerhalb desselben Schemas. Wenn Sie sich Abbildung 1 ansehen, verstehen Sie, was wir meinen.

Das Datenbank-Äquivalent einer monolithischen Anwendung (auch bekannt als „Big Ball of Mud“, wo alles mit allem anderen verbunden ist) besteht aus einem großen Schema, das jede Tabelle miteinander verbindet. Wann immer das passiert, ist die Menge an Entwirrung, die erforderlich ist, um die Tabellen zu trennen, enorm. 

Beim Übergang zu Microservices muss man sich jedoch bewusst sein, dass die gemeinsame Nutzung von Hardware und Lizenzen auf Serverebene wesentlich weniger Probleme verursacht. In der Tat hat es bei der anfänglichen Umstrukturierung zu Microservices viele Vorteile, die neuen, sauberer getrennten Schemas auf denselben Unternehmensservern zu belassen, da Unternehmen in der Regel bereits über Verfahren für die Backup und Wiederherstellung von Datenbanken sowie für Updates von Datenbankservern verfügen, von denen die Teams profitieren können. 

In gewisser Hinsicht bietet das Unternehmen mit der Bereitstellung der Hardware und Software sowie der Verwaltung einer Unternehmensdatenbank eine eingeschränkte Version von Database-as-a-Service (DBaaS) an. Dies passt besonders gut zu einem Ansatz, der damit beginnt, Teile Ihres Monolithen nach Funktionsbereich klarer zu trennen, beginnend mit einem „Modularen Monolithen“-Ansatz, wie in Abbildung 2 dargestellt.

In diesem Beispiel (das ein laufendes Refactoring zeigen soll) sehen Sie, wie die Datenbank durch die Trennung von Tabellen, die drei neuen Schemas (A, B und C) entsprechen, die bestimmten Modulen in der überarbeiteten Anwendung entsprechen, aufgebrochen wurde. Sobald sie so getrennt wurden, können sie sauber in verschiedene Microservices aufgeteilt werden. D und E werden jedoch noch umgestaltet – sie teilen immer noch ein einziges Schema mit miteinander verbundenen Tabellen.

Irgendwann kann sogar die Verknüpfung auf Datenbank-Server-Ebene zu einem Problem werden. Wenn Sie sich beispielsweise für eine Unternehmensdatenbank entscheiden, sind Sie auf deren verfügbare Funktionen beschränkt. Auch in einem relationalen Modell benötigen nicht alle Schemata alle diese Funktionen, oder sie benötigen möglicherweise Funktionen, die von einem anderen Server besser unterstützt werden (z. B. wird oft ein besseres Sharding als Grund für die Verwendung einer NewSQL-Datenbank angeführt). Ebenso könnte das Upgrade eines Datenbankservers, der von mehreren Microservices genutzt wird, mehrere Dienste auf einmal lahmlegen. 

Aber das Problem ist, dass diese Entscheidung aufgeschoben werden kann – sie muss nicht sofort zu Beginn des Projekts getroffen werden. Wenn Teams mit dem Refactoring beginnen, ist es hilfreich, sie zumindest in der Anfangsphase des Projekts auf demselben Datenbankserver zu belassen, um schrittweise Änderungen vornehmen zu können und gleichzeitig die notwendige Erfahrung im Code- und Datenbank-Refactoring zu sammeln.

Wie im letzten Abschnitt angedeutet, sollten Sie im Verlauf des Refactorings etwas sorgfältiger über Ihre Datenbankoptionen denken, da nicht alle Datensätze perfekt für ein relationales Modell geeignet sind. Die Entscheidung für den besten Ansatz zur Verwaltung dieser Datensätze läuft oft auf die Frage hinaus: „Was speichern Sie eigentlich in Ihrer Datenbank?“

Wir haben Unternehmen jahrelang dabei geholfen, Frameworks für die objektrelationale Zuordnung aufzubauen und zu pflegen. Die Realität war jedoch, dass in mehreren Fällen die gespeicherten Daten überhaupt nicht gut mit einem relationalen Datenmodell abgebildet werden konnten. Wann immer das passierte, mussten wir entweder das relationale Modell „verdrehen“, damit es passt, oder, was wahrscheinlicher ist, in den Programmen durch einen Reifen springen, um den Code an den relationalen Datenspeicher anzupassen.

Jetzt, da wir in eine Ära polyglotter Persistenzentscheidungen übergegangen sind, können wir einige dieser Entscheidungen noch einmal überprüfen und einige bessere treffen. Insbesondere wollen wir vier verschiedene Fälle betrachten, in denen offensichtlich ist, dass das relationale Modell nicht die beste Option war, und dann einen Fall betrachten, in dem das relationale Modell die beste Option war und die Daten in einer anderen Form nicht der richtige Ansatz gewesen wären.

Viele Male haben wir den Persistenzcode von Unternehmenssystemen durchsucht und dann zu unserer Überraschung festgestellt, dass das, was sie in ihren relationalen Datenbanken speichern, binäre Darstellungen von serialisierten Java-Objekten sind. Diese werden in „Binary Large Object“- oder „Blob“-Spalten gespeichert und sind in der Regel das Ergebnis davon, dass ein Team angesichts der Komplexität, seine Java-Objekte in relationale Tabellen und Spalten abzubilden, die Hände über dem Kopf zusammenschlägt. Blob-Speicher haben gewisse Nachteile: Sie können niemals spaltenweise abgefragt werden; sie sind oft langsam; und sie reagieren empfindlich auf Änderungen in der Struktur der Java-Objekte selbst – ältere Daten sind möglicherweise nicht mehr lesbar, wenn sich die Objektstruktur erheblich ändert.

Wenn deine Anwendung (oder wahrscheinlicher ein Teil deiner Anwendung) Blob-Speicher in einer relationalen Datenbank verwendet, ist das schon ein ziemlich gutes Zeichen dafür, dass du mit einem Key-Value-Store wie Memcached oder Redis besser beraten bist. Andererseits sollten Sie vielleicht einen Schritt zurücktreten und ein wenig darüber nachdenken, was Sie da eigentlich speichern. Wenn es sich herausstellt, dass es sich nur um ein strukturiertes Java-Objekt handelt (vielleicht tief strukturiert, aber nicht nativ binär), bist du vielleicht besser beraten, einen Dokumentenspeicher wie Cloudant oder MongoDB zu verwenden. Darüber hinaus können Sie mit ein wenig Aufwand in die Speicherung Ihrer Dokumente (beispielsweise sind beide oben genannten Datenbanken JSON-Dokumentenspeicher und JSON-Parser sind weit verbreitet und leicht anzupassen) Probleme mit dem „Schema-Drift“ viel einfacher bewältigen als mit einem Blob-Speicheransatz, der viel undurchsichtiger in seinem Speichermechanismus ist.

Vor Jahren, als Martin Fowler „Patterns of Enterprise Anwendungsarchitekturen“ schrieb, hatten wir eine aktive Korrespondenz und mehrere lebhafte Reviews zu vielen der Muster. Vor allem eines ist mir immer wieder aufgefallen: das Active Record-Muster. Es war seltsam, denn da wir aus der Java-Community kamen, war uns das noch nie begegnet (obwohl Martin uns versicherte, dass es in der Microsoft .NET-Programmiergemeinschaft üblich sei). Aber was uns wirklich auffiel – und vor allem, als wir einige Java-Implementierungen mit Open-Source-Technologien wie iBatis sahen – war, dass es der beste Fall für die Verwendung war, wenn die Objekte, nun ja, flach waren.

Wenn das Objekt, das Sie in eine Datenbank abbilden, vollständig und völlig flach ist – ohne Beziehungen zu anderen Objekten (mit der begrenzten Ausnahme vielleicht von verschachtelten Objekten) – dann nutzen Sie wahrscheinlich nicht die vollen Funktionen des relationalen Modells. Tatsächlich ist es viel wahrscheinlicher, dass Sie ein Dokument speichern. In den Fällen, in denen wir dies beobachtet haben, speichern die Teams buchstäblich elektronische Versionen von Papierdokumenten, seien es Umfragen zur Kundenzufriedenheit, Problemtickets usw. In dieser Situation ist eine Dokumentendatenbank wie Cloudant oder MongoDB wahrscheinlich die beste Wahl für dich. Die Aufteilung Ihres Codes in eigene Dienste, die mit dieser Art von Datenbank arbeiten, führt zu einem viel einfacheren Code und ist oft leichter zu pflegen als der Versuch, dasselbe als Teil einer großen Unternehmensdatenbank zu tun.

Ein weiteres häufiges Muster, das wir bei ORM-Systemen beobachtet haben, ist die Kombination aus „Referenzdaten in einer Tabelle, die in einen In-Memory-Cache geladen werden“. Referenzdaten bestehen aus Dingen, die nicht oft (oder nie) aktualisiert werden, aber ständig gelesen werden. Ein gutes Beispiel hierfür ist die Liste der U.S.-Bundesstaaten oder kanadischen Provinzen; weitere Beispiele sind medizinische Codes oder Standardteilelisten. Diese Art von Daten wird häufig verwendet, um Dropdowns in GUIs auszufüllen.

Das übliche Muster besteht darin, die Liste bei jeder Verwendung zunächst aus einer Tabelle zu lesen (normalerweise eine flache zwei- oder höchstens dreispaltige Tabelle). Sie werden jedoch feststellen, dass der Aufwand, dies jedes Mal zu tun, prohibitiv ist. Daher liest die Anwendung die Daten stattdessen beim Start in einen In-Memory-Cache wie EhCache ein.

Wann immer dieses Problem auftritt, möchte man es in einen einfacheren, schnelleren Caching-Mechanismus umwandeln. Auch in diesem Fall wären Memcached oder Redis völlig sinnvoll. Wenn die Referenzdaten unabhängig vom Rest Ihrer Datenbankstruktur sind (und oft oder höchstens lose gekoppelt sind), kann es hilfreich sein, die Daten und ihre Dienste vom Rest Ihres Systems zu trennen.

In einem Kundensystem, an dem wir gearbeitet haben, führten wir komplexe Finanzmodellierungen durch, die sehr komplizierte Abfragen (in der Größenordnung von sechs- oder siebenfachen Joins) erforderten, nur um die Objekte zu erstellen, die das Programm bearbeitete. Aktualisierungen waren noch komplizierter, da wir mehrere verschiedene Ebenen optimistischer Sperrprüfungen kombinieren mussten, um herauszufinden, was sich geändert hatte und ob das, was in der Datenbank vorhanden war, noch mit der Struktur übereinstimmte, die wir erstellt und manipuliert hatten.

Im Nachhinein ist klar, dass das, was wir taten, natürlicher als Graph hätte modelliert werden können. Situationen wie diese (in diesem Fall haben wir Fondstranchen modelliert, die jeweils aus verschiedenen Arten von Aktien und Schuldverschreibungen bestehen, die jeweils in unterschiedlichen Währungen bewertet werden und zu unterschiedlichen Zeiten fällig werden, mit unterschiedlichen Regeln für jede Bewertung) sind etwas das fast nach einer Datenstruktur verlangt, die es Ihnen ermöglicht, das zu tun, was Sie wirklich wollen: im Diagramm auf- und abwärts zu durchsuchen und Teile des Diagramms nach Belieben zu verschieben.

Hier wäre eine Lösung wie Apache Tinkerpop oder Neo4J ein guter Ansatz. Wenn wir die Lösung direkt als Graph modelliert hätten, hätten wir eine Menge komplizierten Java- und SQL-Code vermeiden und gleichzeitig wahrscheinlich unsere Laufzeitleistung erheblich verbessern können.

Auch wenn es viele Fälle gibt, in denen NoSQL-Datenbanken für bestimmte Datenstrukturen der richtige logische Ansatz sind, ist es oft schwer, die Flexibilität und die Power® des relationalen Modells zu übertreffen. Das Tolle an relationalen Datenbanken ist, dass man dieselben Daten sehr effektiv in verschiedene Formen für unterschiedliche Zwecke „aufteilen“ kann. Tricks wie Datenbankansichten ermöglichen es, mehrere Zuordnungen derselben Daten zu erstellen – etwas, das oft nützlich ist, wenn man eine Reihe zusammenhängender Abfragen eines komplexen Datenmodells implementiert. 

Für einen detaillierteren Vergleich von NoSQL und SQL siehe „SQL vs. NoSQL: Was ist der Unterschied?“

Wie wir bereits in einem früheren Artikel erörtert haben, ist es oft am einfachsten und unkompliziertesten, die Sichten zur Darstellung einer Reihe zusammenhängender Abfragen mit SQL zu implementieren, wenn die „untere Grenze“ eines Microservice eine Gruppe von Entitäten ist, die in einem Aggregat zusammen mit der zugehörigen Gruppe von Diensten gruppiert sind, die mit diesen Daten arbeiten.

Das haben wir zuerst im Kundenbeispiel gesehen, das zu unserem einfachen Beispiel mit Konto/Line-Item im vorherigen Artikel geführt hat. In diesem Fall gab es eine Bank, die sehr versucht hat, ein einfaches Modell genau wie dieses in einer dokumentenorientierten NoSQL-Datenbank zum Laufen zu bringen, wurde jedoch vom CAP-Theorem besiegt. Das Team hatte dieses Datenmodell jedoch aus den völlig falschen Gründen gewählt. Sie hatten sich dafür entschieden, die dokumentenorientierte Datenbank für all ihre verschiedenen Microservices zu verwenden, da sie eine einheitliche Architektur nicht wünschten.

In diesem Fall benötigten sie zwar alle Eigenschaften des ACID-Modus, aber kein Sharding (z. B. Partitionierung); ihr bestehendes System hatte jahrelang mit einer völlig akzeptablen Leistung auf einem relationalen Modell funktioniert, und sie rechneten nicht mit einem enormen Wachstum. Aber obwohl der Kern des Systems ACID-Transaktionen benötigte und keine Partitionierung erforderte, galt dies nicht unbedingt für alle anderen Teile des Systems. Es gibt einige Dinge, in denen SQL-Datenbanken besonders gut sind, und ACID-Transaktionen sind eines davon. In Microservices-Systemen ist es in der Regel der richtige Ansatz, die ACID-Transaktionen um den kleinsten Datensatz herum zu gruppieren, mit dem sie arbeiten.

SQL bedeutet jedoch nicht zwangsläufig traditionelle SQL-Datenbanken. Das ist möglich, und in vielen Microservices-Architekturen hat es sicherlich seinen Platz, aber SQL ist auch in mindestens zwei anderen Datenbanktypen implementiert, die für viele Teams, die Microservices implementieren, eine sinnvolle Wahl darstellen können. Die erste Kategorie ist „Small SQL“, das Gebiet von Open-Source-Datenbanken wie MySQL und Postgres. Für viele Teams, die Microservices implementieren, sind diese Datenbanken aus vielen Gründen eine durchaus vernünftige Wahl:

1. Teams, die bestehende Anwendungen in Microservices umwandeln, haben in der Regel Erfahrung sowohl mit SQL als auch mit objektrelationalen Mapping-Frameworks wie Hibernate oder Spring Persistence. Es ist sicherlich sinnvoll, dieses Wissen zu nutzen und dabei die Grenzen eines Microservice-Ansatzes einzuhalten.
2. Diese Datenbanken werden sehr gut unterstützt, sowohl von der Open-Source-Community als auch von vielen Anbietern, die Support dafür anbieten. Es ist relativ einfach, Dokumentation und Tutorials für diese Programme zu finden und Entwickler zu finden, die sich damit auskennen.
3. Diese Datenbanken sind klein und leicht genug, um leicht zu containerisieren und über die gleichen GitOps-Mechanismen bereitgestellt und aktualisiert zu werden, die Sie für Ihren Anwendungscode verwenden.
4. Diese Datenbanken werden in SaaS-Versionen von den meisten oder allen hyperskalaren Public Clouds unterstützt.

Der größte Nachteil dieser „kleinen SQL“-Datenbanken besteht darin, dass sie oft nicht die gleiche Skalierbarkeit (insbesondere im Hinblick auf Sharding) bieten wie Unternehmensdatenbanken. Dieses Problem wurde jedoch von einer neuen Generation von Datenbankanbietern und Open-Source-Projekten hervorragend gelöst, die die besten Eigenschaften von SQL-Datenbanken mit der Skalierbarkeit von NoSQL-Datenbanken verbinden. Zu diesen oft als „NewSQL“ bezeichneten Datenbanken gehören CockroachDB, Apache Trofidion und Clustrix.

Wenn Sie ACID-Transaktionen, eine SQL-Engine, die das relationale Modell vollständig unterstützt, sowie umfangreiche Skalierungs- und Sharding-Funktionen benötigen, sind NewSQL-Datenbanken eine gute Wahl für Teams. Diese Wahl hat allerdings ihren Preis – diese Datenbanken sind oft komplexer einzurichten und zu verwalten als die älteren „kleinen SQL“-Lösungen. Es ist auch schwieriger, in diesen Datenbanken geeignete Personen zu finden. Ungeachtet dessen müssen sie bei der Abwägung Ihrer Optionen sorgfältig berücksichtigt werden.

Wir haben einen rasanten Überblick über verschiedene Probleme der Datenbankmodellierung gegeben, die fälschlicherweise als Codierungsprobleme interpretiert werden können. Wenn Sie feststellen, dass Sie eines oder mehrere dieser Probleme haben, ist es möglicherweise besser, sich von Ihrem bestehenden Unternehmensdatenspeicher zu trennen und ihn mit einem anderen Typ von Datenspeicher neu zu gestalten. Unser Rat lautet in jedem Fall, langsam und schrittweise vorzugehen. Seien Sie sich bewusst, dass nicht alle Anwendungen alle Arten von Datenmodellen benötigen und dass Sie im Laufe der Zeit Funktionen und Verständnis für die operativen Funktionen Ihrer gewählten Datenbanken erwerben müssen, bevor Sie mit der Umsetzung in großem Maßstab beginnen.

Schließlich sollte man sich darüber im Klaren sein, dass der gesamte Microservices-Ansatz auf der Idee beruht, dass die Teams, die die einzelnen Microservices entwickeln, selbst entscheiden können, welcher Datenspeicher für sie der richtige ist. Das größte Problem, auf das wir bisher gestoßen sind (wie viele dieser Berichte angedeutet haben), besteht darin, eine einzige Lösung zur Darstellung und Speicherung von Daten zu finden, die für alle Situationen funktioniert. 

Ich habe schon oft erlebt, dass Teams mit den Realitäten des CAP-Theorems in Situationen konfrontiert wurden, in denen sie eigentlich gar keine NoSQL-Datenbank hätten verwenden sollen. Ebenso ist der Versuch, komplexe Berichte aus einer NoSQL-Datenbank durchzuführen, oft frustrierend. Andererseits zeigen die von uns dargestellten Situationen, dass das relationale Modell nicht allumfassend ist. Andere Models haben auch ihre Plätze. Der beste Ratschlag, den wir geben können, ist sicherzustellen, dass Ihre Teams die notwendige Autonomie haben, um für jeden Microservice das richtige Modell auszuwählen.

IBM® Garage ist darauf ausgelegt, schneller voranzukommen, smarter zu arbeiten und Innovationen auf eine Art und Weise zu entwickeln, die es ermöglicht, Unterbrechungen zu umgehen.