Cosmos DB

Azure Cosmos DB ist ein global verteilter, multimodaler Datenbankdienst von Microsoft . Er bietet moderne Anwendungen hohe Verfügbarkeit, Skalierbarkeit und geringen Datenzugriff. Im Gegensatz zu traditionellen relationalen Datenbanken ist Cosmos DB eine NoSQL-Datenbank (d. h. „nicht nur SQL“, nicht „Null-SQL“) und Vektordatenbank ^{[ 1 ]} , was bedeutet, dass sie unstrukturierte, semistrukturierte, strukturierte und Vektordatentypen verarbeiten kann. ^{[ 2 ]}

Intern speichert Cosmos DB „Elemente“ in „Containern“ ^{[ 3 ].} Diese beiden Konzepte werden je nach verwendeter API unterschiedlich dargestellt (beispielsweise als „Dokumente“ in „Sammlungen“ bei Verwendung der MongoDB-kompatiblen API). Container sind in „Datenbanken“ gruppiert, die den Namensräumen über den Containern entsprechen. Container sind schemaunabhängig, d. h. beim Hinzufügen von Elementen wird kein Schema erzwungen.

Standardmäßig wird jedes Feld in jedem Element automatisch indiziert, was im Allgemeinen eine gute Leistung ohne Anpassung an spezifische Abfragemuster gewährleistet. Diese Standardeinstellungen können durch Festlegen einer Indizierungsrichtlinie geändert werden, die für jedes Feld den gewünschten Indextyp und die Genauigkeit festlegt. Cosmos DB bietet zwei Arten von Indizes:

• Bereich, unterstützender Bereich und ORDER BY-Abfragen
• räumlich, Unterstützung räumlicher Abfragen von Punkten, Polygonen und Linienketten, die in standardmäßigen GeoJSON- Fragmenten kodiert sind

Container können auch eindeutige Schlüsselbeschränkungen erzwingen, um die Datenintegrität zu gewährleisten. ^{[ 4 ]}

Jeder Cosmos-DB-Container stellt einen Änderungsfeed bereit, den Clients abonnieren können, um über neue hinzugefügte oder aktualisierte Elemente im Container benachrichtigt zu werden. ^{[ 5 ]} Seit dem 7. Juni 2021 werden Löschungen von Elementen nicht mehr über den Änderungsfeed gemeldet. Änderungen werden von Cosmos DB persistent gespeichert, sodass Änderungen von jedem beliebigen Zeitpunkt seit der Erstellung des Containers abgerufen werden können.

Eine Gültigkeitsdauer („ Time to Live “, TTL) kann auf Containerebene festgelegt werden, damit Cosmos DB Elemente nach einer bestimmten Zeit in Sekunden automatisch löscht. Dieser Countdown beginnt nach der letzten Aktualisierung des Elements. Bei Bedarf kann die Gültigkeitsdauer auch auf Elementebene angepasst werden.

Das im vorherigen Abschnitt beschriebene interne Datenmodell wird wie folgt dargestellt:

• eine proprietäre SQL-API.
• Fünf verschiedene Kompatibilitäts-APIs stellen Endpunkte bereit, die teilweise mit den Protokollen von MongoDB , Gremlin , Cassandra , Azure Table Storage und etcd kompatibel sind ; diese Kompatibilitäts-APIs ermöglichen es jeder kompatiblen Anwendung, sich über Standardtreiber oder SDKs mit Cosmos DB zu verbinden und es zu nutzen und gleichzeitig von den Kernfunktionen von Cosmos DB wie Partitionierung und globaler Verteilung zu profitieren.

Die SQL-API ermöglicht es Clients, Container und Elemente zu erstellen, zu aktualisieren und zu löschen. Elemente können mit einem schreibgeschützten, JSON -kompatiblen SQL-Dialekt abgefragt werden. ^{[ 8 ]} Da Cosmos DB eine JavaScript-Engine integriert , ermöglicht die SQL-API außerdem Folgendes:

