Seminar FoundationDB – Intensivseminar Anwendungsentwicklung und Datenmodelle

Das Intensivseminar vermittelt Durchgängige Entwicklung von Einsatzprofil und Schlüsselmodell über Transaktionen und Idempotenz bis zu Integrationsmustern und Record Layer. Die Themen werden von der fachlichen Einordnung über die Konfiguration beziehungsweise Implementierung bis zur kontrollierten Prüfung in einer zusammenhängenden Laborumgebung bearbeitet.

Jeder Themenblock enthält eine eigene Inhaltsübersicht, konkrete Arbeitsschritte und Prüfpunkte. Konfigurationen, Datenmodelle und Betriebsentscheidungen werden so dokumentiert, dass sie in Projekt- und Betriebsstandards übernommen werden können.

Verdichtete Themenfelder: Einführung und Architekturüberblick; Datenmodellierung mit Tuple, Subspace und Directory Layer; Transaktionen, Konflikte und Idempotenz; Entwicklung mit Go, Java und Python über gemeinsame Binding-Muster; Anwendungsarchitektur, Events und Integrationsmuster; Record Layer, Indizes und relationale Modelle.

Inhaltsübersicht

1. 1. Einsatzprofil und Systemgrenzen
2. 2. Fachliches Schlüsselraumdesign
3. 3. Tuple Layer und ordnungserhaltende Kodierung
4. 4. Subspaces und Namensräume
5. 5. ACID-Semantik, MVCC und Strict Serializability
6. 6. Retry-Loops und Fehlerklassifikation
7. 7. Konfliktbereiche und Konkurrenzdesign
8. 8. Unbekannte Commit-Ergebnisse und Idempotenz
9. 9. Outbox-, Inbox- und Deduplizierungsmuster
10. 10. Idempotente Workflows und Zustandsautomaten
11. 11. Record-Layer-Architektur und Einsatzgrenzen
12. 12. Architekturreview und Produktionsfreigabe

1. Einsatzprofil und Systemgrenzen

Kapitelinhaltsverzeichnis

1. 1.1 Einordnung und Zielsetzung
2. 1.2 Fachthemen
3. 1.3 Schritt-für-Schritt-Übung
4. 1.4 Prüfpunkte

Einordnung und Zielsetzung

Das Kapitel ordnet FoundationDB als verteilten Transaktionskern ein. Im Mittelpunkt stehen das Zusammenspiel von Schlüsselraum, Transaktionen und darüberliegenden Datenmodellen sowie die bewusste Abgrenzung zu Such-, Analyse- und Objektspeichern.

Fachthemen

• Transaktionaler, geordneter Schlüsselraum
• Layer-Prinzip und Anwendungslogik
• Geeignete und ungeeignete Workloads

Schritt-für-Schritt-Übung: ein belastbares Einsatzprofil erstellen

1. Schritt 1: Geschäftsvorgänge, Konsistenzanforderungen und erwartete Datenmengen erfassen.
2. Schritt 2: Lese-, Schreib- und Bereichszugriffe als konkrete Zugriffsmuster beschreiben.
3. Schritt 3: Funktionen identifizieren, die durch einen Layer oder einen ergänzenden Dienst bereitgestellt werden müssen.
4. Schritt 4: Ungeeignete Workloads wie unstrukturierte Volltextsuche oder lang laufende Massentransaktionen abgrenzen.
5. Schritt 5: Ein Zielbild mit Datenverantwortung, Schnittstellen und Betriebsgrenzen dokumentieren.

Prüfpunkte

• Die Konsistenzanforderungen sind pro Vorgang benannt.
• Jeder Zugriff lässt sich einem Schlüsselbereich zuordnen.
• Ergänzende Systeme sind mit klarer Verantwortung abgegrenzt.

2. Fachliches Schlüsselraumdesign

Kapitelinhaltsverzeichnis

1. 2.1 Einordnung und Zielsetzung
2. 2.2 Fachthemen
3. 2.3 Schritt-für-Schritt-Übung
4. 2.4 Prüfpunkte

Einordnung und Zielsetzung

