Anforderungsanalyse und Schemaentwurf

In dieser Abschlusslektion wenden Sie Ihr gesamtes Wissen aus dem MongoDB-Kurs an, um eine produktionsreife Anwendung von Grund auf zu entwerfen. Wir erstellen eine Multi-Vendor-E-Commerce-Plattform – eine Domäne, die umfangreich genug ist, um Entscheidungen zwischen Einbetten und Referenzieren, die Indexplanung, den Entwurf von Aggregationen und Sicherheitsaspekte zu behandeln. Der Prozess beginnt mit der Anforderungsanalyse, die alle nachfolgenden Schemaentscheidungen bestimmt.

Beginnen Sie damit, die zentralen Entitäten und Vorgänge der Anwendung aufzulisten. Für unsere E-Commerce-Plattform sind dies: Entitäten – Users, Vendors, Products, Orders, Reviews, Carts; Vorgänge – Produkte nach Kategorie durchsuchen, nach Schlüsselwörtern suchen, Bestellungen aufgeben, Zahlungen verarbeiten, Lieferungen verfolgen und Bewertungen verfassen. Jeder Vorgang entspricht einer oder mehreren MongoDB-Abfragen, und diese Abfragen bestimmen die Schemaentscheidungen.

Zugriffsmuster sind die konkreten Abfragen, die Ihre Anwendung ausführen wird. Dokumentieren Sie sie vor dem Entwurf des Schemas präzise – das Schema sollte den Abfragen dienen, nicht umgekehrt. Erfassen Sie für jedes Muster: die Filterfelder, Sortierfelder, projizierten Felder und die geschätzte Häufigkeit. Häufig verwendete Muster bestimmen die Indexierungs- und Einbettungsentscheidungen. Bei selten verwendeten Mustern kann der zusätzliche Aufwand durch Joins oder eine Aggregationspipeline akzeptabel sein.

Das Produktdokument wird im System am häufigsten gelesen. Wenden Sie die gelernten Muster an: Computed Pattern für vorab berechnete Statistiken (avgRating, reviewCount); Subset Pattern, um nur die fünf besten Bewertungen einzubetten; Extended Reference, um den Namen und das Logo des Anbieters neben vendorId einzubetten. Dadurch entfallen bei 95 % der Darstellungen von Produktseiten Joins.

Bestellungen sind ein klassischer Fall für ein Snapshot-Dokument: Sie halten den Stand von Preisen und Adressen zum Zeitpunkt des Kaufs fest, nicht den aktuellen Stand. Betten Sie die vollständige Lieferadresse ein (keine Referenz auf die aktuelle Adresse des Benutzers), ebenso den Produktschnappschuss (Name, Preis und Bild zum Kaufzeitpunkt) sowie den Namen des Anbieters. So bleiben Bestellungen korrekt, auch wenn sich Preise ändern oder Anbieter ihre Profile aktualisieren.

Wenden Sie für jede Beziehung die Entscheidungs-Checkliste an: Wie oft wird sie gemeinsam abgerufen? (Immer: einbetten, selten: referenzieren); Wie oft ändern sich die referenzierten Daten? (Selten: einbetten, häufig: referenzieren); Wird das eingebettete Array unbeschränkt wachsen? (Ja: referenzieren, begrenzt: einbetten); Wird nach den Daten unabhängig abgefragt? (Ja: separate Collection, immer über das übergeordnete Dokument abgerufen: einbetten).

Fügen Sie den Collections products und orders JSON-Schema-Validatoren hinzu, um zu verhindern, dass fehlerhaft formatierte Dokumente Ihre Daten beschädigen. Erzwingen Sie Pflichtfelder (price muss eine positive Zahl sein, status muss einem der gültigen Enum-Werte entsprechen) und setzen Sie validationAction: 'error', damit ungültige Schreibvorgänge sofort abgelehnt werden, statt nur eine Warnung auszugeben.

Definieren Sie für jedes häufig verwendete Zugriffsmuster Indizes. Verwenden Sie für zusammengesetzte Indizes die ESR-Regel (Equality → Sort → Range). Erstellen Sie Indizes nur für häufig ausgeführte Abfragen – ungenutzte Indizes beeinträchtigen die Schreibperformance und verbrauchen RAM. Dokumentieren Sie den Zweck jedes Index, damit das Team redundante Indizes entfernen kann, wenn sich die Zugriffsmuster weiterentwickeln.

Eine zentrale Herausforderung im E-Commerce ist das Verhindern von Überverkäufen: Zwei Benutzer dürfen nicht beide den letzten verfügbaren Artikel kaufen können. Verwenden Sie MongoDBs atomare Methode findOneAndUpdate mit der Prüfbedingung stock: { $gt: 0 }. Die Aktualisierung ist nur erfolgreich, wenn Bestand verfügbar ist, und die Verringerung erfolgt atomar – eine Race Condition ist somit ausgeschlossen.

Entwerfen Sie eine Aggregationspipeline für eine Verkaufsübersicht, die den Umsatz pro Anbieter für die letzten 30 Tage ausgibt. Dies ist ein klassischer Fall, in dem die Aggregationspipeline eine komplexe Berechnung auf Anwendungsseite ersetzt. Die Pipeline filtert aktuelle Bestellungen, entpackt die Artikel, gruppiert nach Anbieter und sortiert nach dem Gesamtumsatz.

Validieren Sie vor dem Übergang in die Produktion jede kritische Abfrage mit explain('executionStats'). Stellen Sie sicher, dass alle häufig verwendeten Abfragen im gewinnenden Plan IXSCAN (nicht COLLSCAN) anzeigen, dass docsExamined nahe an nReturned liegt und dass totalKeysExamined angemessen ist. Jede Abfrage mit COLLSCAN oder einem hohen Verhältnis von docsExamined zu nReturned benötigt einen Index.

In dieser Lektion haben Sie gelernt: Anforderungsanalyse und die Dokumentation von Zugriffsmustern kommen vor dem Schemaentwurf – das Schema dient den Abfragen, nicht umgekehrt; ein gutes Produktdokument kombiniert Extended Reference, Computed Pattern und Subset Pattern, um Joins im häufig genutzten Lesepfad zu vermeiden; und atomare Aufrufe von findOneAndUpdate mit Prüfbedingungen verhindern Überverkäufe, ohne Transaktionen zu benötigen. Als Nächstes definieren wir die Indexstrategie und validieren jeden Index mit explain().