• Gespeicherte Prozeduren sind Funktionen, die beliebig komplexe Operationen und Logik in einer ACID -konformen Transaktion bündeln. Sie sind von Änderungen während der Ausführung der gespeicherten Prozedur isoliert, und entweder sind alle Schreibvorgänge erfolgreich oder alle schlagen fehl, wodurch die Datenbank in einem konsistenten Zustand verbleibt. Gespeicherte Prozeduren werden in einer einzelnen Partition ausgeführt. Daher muss der Aufrufer beim Aufruf einer partitionierten Sammlung einen Partitionsschlüssel angeben. Gespeicherte Prozeduren können verwendet werden, um fehlende Funktionalitäten zu kompensieren. Beispielsweise wird die fehlende Aggregationsfunktion durch die Implementierung eines OLAP-Cubes als gespeicherte Prozedur im Open-Source-Projekt documentdb-lumenize ^{[ 9 ]} ausgeglichen .
• Trigger sind Funktionen, die vor oder nach bestimmten Operationen (z. B. beim Einfügen eines Dokuments) ausgeführt werden und die Operation entweder ändern oder abbrechen können. Trigger werden nur auf Anfrage ausgeführt.
• Benutzerdefinierte Funktionen (UDF) . Funktionen, die aus der SQL-Abfragesprache aufgerufen werden können und diese erweitern, um die begrenzten Funktionen von SQL auszugleichen.

Die SQL-API wird als REST- API bereitgestellt, die ihrerseits in verschiedenen SDKs implementiert ist, die offiziell von Microsoft unterstützt werden und für .NET Framework , .NET , ^{[ 10 ]} Node.js ( JavaScript ), Java und Python verfügbar sind .

Cosmos DB hat 2016 mit der Einführung partitionierter Container die automatische Partitionierung eingeführt. Im Hintergrund erstrecken sich partitionierte Container über mehrere physische Partitionen, wobei die Elemente anhand eines vom Client bereitgestellten Partitionsschlüssels verteilt werden. Cosmos DB entscheidet automatisch, auf wie viele Partitionen die Daten verteilt werden, abhängig von Größe und Durchsatzbedarf. Beim Hinzufügen oder Entfernen von Partitionen erfolgt der Vorgang ohne Ausfallzeit, sodass die Daten während der Neuverteilung auf die neuen oder verbleibenden Partitionen verfügbar bleiben.

Bevor partitionierte Container verfügbar waren, war es üblich, benutzerdefinierten Code zur Datenpartitionierung zu schreiben, und einige Cosmos DB SDKs unterstützten explizit verschiedene Partitionierungsschemata. Dieser Modus ist weiterhin verfügbar, wird aber nur empfohlen, wenn die Speicher- und Durchsatzanforderungen die Kapazität eines Containers nicht überschreiten oder wenn die integrierte Partitionierungsfunktion die Anwendungsanforderungen nicht erfüllt.

Entwickler können den gewünschten Durchsatz entsprechend der erwarteten Anwendungslast festlegen. Cosmos DB reserviert Ressourcen (Speicher, CPU und IOPS ), um den angeforderten Durchsatz zu gewährleisten und gleichzeitig die Latenz für Lese- und Schreibvorgänge im 99. Perzentil unter 10 ms zu halten . Der Durchsatz wird in Request Units (RUs) pro Sekunde angegeben. Das Lesen eines 1 KB großen Elements kostet 1 Request Unit (oder 1 RU). SELECT-Operationen mit der ID verbrauchen weniger RUs als DELETE-, UPDATE- und INSERT-Operationen für dasselbe Dokument. Umfangreiche Abfragen (z. B. Aggregationen wie COUNT) und die Ausführung gespeicherter Prozeduren können je nach Komplexität der erforderlichen Operationen Hunderte bis Tausende von RUs beanspruchen. ^{[ 11 ]} Die Abrechnung erfolgt mindestens stundenweise.