Das Datenmodell beginnt mit den Zugriffsmustern, nicht mit einer tabellarischen Übertragung. Entitäten, Beziehungen und Sortieranforderungen werden in stabile Präfixe und Bereichsgrenzen übersetzt.

Fachthemen

• Entitäten und Zugriffsmuster
• Präfixhierarchie
• Hotspot- und Wachstumsrisiken

Schritt-für-Schritt-Übung: einen Schlüsselraum aus Zugriffsmustern ableiten

1. Schritt 1: Häufige Lese-, Schreib- und Scanvorgänge priorisieren.
2. Schritt 2: Entitäten und Mandanten als stabile Präfixebenen modellieren.
3. Schritt 3: Sortierfelder in der Reihenfolge der benötigten Bereichszugriffe anordnen.
4. Schritt 4: Monoton wachsende oder stark konzentrierte Präfixe auf Hotspot-Risiken prüfen.
5. Schritt 5: Schlüsselbeispiele und Bereichsgrenzen in einem Modellkatalog dokumentieren.

Prüfpunkte

• Die Umsetzung berücksichtigt Entitäten und Zugriffsmuster und ist reproduzierbar dokumentiert.
• Das Verhalten von Präfixhierarchie ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

3. Tuple Layer und ordnungserhaltende Kodierung

Kapitelinhaltsverzeichnis

1. 3.1 Einordnung und Zielsetzung
2. 3.2 Fachthemen
3. 3.3 Schritt-für-Schritt-Übung
4. 3.4 Prüfpunkte

Einordnung und Zielsetzung

Der Tuple Layer kodiert strukturierte Werte zu geordneten Schlüsseln. Ein konsistentes Schema ermöglicht sprachübergreifenden Zugriff und vermeidet fehleranfällige eigene Trennzeichenformate.

Fachthemen

• Datentypen und zusammengesetzte Schlüssel
• Sprachübergreifende Kompatibilität
• Prefix Ranges

Schritt-für-Schritt-Übung: ein Tuple-Schema implementieren

1. Schritt 1: Datentypen und natürliche Sortierreihenfolge der Schlüsselfelder festlegen.
2. Schritt 2: Zusammengesetzte Schlüssel mit dem Tuple Layer kodieren.
3. Schritt 3: Pack- und Unpack-Ergebnisse mit Grenzwerten und Sonderzeichen testen.
4. Schritt 4: Prefix Ranges für alle Hauptzugriffe ableiten.
5. Schritt 5: Kompatibilität zwischen den eingesetzten Sprachbindungen prüfen.

Prüfpunkte

• Die Umsetzung berücksichtigt Datentypen und zusammengesetzte Schlüssel und ist reproduzierbar dokumentiert.
• Das Verhalten von sprachübergreifende Kompatibilität ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

4. Subspaces und Namensräume

Kapitelinhaltsverzeichnis

1. 4.1 Einordnung und Zielsetzung
2. 4.2 Fachthemen
3. 4.3 Schritt-für-Schritt-Übung
4. 4.4 Prüfpunkte

Einordnung und Zielsetzung

Subspaces kapseln Präfixe und reduzieren Fehler bei der manuellen Schlüsselkonstruktion. Damit entstehen wiederverwendbare Namensräume für Entitäten, Indizes und Metadaten.

Fachthemen

• Präfixkapselung
• Unterräume und Wiederverwendung
• Sichere Range Clears

Schritt-für-Schritt-Übung: Subspaces für ein Domänenmodell strukturieren

1. Schritt 1: Einen Root-Subspace für Anwendung oder Tenant festlegen.
2. Schritt 2: Unterräume für Primärdaten, Indizes, Ereignisse und Metadaten definieren.
3. Schritt 3: Hilfsfunktionen für Schlüssel, Bereiche und Dekodierung bereitstellen.
4. Schritt 4: Range Reads und Range Clears ausschließlich innerhalb definierter Unterräume testen.
5. Schritt 5: Subspace-Versionen und Verantwortlichkeiten dokumentieren.

Prüfpunkte

