Sie entwerfen eine global verteilte soziale App, die Benutzer-Timelines und Kommentare als JSON-Dokumente speichert. Benutzer müssen ihre eigenen Schreibvorgänge sofort sehen, während die regionsübergreifende Latenz gering bleiben muss. Schreibvorgänge werden gleichmäßig nach Benutzer verteilt. Welches Cosmos DB-Design sollten Sie wählen?

Die Wahl von Azure Cosmos DB SQL (Core) API mit Session-Konsistenz und einem Partitionsschlüssel von userId ist optimal. Die Session-Konsistenz stellt sicher, dass Benutzer ihre eigenen Schreibvorgänge sofort sehen (Read-Your-Own-Writes), was für soziale Apps entscheidend ist, während die regionsübergreifende Latenz gering bleibt, da sie weniger strenge Garantien als Strong-Konsistenz bietet. Der Partitionsschlüssel userId verteilt Schreibvorgänge gleichmäßig über die Benutzer, was Hot-Partitionen vermeidet und die Skalierbarkeit verbessert. Azure Cosmos DB for MongoDB mit Strong-Konsistenz würde die Latenz erhöhen. Azure Table Storage mit Eventual-Konsistenz erfüllt nicht die Anforderung, eigene Schreibvorgänge sofort zu sehen. Strong-Konsistenz mit einem Partitionsschlüssel von timestamp würde die Latenz ebenfalls erhöhen und wäre kein guter Partitionsschlüssel für gleichmäßige Verteilung. Gremlin API ist für Diagrammdatenbanken gedacht und Consistent Prefix erfüllt nicht die Read-Your-Own-Writes-Anforderung.