Der Durchsatz kann entweder auf Container- oder Datenbankebene bereitgestellt werden. Bei Bereitstellung auf Datenbankebene wird der Durchsatz auf alle Container innerhalb dieser Datenbank verteilt, wobei zusätzlich ein dedizierter Durchsatz für einzelne Container möglich ist. Der für einen Azure Cosmos-Container bereitgestellte Durchsatz ist exklusiv für diesen Container reserviert. ^{[ 12 ]} Standardmäßig beträgt die maximale Anzahl an RUs, die pro Datenbank und Container bereitgestellt werden können, 1.000.000 RU. Kunden können dieses Limit jedoch durch Kontaktaufnahme mit dem Kundensupport erhöhen lassen.

Als Beispiel für die Kostenberechnung: Bei Verwendung einer einzelnen Regionsinstanz benötigt das Zählen von 1.000.000 Datensätzen mit jeweils 1k in 5 Sekunden 1.000.000 RUs.0,008 $/ h , was 800 $ entspricht . Zwei Regionen verdoppeln die Kosten.

Cosmos DB-Datenbanken lassen sich so konfigurieren, dass sie in jeder der Microsoft Azure-Regionen (54 Regionen, Stand Dezember 2018) verfügbar sind. Dadurch können Anwendungsentwickler ihre Daten näher an den Standorten ihrer Benutzer platzieren. ^{[ 13 ]} Die Daten jedes Containers werden transparent über alle konfigurierten Regionen repliziert. Das Hinzufügen oder Entfernen von Regionen erfolgt ohne Ausfallzeiten oder Leistungseinbußen. Dank der Multi-Homing-API von Cosmos DB müssen Anwendungen beim Hinzufügen oder Entfernen von Regionen nicht aktualisiert oder neu bereitgestellt werden, da Cosmos DB die Anfragen automatisch an die verfügbaren und nächstgelegenen Regionen weiterleitet.

Die Datenkonsistenz ist in Cosmos DB konfigurierbar, sodass Anwendungsentwickler zwischen fünf verschiedenen Stufen wählen können: ^{[ 14 ]}

• Eventual garantiert keine bestimmte Reihenfolge und stellt lediglich sicher, dass die Replikate letztendlich konvergieren.
• Ein konsistentes Präfix fügt zusätzlich zu eventuellen weiteren Garantien auch Reihenfolgegarantien hinzu.
• Session ist auf eine einzelne Client-Verbindung beschränkt und gewährleistet im Wesentlichen eine Read-Your-Own-Writes-Konsistenz für jeden Client; es handelt sich um die Standard-Konsistenzstufe ^{[ 15 ].}
• Begrenzte Veralterung erweitert konsistente Präfixe, indem sichergestellt wird, dass Lesevorgänge nicht über x Versionen eines Elements oder ein bestimmtes Zeitfenster hinaus verzögert werden.
• Starke Konsistenz (oder Linearisierbarkeit ) stellt sicher, dass Clients immer die neueste global festgeschriebene Version lesen.

Der gewünschte Konsistenzgrad wird auf Kontoebene definiert, kann aber für jede Anfrage einzeln überschrieben werden, indem ein spezifischer HTTP-Header oder die entsprechende Funktion der SDKs verwendet wird. Alle fünf Konsistenzgrade wurden mithilfe der TLA+-Spezifikationssprache spezifiziert und verifiziert . Das TLA+-Modell ist als Open Source auf GitHub verfügbar. ^{[ 16 ]}