• Die Umsetzung berücksichtigt Präfixkapselung und ist reproduzierbar dokumentiert.
• Das Verhalten von Unterräume und Wiederverwendung ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

5. ACID-Semantik, MVCC und Strict Serializability

Kapitelinhaltsverzeichnis

1. 5.1 Einordnung und Zielsetzung
2. 5.2 Fachthemen
3. 5.3 Schritt-für-Schritt-Übung
4. 5.4 Prüfpunkte

Einordnung und Zielsetzung

Die Transaktionsgarantien werden mit konkurrierenden Abläufen praktisch überprüft. Dabei wird zwischen Snapshot innerhalb einer Transaktion, Commit-Reihenfolge und dauerhafter Bestätigung unterschieden.

Fachthemen

• Snapshot einer Transaktion
• Optimistische Nebenläufigkeit
• Causal Read und Durability

Schritt-für-Schritt-Übung: Transaktionsgarantien experimentell prüfen

1. Schritt 1: Zwei parallele Clients mit kontrollierten Lese- und Schreibfolgen vorbereiten.
2. Schritt 2: Identische Read Versions und unterschiedliche Commit-Reihenfolgen beobachten.
3. Schritt 3: Einen echten Read-Write-Konflikt und einen konfliktfreien Blind Write erzeugen.
4. Schritt 4: Sichtbare Zustände vor und nach erfolgreichem Commit protokollieren.
5. Schritt 5: Die beobachteten Abläufe einem seriellen Ergebnis zuordnen.

Prüfpunkte

• Die Umsetzung berücksichtigt Snapshot einer Transaktion und ist reproduzierbar dokumentiert.
• Das Verhalten von optimistische Nebenläufigkeit ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

6. Retry-Loops und Fehlerklassifikation

Kapitelinhaltsverzeichnis

1. 6.1 Einordnung und Zielsetzung
2. 6.2 Fachthemen
3. 6.3 Schritt-für-Schritt-Übung
4. 6.4 Prüfpunkte

Einordnung und Zielsetzung

Retry-Loops sind ein fester Bestandteil der Clientprogrammierung. Die Schleife darf nur transaktionale Datenbankoperationen automatisch wiederholen; externe Nebenwirkungen benötigen eigene Kontrolle.

Fachthemen

• On_error und Backoff
• Transiente und nicht wiederholbare Fehler
• Nebenwirkungen außerhalb der Transaktion

Schritt-für-Schritt-Übung: einen sicheren Retry-Loop implementieren

1. Schritt 1: Transaktionsobjekt und Retry-Schleife nach Binding-Konvention aufbauen.
2. Schritt 2: Reads, Writes und Commit innerhalb des kontrollierten Blocks platzieren.
3. Schritt 3: Fehler an die Binding-Funktion für Backoff und Reset übergeben.
4. Schritt 4: Dateizugriffe, Nachrichtenversand und sonstige Nebenwirkungen aus der Schleife entfernen.
5. Schritt 5: Konflikte und transiente Fehler gezielt auslösen und Wiederholungsverhalten messen.

Prüfpunkte

• Die Umsetzung berücksichtigt on_error und Backoff und ist reproduzierbar dokumentiert.
• Das Verhalten von transiente und nicht wiederholbare Fehler ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

7. Konfliktbereiche und Konkurrenzdesign

Kapitelinhaltsverzeichnis

1. 7.1 Einordnung und Zielsetzung
2. 7.2 Fachthemen
3. 7.3 Schritt-für-Schritt-Übung
4. 7.4 Prüfpunkte

Einordnung und Zielsetzung

Konflikte entstehen aus überlappenden logischen Abhängigkeiten, nicht allein aus identischen Schreibschlüsseln. Ein gutes Design minimiert unnötige Read Conflict Ranges, ohne Konsistenz zu verlieren.

Fachthemen

• Read und Write Conflict Ranges
• Blind Writes und Snapshot Reads
• Konfliktdichte

Schritt-für-Schritt-Übung: Konflikte systematisch reduzieren

