Die ersten vier Lektionen dieses Moduls haben Werkzeuge gezeigt: den Stern, Fabric, die Ladung, Spark. Diese Lektion tritt einen Schritt zurück. Welche Datenbanken braucht die Kladde überhaupt? Wem gehören die Daten, wenn sie in einer Auswertung landen? Wie kommt eine Löschung in jede Kopie, auch in alte Versionen einer Delta-Tabelle? Und was kostet eine Auswertung je Büro? Am Ende steht das ADR „Auswertungen der Kladde“, das Lektion 4.13.2 angekündigt hat: Lesereplikat, Fabric oder vorerst nichts.

Mehrere Datenbanken mit Maß

Microsofts Architecture Center sagt es nüchtern: Ein einzelner Datenspeicher bedient selten alle Zugriffsmuster gut, und die meisten Systeme im Betrieb nutzen mehrere Datenmodelle. Das heißt polyglotte Persistenz. Derselbe Leitfaden nennt den Weg dorthin, und der beginnt nicht bei den Produkten:

  1. Die Zugriffsmuster der Anwendung benennen: Lesen über einen Schlüssel, Aggregieren, Volltextsuche, Ähnlichkeit, Zeitfenster, ganze Dateien.
  2. Jedem Muster ein Datenmodell zuordnen.
  3. Erst dann Dienste in Azure auswählen, die dieses Modell anbieten.
  4. Nach Konsistenz, Latenz, Größe, Governance und Kosten bewerten.
  5. Modelle nur kombinieren, wo Zugriffsmuster oder Lebenszyklen deutlich auseinandergehen.

Der fünfte Punkt ist der wichtigste. Dazu gehört ein Hinweis aus demselben Leitfaden: Ein Dienst kann mehrere Modelle anbieten, und dann ist es besser, das passende Modell darin zu nehmen, als Modelle so zu kombinieren, dass der Betrieb schwerer wird. Azure SQL Database speichert neben Tabellen auch JSON, Graphen, Geodaten und Vektoren.

Zugriffsmuster Modell Dienste in Azure Bei der Kladde
Transaktionen über mehrere Zeilen und Tabellen relational Azure SQL Database, Azure Database for PostgreSQL alles Fachliche, der Event Store, der Zustand der Grains
ein Dokument mit wechselnder Form, Lesen über den Schlüssel Dokumente Azure Cosmos DB bisher kein Fall, der nicht in eine JSON-Spalte passt
Ähnlichkeit („Ausschreibungen wie diese“) Vektoren Azure SQL (Datentyp vector), Azure AI Search, Azure Cosmos DB noch kein Fall; wenn, dann zuerst in der eigenen Datenbank
viele Messwerte mit Zeitstempel, Fenster über die Zeit Zeitreihen Azure Data Explorer, Eventhouse in Fabric die Telemetrie liegt schon in Application Insights
große Mengen Geschichte, Aggregation über alles Analyse Microsoft Fabric, Azure Data Explorer, Azure Databricks Thema dieses Moduls

Jeder neue Datenspeicher bringt dieselbe Liste mit, die Sie in K4 Modul für Modul abgearbeitet haben: private Endpunkte und ein Platz im Netz (4.7.2), Identitäten und Rechte (4.8.5), Sicherung und Notfallplan (4.7.5), ein Eintrag im Datenverzeichnis (4.8.3), ein Weg für Auskunft und Löschung (4.8.4), Kosten je Büro (4.1.5) und Wissen im Team. Ein Datenmodell, das die vorhandene Datenbank kann, kostet nichts davon noch einmal.

Das gilt auch für die Dienste aus Modul 4.12. „Daten je Dienst“ aus Lektion 4.12.3 gibt jedem Dienst die Freiheit, seinen Speicher zu wählen. Eine Pflicht zur Vielfalt ist das nicht: Der Dienst Ausschreibungen hat eine eigene Datenbank, aber dieselbe Art von Datenbank wie der Kern.