Das ursprüngliche Verteilungsmodell von Cosmos DB sieht eine einzige Schreibregion vor, während alle anderen Regionen als schreibgeschützte Replikate fungieren. Im März 2018 kündigte Microsoft eine neue Multi-Master-Funktion für Azure Cosmos DB an, die es ermöglicht, mehrere Regionen als Schreibreplikate einzusetzen. Diese Funktion stellte eine deutliche Verbesserung gegenüber dem ursprünglichen Modell mit einer einzigen Schreibregion dar, in der die anderen Regionen schreibgeschützt waren. Mit Multi-Master können gleichzeitige Schreibvorgänge aus verschiedenen Regionen zu potenziellen Konflikten führen. Diese lassen sich entweder mithilfe der standardmäßigen „Last Write Wins“-Richtlinie (LWW) oder eines benutzerdefinierten Konfliktlösungsmechanismus, beispielsweise einer JavaScript-Funktion, beheben. Die LWW-Richtlinie verwendet Zeitstempel, um den maßgeblichen Schreibvorgang zu ermitteln, während die benutzerdefinierte Option Entwicklern die Möglichkeit gibt, Konflikte durch anwendungsdefinierte Regeln zu behandeln. ^{[ 17 ]}

Diese im Mai 2020 angekündigte Funktion ^{[ 18 ]} stellt einen vollständig isolierten Spaltenspeicher dar, der umfangreiche Analysen von Betriebsdaten in Azure Cosmos DB ermöglicht, ohne die Transaktionsworkloads zu beeinträchtigen. Sie adressiert die Komplexitäts- und Latenzprobleme herkömmlicher ETL- Pipelines, die ein für die Online-Analyse optimiertes Datenrepository erfordern. Dies geschieht durch die automatische Synchronisierung der Betriebsdaten in einen separaten Spaltenspeicher, der für die optimierte Ausführung umfangreicher analytischer Abfragen geeignet ist und somit die Latenz dieser Abfragen verbessert.

Mithilfe von Microsoft Azure Synapse Link ^{[ 19 ]} für Cosmos DB lassen sich durch die direkte Anbindung von Synapse Analytics an den analytischen Speicher von Azure Cosmos DB hybride Transaktions-/Analyselösungen ohne ETL erstellen . Dies ermöglicht die Durchführung umfangreicher Analysen nahezu in Echtzeit direkt auf den Betriebsdaten.

Microsoft nutzt Cosmos DB in vielen seiner eigenen Anwendungen, ^{[ 20 ]} darunter Microsoft Office , Skype , Active Directory , Xbox und MSN .

Cosmos DB lässt sich mit anderen Azure-Diensten wie Azure App Services und Azure Traffic Manager kombinieren, um eine robustere Anwendung zu schaffen. ^{[ 21 ]}

Das Cloud-Kostenoptimierungstool Cosmos DB Profiler erkennt ineffiziente Datenabfragen in der Interaktion zwischen einer Anwendung und ihrer Cosmos DB-Datenbank. Der Profiler weist Benutzer auf Leistungsverluste und überhöhte Cloud-Kosten hin. Er gibt außerdem Empfehlungen zur Behebung dieser Probleme, indem er den Code isoliert und analysiert und die Benutzer direkt zur entsprechenden Stelle führt. ^{[ 22 ]}

• SQL ist eingeschränkt. Aggregationen sind auf die Funktionen COUNT, SUM, MIN, MAX und AVG beschränkt; GROUP BY oder andere in Datenbanksystemen übliche Aggregationsfunktionen werden nicht unterstützt. Gespeicherte Prozeduren können jedoch verwendet werden, um Aggregationen innerhalb der Datenbank zu implementieren. ^{[ 23 ]}
• SQL-Joins zwischen „Tabellen“ sind nicht möglich.
• Cosmos DB unterstützt ausschließlich reine JSON-Datentypen. Insbesondere fehlt die Unterstützung für Datums- und Zeitangaben, sodass diese Daten mithilfe der verfügbaren Datentypen gespeichert werden müssen. Beispielsweise können sie als ISO-8601-Zeichenkette oder Unix-Zeitstempel gespeichert werden. MongoDB , die Datenbank, mit der Cosmos DB am häufigsten verglichen wird, hat JSON in ihrer BSON-Spezifikation für die binäre Serialisierung erweitert, um neben herkömmlichen Zahlentypen, regulären Ausdrücken und dem Wert „Undefined“ auch Datums- und Zeitangaben abzudecken.

• Offizielle Website