1. Schritt 1: Reads und Writes einer langsamen Transaktion als Schlüsselbereiche erfassen.
2. Schritt 2: Fachlich notwendige von unbeabsichtigten Konfliktbereichen trennen.
3. Schritt 3: Breite Reads durch präzisere Schlüssel oder materialisierte Metadaten ersetzen.
4. Schritt 4: Snapshot Reads nur dort einsetzen, wo veraltete Werte fachlich zulässig sind.
5. Schritt 5: Konfliktrate und fachliche Invarianten nach jeder Änderung erneut testen.

Prüfpunkte

• Die Umsetzung berücksichtigt Read und Write Conflict Ranges und ist reproduzierbar dokumentiert.
• Das Verhalten von Blind Writes und Snapshot Reads ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

8. Unbekannte Commit-Ergebnisse und Idempotenz

Kapitelinhaltsverzeichnis

1. 8.1 Einordnung und Zielsetzung
2. 8.2 Fachthemen
3. 8.3 Schritt-für-Schritt-Übung
4. 8.4 Prüfpunkte

Einordnung und Zielsetzung

Bei Kommunikationsfehlern kann der Client den Commit-Status nicht sicher kennen. Wiederholbare Geschäftsoperationen benötigen daher eine vor der Retry-Schleife erzeugte Identität und einen transaktionalen Abschlussnachweis.

Fachthemen

• Commit_unknown_result
• Deterministische Operations-ID
• Deduplizierungsschlüssel

Schritt-für-Schritt-Übung: einen idempotenten Geschäftscommit entwerfen

1. Schritt 1: Eine stabile Operations-ID außerhalb der Retry-Schleife erzeugen.
2. Schritt 2: Einen Deduplizierungsschlüssel aus Operation und Fachobjekt ableiten.
3. Schritt 3: Zu Beginn der Transaktion prüfen, ob der Abschlussnachweis bereits existiert.
4. Schritt 4: Fachänderung und Abschlussnachweis gemeinsam committen.
5. Schritt 5: Unbekannte Ergebnisse und wiederholte Aufrufe durch Fehlerinjektion testen.

Prüfpunkte

• Die Umsetzung berücksichtigt commit_unknown_result und ist reproduzierbar dokumentiert.
• Das Verhalten von deterministische Operations-ID ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

9. Outbox-, Inbox- und Deduplizierungsmuster

Kapitelinhaltsverzeichnis

1. 9.1 Einordnung und Zielsetzung
2. 9.2 Fachthemen
3. 9.3 Schritt-für-Schritt-Übung
4. 9.4 Prüfpunkte

Einordnung und Zielsetzung

Outbox und Inbox verbinden transaktionale Zustandsänderungen mit mindestens einmal zugestellten Nachrichten. FoundationDB übernimmt den atomaren lokalen Commit; externe Zustellung bleibt idempotent.

Fachthemen

• Atomarer Zustands- und Ereigniscommit
• Deduplizierung
• Asynchrone Zustellung

Schritt-für-Schritt-Übung: eine zuverlässige Nachrichtenzustellung umsetzen

1. Schritt 1: Operations-ID und Ereignis-ID außerhalb der Retry-Schleife erzeugen.
2. Schritt 2: Fachzustand und Outbox-Eintrag in derselben Transaktion schreiben.
3. Schritt 3: Dispatcher liest geordnet, sendet und markiert den Fortschritt idempotent.
4. Schritt 4: Empfänger prüft eine Inbox- oder Deduplizierungskennung.
5. Schritt 5: Absturz vor und nach Versand sowie wiederholte Zustellung testen.

Prüfpunkte

• Die Umsetzung berücksichtigt atomarer Zustands- und Ereigniscommit und ist reproduzierbar dokumentiert.
• Das Verhalten von Deduplizierung ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

10. Idempotente Workflows und Zustandsautomaten

Kapitelinhaltsverzeichnis

1. 10.1 Einordnung und Zielsetzung
2. 10.2 Fachthemen
3. 10.3 Schritt-für-Schritt-Übung
4. 10.4 Prüfpunkte

Einordnung und Zielsetzung

Mehrstufige Workflows werden als explizite Zustandsautomaten modelliert. Jeder Übergang ist klein, prüfbar und bei Wiederholung wirkungsgleich.

