Hotels und Fluggesellschaften liefern der Nordlicht Reisen GmbH ihre Angebote, und jeder Partner schickt andere Felder: Zimmerarten, Saisonzeiten, Zusatzleistungen, Gepäckregeln. Ein Schema, das alles abdeckt, gibt es nicht, und es ändert sich mit jedem neuen Partner. Das Portal liest diese Angebote an Kampagnentagen etwa zehnmal so oft wie sonst. Die Prüfung nennt das: eine Lösung für das Speichern teilstrukturierter Daten empfehlen. Teilstrukturiert heißt: Die Daten haben eine Struktur (Felder, Verschachtelung), aber nicht dieselbe für alle Einträge, meist als JSON.
Vorwissen. Den Unterschied zwischen relational und Dokument und Cosmos DB for NoSQL in fünf Begriffen (Konto, Datenbank, Container, Element, Partitionsschlüssel) lehrt K3 in Lektion 3.6.4; Azure SQL zeigt K3 in Lektion 3.6.1. Das wird hier nicht wiederholt. Neu sind Wahl der API, Konsistenz, Durchsatzmodus und Partitionsschlüssel nach Anforderung, samt den Grenzen, die sie kippen. Sicherung und Hochverfügbarkeit dieser Daten folgen in Lektion 3.4.
Die Anforderung
Alle Zahlen sind Annahmen der Aufgabe.
| Anforderung | Quelle | Messgröße (Annahme) |
|---|---|---|
| Angebote von etwa 120 Partnern mit je eigenen Feldern | Produkt | kein festes Schema; neue Felder ohne Umbau |
| Lesen überwiegt | Betrieb | 800 Lesezugriffe je Sekunde im Mittel, 8.000 an Kampagnentagen |
| Eigene Änderungen sofort sichtbar | Partnerbetreuung | Mitarbeitende eines Partners sehen ihre Änderung beim nächsten Lesen |
| Daten bleiben in der EU | Datenschutz | germanywestcentral plus eine zweite EU-Region zum Lesen |
| Ausfall der Hauptregion überstehen | Geschäftsführung | Verlust von höchstens 15 Minuten Schreibvorgängen |
| Keine Schlüssel im Code | Sicherheit | Anmeldung mit Managed Identity |
| Ein Großpartner (Fluggesellschaft) | Produkt | allein mehr als 60 GB Angebotsdaten |