Fachthemen

• Operations-ID
• Zustandsübergänge
• Kompensation und Wiederaufnahme

Schritt-für-Schritt-Übung: einen wiederaufnehmbaren Workflow modellieren

1. Schritt 1: Zulässige Zustände und Übergänge formal festlegen.
2. Schritt 2: Operations- und Workflow-ID stabil erzeugen.
3. Schritt 3: Jeden Übergang mit erwartetem Ausgangszustand transaktional prüfen.
4. Schritt 4: Externe Schritte durch vorbereitete und bestätigte Zustände umschließen.
5. Schritt 5: Abbruch, Wiederholung und Kompensation für jeden Übergang testen.

Prüfpunkte

• Die Umsetzung berücksichtigt Operations-ID und ist reproduzierbar dokumentiert.
• Das Verhalten von Zustandsübergänge ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

11. Record-Layer-Architektur und Einsatzgrenzen

Kapitelinhaltsverzeichnis

1. 11.1 Einordnung und Zielsetzung
2. 11.2 Fachthemen
3. 11.3 Schritt-für-Schritt-Übung
4. 11.4 Prüfpunkte

Einordnung und Zielsetzung

Der Record Layer ergänzt den Schlüssel-Wert-Kern um Schemas, Datensätze, Indizes und Abfragen. Die Architektur trennt FoundationDB-Cluster, stateless Anwendungsschicht und Schema-Lebenszyklus.

Fachthemen

• Java-Bibliothek über FoundationDB
• Record-orientierte und relationale API
• Stateless Services

Schritt-für-Schritt-Übung: ein Record-Layer-Zielbild erstellen

1. Schritt 1: Fachliche Datensätze, Abfragen und Mandantenanforderungen erfassen.
2. Schritt 2: Niedrige Record API und relationale SQL/JDBC-Schnittstelle hinsichtlich Reife und Bedarf vergleichen.
3. Schritt 3: Stateless Serviceinstanzen und FoundationDB-Zugriff planen.
4. Schritt 4: Keyspace, Metadaten und Store Context voneinander abgrenzen.
5. Schritt 5: Betrieb, Versionierung und Recovery in das Gesamtzielbild aufnehmen.

Prüfpunkte

• Die Umsetzung berücksichtigt Java-Bibliothek über FoundationDB und ist reproduzierbar dokumentiert.
• Das Verhalten von record-orientierte und relationale API ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.

12. Architekturreview und Produktionsfreigabe

Kapitelinhaltsverzeichnis

1. 12.1 Einordnung und Zielsetzung
2. 12.2 Fachthemen
3. 12.3 Schritt-für-Schritt-Übung
4. 12.4 Prüfpunkte

Einordnung und Zielsetzung

Das Review verbindet Anwendung und Betrieb. Ein Design gilt erst dann als freigabefähig, wenn Invarianten, Lastgrenzen, Wiederherstellung und Störungsverhalten nachgewiesen sind.

Fachthemen

• Datenmodell und Transaktionen
• Betrieb, Sicherheit und Recovery
• Last- und Fehlertests

Schritt-für-Schritt-Übung: eine Architekturentscheidung freigeben

1. Schritt 1: Zielbild, Schlüsselraum und Transaktionsinvarianten reviewen.
2. Schritt 2: Abhängigkeiten, Sicherheitsgrenzen und Betriebsverantwortung prüfen.
3. Schritt 3: Lastprofil, Kapazitätsmodell und Hotspot-Risiken bewerten.
4. Schritt 4: Backup-, Restore- und Ausfallszenarien gegen die Schutzziele testen.
5. Schritt 5: Offene Risiken mit Eigentümer, Frist und Freigabekriterium dokumentieren.

Prüfpunkte

• Die Umsetzung berücksichtigt Datenmodell und Transaktionen und ist reproduzierbar dokumentiert.
• Das Verhalten von Betrieb, Sicherheit und Recovery ist mit einem positiven und einem negativen Testfall geprüft.
• Abbruch-, Rückfall- und Eskalationskriterien sind eindeutig benannt.