Seit der ersten Konzeption als cloudbasierte Datenbank im Jahr 2010 haben wir Azure Cosmos DB sorgfältig entworfen und entwickelt, um die drei fundamentalen Eigenschaften der Cloud vollständig zu nutzen:
- Globale Verteilung durch transparente Multimasterreplikation
- Flexible Skalierbarkeit von Durchsatz und Speicher weltweit durch horizontale Partitionierung
- Differenzierte Mehrmandantenfähigkeit durch stark ressourcenorientierte Systemzusammenstellungen von der Datenbank-Engine bis zum Replikationsprotokoll
In Cosmos DB kommen diese drei Eigenschaften auf eine ganz neue Art zusammen, um eine flexible Skalierung für Schreib- und Lesevorgänge auf der ganzen Welt mit einer garantierten Latenz im einstelligen Millisekundenbereich am 99. Perzentil und mit einer Hochverfügbarkeit von 99,999 % zu bieten. Der Dienst repliziert Ihre Daten transparent und stellt Ihnen ein einziges Systemimage Ihrer global verteilten Cosmos-Datenbank bereit. Sie haben dabei die Wahl zwischen fünf genau definierten Konsistenzmodellen (präzise Spezifikation über TLA+), während Ihre Benutzer von überall auf der Welt Lese- und Schreibvorgänge durchführen können. Seit der Einführung im letzten Jahr bestätigt das Wachstum bei diesem Dienst unsere Entwurfsentscheidungen – aber auch unsere technischen Kompromisse.
Unvergleichlich schnelle, global skalierbare Schreibvorgänge
Da Cosmos DB zu den Basisdiensten von Azure gehört, steht er standardmäßig in allen Azure-Regionen zur Verfügung. Zum Zeitpunkt der Erstellung dieses Artikels ist Cosmos DB in mehr als 50 geografischen Regionen im Einsatz. Zehntausende Kunden haben für ihre Cosmos-Datenbanken eine globale Replikation zwischen 2 und über 50 Regionen konfiguriert.
Auch wenn unsere Kunden ihre Cosmos-Datenbanken auf mehrere Regionen ausweiten können, war es ihnen bisher nur möglich, eine diese Regionen für Schreibvorgänge (und Lesevorgänge) festzulegen, während die anderen Regionen lediglich für Lesevorgänge genutzt werden konnten. Nach intensiven Tests mithilfe interner Microsoft-Workloads für mehrere Jahre freuen wir uns, heute bekannt geben zu können, dass Sie Ihre Cosmos-Datenbanken nun auch mit mehreren Schreibregionen konfigurieren können (also als Multimasterkonfiguration). Diese Funktionalität bietet Ihnen folgende Vorteile:
- Verfügbarkeit von 99,999 % für Schreib- und Lesevorgänge – weltweit: Über die Verfügbarkeit von 99,999 % für das Lesen hinaus bietet Cosmos DB nun auch eine Verfügbarkeit von 99,999 % für Schreibvorgänge unter SLAs mit finanzieller Absicherung an.
- Flexible Skalierbarkeit von Schreib- und Lesevorgängen – weltweit: Neben den Lesevorgängen können Sie nun auch die Schreibvorgänge auf der ganzen Welt skalieren. Der für Ihre Anwendung in einem Cosmos DB-Container (oder einer Datenbank) konfigurierte Durchsatz wird für alle Regionen unter SLAs mit finanzieller Absicherung garantiert.
- Latenzen im einstelligen Millisekundenbereich für Schreib- und Lesevorgänge am 99. Perzentil – weltweit: Neben den garantierten Latenzen im einstelligen Millisekundenbereich für Lesevorgänge bietet Cosmos DB nun eine Latenz < 10 ms für Schreibvorgänge am 99. Perzentil in sämtlichen Regionen weltweit unter SLAs mit finanzieller Absicherung.
- Mehrere klar definierte Konsistenzmodelle: Das Replikationsprotokoll von Cosmos DB bietet fünf klar definierte, praktische und intuitive Konsistenzmodelle für das problemlose Erstellen funktionierender global verteilter Anwendungen. Darüber hinaus stehen auch die TLA+-Spezifikationen der höchsten Ebene für die Konsistenzmodelle zur Verfügung.
- Unbegrenzte Endpunktskalierbarkeit: Das Replikationsprotokoll von Cosmos DB dient der einheitlichen Skalierung über Hunderte Rechenzentren und Milliarden von Edgegeräten hinweg. Für die Architektur sind eine Azure-Region oder ein Edgegerät gleich – beide können Cosmos DB-Replikate hosten und als echte Peers an der Multimasterreplikation teilhaben.
- Multimaster-MongoDB, Cassandra, SQL, Gremlin und Table Storage: Als Datenbank für mehrere Modelle und APIs bietet Cosmos DB native Unterstützung für Wire Protocol für die APIs zu SQL (Cosmos DB), Cassandra (CQL), MongoDB, Table Storage und Gremlin. Sie verfügen mit Cosmos DB über einen vollständig verwalteten, sicheren, kompatiblen, kostengünstigen und serverlosen Datenbankdienst für Ihre MongoDB- und Cassandra-Anwendungen, die jeweils ebenfalls durch branchenweit führende und umfassende SLAs gedeckt sind. Die oben aufgeführten Funktionen stehen nun für alle von Cosmos DB unterstützten APIs zur Verfügung, einschließlich Cassandra, MongoDB, Gremlin, Table Storage und SQL. Sie können damit nun z.B. eine global verteilte Multimaster-Datenbank von MongoDB oder eine grafische Apache Gremlin-Datenbank durch Cosmos DB unterstützen.
Jahrzehnte der Forschung + präzises Engineering = Cosmos DB
Bei der Einführung von Cosmos DB im letzten Jahr haben wird eine technische Übersicht zu Cosmos DB geschrieben und um ein Videointerview mit dem Turing Award-Gewinner Dr. Leslie Lamport ergänzt, in dem die technischen Grundlagen von Cosmos DB beschrieben werden. In Fortsetzung dieser Tradition finden Sie hier das neue Videointerview mit Leslie Lamport. Darin werden die Weiterentwicklung der Architektur von Cosmos DB und die Anwendung von TLA+ bei der Entwicklung des neuen Replikationsprotokolls beschrieben. Außerdem erfahren Sie, wie in Cosmos DB Jahrzehnte der Forschung an verteilten Systemen von Paxos an epidemischen Protokollen mit herausragendem Engineering gekoppelt wurden, damit Sie Apps auf „kosmischer“ Ebene entwickeln können.
Dieser Blogbeitrag befasst sich etwas genauer mit der global verteilten Architektur von Cosmos DB und der neuen Funktion zur Aktivierung mehrerer Regionen mit Schreibzugriff auf Ihre Cosmos-Datenbank. In den folgenden Abschnitten besprechen wir das Systemmodell für die globale Verteilung in Cosmos DB im Zusammenhang mit dem Anti-Entropie-Design für die Skalierung von Schreibvorgängen auf der ganzen Welt.
Systemmodell für die globale Verteilung
Der Cosmos DB-Dienst ist einer der Basisdienste von Azure und wird daher in sämtlichen Azure-Regionen weltweit, einschließlich der öffentlichen, Sovereign, DoD- und Government-Clouds, bereitgestellt. Innerhalb eines Rechenzentrums wird der Cosmos DB-Dienst auf umfangreichen „Stamps“ von Computern bereitgestellt und verwaltet, die jeweils über dedizierten lokalen Speicher verfügen. Innerhalb eines Rechenzentrums wird Cosmos DB in vielen Clustern bereitgestellt, die jeweils in der Lage sind, mehrere Hardwaregenerationen auszuführen. Die Computer in einem Cluster werden in der Regel auf 10–20 Fehlerdomänen aufgeteilt.
Abbildung 1: Systemtopologie
Globale Verteilung ist der Schlüssel in Cosmos DB: Kunden können jederzeit mit wenigen Klicks (oder programmgesteuert mit einem einzigen API-Aufruf) eine beliebige Anzahl von geografischen Regionen hinzufügen, um sie ihrer Cosmos-Datenbank zuzuordnen, oder sie entfernen. Eine Cosmos-Datenbank besteht wiederum aus einer Reihe von Cosmos-Containern. In Cosmos DB dienen Container als logische Einheit für die Verteilung und Skalierung. Die Sammlungen, Tabellen und Diagramme, die Sie erstellen, werden (intern) als Cosmos-Container dargestellt. Container sind vollständig schemaunabhängig und stellen einen Gültigkeitsbereich für Abfragen dar. Sämtliche Daten in einem Cosmos-Container werden bei der Erfassung automatisch indiziert. Dadurch können Benutzer die Daten abfragen, ohne sich um das Schema oder die Indexverwaltung kümmern zu müssen, was besonders in einem global verteilten Setup hilfreich ist.
Wie in Abbildung 2 zu sehen, sind die Daten in einem Container über zwei Dimensionen verteilt:
- Innerhalb einer bestimmten Region werden die Daten in einem Container mithilfe eines Partitionsschlüssels, den Sie angeben, verteilt und transparent von den zugrunde liegenden Ressourcenpartitionen (lokale Verteilung) verwaltet.
- Jede Ressourcenpartition wird außerdem über geografische Regionen repliziert (globale Verteilung).
Wenn eine App den Durchsatz in einem Cosmos-Container mithilfe von Cosmos DB elastisch skaliert (oder zusätzlichen Speicher verbraucht), führt Cosmos DB im Hintergrund die Vorgänge zur Partitionsverwaltung (z.B. Teilen, Klonen, Löschen usw.) in sämtlichen Regionen durch. Unabhängig von Skalierung, Verteilung oder Ausfällen stellt Cosmos DB weiterhin ein einzelnes Systemimage der Daten in den Containern bereit, die global auf eine beliebige Anzahl von Regionen verteilt sind.
Abbildung 2: Verteilung von Ressourcenpartitionen über zwei Dimensionen und mehrere Regionen weltweit
Physisch wird eine Ressourcenpartition durch eine Gruppe von Replikaten implementiert, die als Replikatgruppe bezeichnet wird. Jeder Computer hostet Hunderte von Replikaten für verschiedene Ressourcenpartitionen innerhalb eines festen Satzes von Prozessen (siehe Abbildung 1). Die zu den Ressourcenpartitionen gehörenden Replikate werden dynamisch und mit einem Lastenausgleich auf den Computern in einem Cluster sowie den Rechenzentren in einer Region verteilt.
Ein Replikat gehört eindeutig zu einem Cosmos DB-Mandanten. Jedes Replikat hostet eine Instanz der Datenbank-Engine von Cosmos DB, die die Ressourcen und die zugehörigen Indizes verwaltet. Die Datenbank-Engine von Cosmos DB arbeitet nach einem ARS-basierten (Atom Record Sequence) Typensystem1. Die Engine ist vollständig unabhängig von jeglichem Schema und verwischt damit die Grenzen zwischen der Struktur und den Instanzenwerten von Datensätzen. Vollständige Schemaunabhängigkeit erreicht Cosmos DB durch die automatische und effiziente Indizierung von allen Elementen schon bei der Erfassung. Damit können Benutzer ihre global verteilten Daten abfragen, ohne sich um das Schema oder die Indexverwaltung kümmern zu müssen. Die Datenbank-Engine von Cosmos DB besteht wiederum aus Komponenten. Dazu gehören die Implementierung verschiedener Koordinationselemente, Language Runtimes, der Abfrageprozessor und die Untersysteme, die für die transaktionale Speicherung und Indizierung der Daten verantwortlich sind. Zu Gewährleistung von Dauerhaftigkeit und Hochverfügbarkeit speichert die Datenbank-Engine ihre Daten und ihren Index auf SSD-Datenträgern und repliziert sie mit anderen Instanzen der Datenbank-Engine innerhalb der Replikatgruppen. Größere Mandanten benötigen mehr Durchsatz und Speicherplatz und verfügen daher über größere und/oder mehr Replikate (umgekehrt gilt dasselbe). Jede Komponente des Systems ist vollständig asynchron – kein Thread wird jemals gesperrt, und jeder Thread verrichtet kurzfristige Aufgaben, die keine unnötigen Threadwechsel erfordern. Ratenlimits und Rückstaus werden auf den gesamten Stapel von der Erfassungssteuerung bis zu allen E/A-Pfaden aufgeteilt. Unsere Datenbank-Engine ist darauf ausgelegt, Parallelität präzise zu steuern und für einen hohen Durchsatz zu sorgen und dabei minimale Systemressourcen zu verbrauchen.
Die globale Verteilung von Cosmos DB beruht auf zwei wichtigen Abstraktionen: Replikatgruppen und Partitionsgruppen. Eine Replikatgruppe ist ein modularer Lego-Stein für die Steuerung, und eine Partitionsgruppe ist eine dynamische Überlagerung einer oder mehrerer geografisch verteilter Ressourcenpartitionen. Damit Sie genau verstehen können, wie die globale Verteilung funktioniert, müssen Sie diese beiden Abstraktionen verstanden haben.
Replikatgruppen – Lego-Steine für die Koordination
Eine Ressourcenpartition ist eine selbst verwaltete Gruppe von Replikaten mit dynamischem Lastenausgleich, die auf mehrere Fehlerdomänen – eine Replikatgruppe – verteilt sind. Die Gruppe implementiert gemeinsam das Protokoll mit dem replizierten Zustand des Computers, damit die Daten in der Ressourcenpartition hochverfügbar, dauerhaft und absolut konsistent bleiben. Die Mitgliedschaft N in der Replikatgruppe ist dynamisch – sie variiert basierend auf den Ausfällen, Verwaltungsvorgängen und der Zeit für die Neuerstellung/Wiederherstellung von fehlerhaften Replikaten zwischen NMin und NMax. Je nach der Art der Mitgliedschaftsänderung konfiguriert das Replikationsmodell auch die Quorumgröße für Lese- und Schreibvorgänge neu. Für eine einheitliche Verteilung des Durchsatzes, der einer bestimmten Ressourcenpartition zugewiesen ist, gelten zwei Paradigmen: Zum einen ist der Aufwand für die Verarbeitung der Schreibanforderungen an den Leader höher als für die Anwendung von Updates auf den Followern. Aus diesem Grund werden dem Leader mehr Systemressourcen als den Followern zugewiesen. Zum anderen wird das Lesequorum für eine bestimmte Konsistenzstufe so weit wie möglich ausschließlich aus Followerreplikaten zusammengestellt. Die Einbeziehung des Leaders in Lesevorgänge wird vermieden, außer wenn dies absolut unumgänglich ist. Wir nutzen eine Reihe von Ideen aus der Forschung zur Beziehung zwischen Last und Kapazität in quorumbasierten Systemen für die fünf von Cosmos DB unterstützten Konsistenzmodelle.
Partitionsgruppen – dynamische, geografisch verteilte Überlagerungen
Eine Gruppe von Ressourcenpartitionen (jeweils eine aus jeder für die Cosmos-Datenbank konfigurierten Region) dient der Verwaltung derselben Schlüsselsätze, die in allen konfigurierten Regionen repliziert werden. Dieses höhere Koordinationselement wird als Partitionsgruppe bezeichnet. Diese stellt eine geografisch verteilte, dynamische Überlagerung der Ressourcenpartitionen für die Verwaltung eines bestimmten Schlüsselsatzes dar. Während der Gültigkeitsbereich einer Ressourcenpartition (also einer Replikatgruppe) auf einen Cluster beschränkt ist, kann eine Partitionsgruppe Cluster, Rechenzentren und geografische Regionen überschreiten (Abbildungen 2 und 3).
Abbildung 3: Partitionsgruppe als dynamische Überlagerung von Ressourcenpartitionen
Sie können sich eine Partitionsgruppe als eine geografisch verteilte „Superreplikatgruppe“ vorstellen, die mehrere Replikatgruppen mit denselben Schlüsselsätzen umfasst. Wie bei einer Replikatgruppe ist auch bei einer Partitionsgruppe die Mitgliedschaft dynamisch. Sie variiert in Abhängigkeit von impliziten Vorgängen zur Partitionsverwaltung beim Hinzufügen/Entfernen von Partitionen in einer Partitionsgruppe (wenn Sie z.B. den Durchsatz in einem Container skalieren, in Ihrer Cosmos-Datenbank eine Region hinzufügen/entfernen, bei Ausfällen usw.) Damit die einzelnen Partitionen (einer Partitionsgruppe) die festgelegte Mitgliedschaft in der eigenen Replikatgruppe verwalten können, ist die Mitgliedschaft vollständig dezentralisiert und hochverfügbar angelegt. Während der Neukonfiguration einer Partitionsgruppe wird auch die Topologie der Überlagerung zwischen Ressourcenpartitionen eingerichtet. Die Topologie wird dynamisch basierend auf der Konsistenzstufe, dem geografischen Abstand und der zwischen Quell- und Zielressourcenpartitionen verfügbaren Netzwerkbandbreite ausgewählt.
Der Dienst ermöglicht es Ihnen, Ihre Cosmos-Datenbanken mit einer einzelnen oder mit mehreren Schreibregionen zu konfigurieren. Je nach Ihrer Auswahl werden die Partitionsgruppen so konfiguriert, dass sie Schreibanforderungen in genau einer oder in allen Regionen zulassen. Das System nutzt ein geschachteltes Konsensprotokoll mit zwei Ebenen – eine Ebene agiert in den Replikaten einer Replikatgruppe einer Ressourcenpartition, die Schreibanforderungen akzeptiert, und die andere agiert auf der Ebene der Partitionsgruppe, um alle committeten Schreibvorgänge in der Partitionsgruppe zu garantierten. Dieser geschachtelte Multiebenenkonsens ist sehr wichtig für die Implementierung unserer strikten SLAs für Hochverfügbarkeit sowie der Konsistenzmodelle, die Cosmos DB den Kunden anbietet.
Anti-Entropie mit flexibler Konfliktlösung
Unser Ansatz zur Updateverteilung, Konfliktlösung und Ursachenverfolgung beruht auf der Vorarbeit zu epidemischen Algorithmen und dem Bayou-System. Teile dieser Ideen haben überlebt und stellen einen passenden Referenzrahmen für die Beschreibung des Systementwurfs von Cosmos DB dar, sie haben aber auch eine erhebliche Transformation durchgemacht, während sie auf das Cosmos DB-System übertragen wurden. Diese Anpassungen waren erforderlich, da bei früheren Systemen weder die Ressourcenverwaltung noch die angestrebte Zielskalierung von Cosmos DB noch die erforderlichen Funktionen (z.B. Konsistenz mit begrenzter Veraltung) gegeben waren. Auch konnten ohne die Änderungen die strikten und umfassenden SLAs von Cosmos DB für die Kunden nicht erreicht werden.
Erinnern Sie sich daran, dass eine Partitionsgruppe über mehrere Regionen verteilt ist und das (Multimaster-)Replikationsprotokoll von Cosmos DB bei der Replikation der Daten auf den Ressourcenpartitionen einer Partitionsgruppe befolgt. Jede Ressourcenpartition (einer Partitionsgruppe) akzeptiert Schreibanforderungen und verarbeitet Leseanforderungen in der Regel für die Clients in derselben Region. Die von einer Ressourcenpartition akzeptierten Schreibanforderungen innerhalb einer Region werden dauerhaft committet und innerhalb der Ressourcenpartition hochverfügbar gemacht, bevor sie dem Client bestätigt werden. Dies sind vorläufige Schreibvorgänge, die über einen Anti-Entropie-Kanal an andere Ressourcenpartitionen in der Partitionsgruppe übermittelt werden. Clients können über einen Anforderungsheader vorläufige oder committete Schreibvorgänge anfordern. Die Anti-Entropie-Übertragung ist (einschließlich ihrer Häufigkeit) dynamisch. Sie basiert auf der Topologie der Partitionsgruppe, der regionalen Nähe der Ressourcenpartitionen und der konfigurierten Konsistenzstufe. Innerhalb einer Partitionsgruppe befolgt Cosmos DB ein Schema mit einem primären Commit mit einer dynamisch ausgewählten Vermittlungspartition. Die Vermittlungsauswahl ist ein integraler Bestandteil der Neukonfiguration der Partitionsgruppe basierend auf der Topologie der Überlagerung. Für die committeten Schreibvorgänge (einschließlich mehrzeiliger/Batchupdates) wird eine vollständige Sortierung garantiert.
Wir nutzen codierte Vektoruhren (mit Regions-ID und logischen Taktungen für die einzelnen Konsensstufen der Replikat- bzw. Partitionsgruppe) für die Ursachenverfolgung und Versionsvektoren für das Erkennen und Beheben von Updatekonflikten. Die Topologie und der Peerauswahlalgorithmus sollen sicherstellen, dass für die Versionsvektoren nur ein fester und sehr geringer Mehraufwand in Bezug auf Speicher und Netzwerk entsteht. Der Algorithmus garantiert strikte Konvergenz.
Für Cosmos-Datenbanken, die mit mehreren Schreibregionen konfiguriert wurden, stellt das System Entwicklern eine Reihe flexibler automatischer Richtlinien für die Konfliktlösung bereit, einschließlich:
- Letzter Schreibvorgang gewinnt (Last-Write-Wins, LWW) nutzt standardmäßig eine vom System definierte Zeitstempeleigenschaft (die auf dem Protokoll zur Zeitsynchronisierung basiert). Cosmos DB erlaubt auch die Angabe einer anderen benutzerdefinierten numerischen Eigenschaft für die Konfliktlösung.
- Benutzerdefinierte Richtlinie zur Konfliktlösung (über Mergeprozeduren), die durch die Anwendung angegeben wird und dafür vorgesehen ist, Konflikte anwendungsdefiniert semantisch zu lösen. Diese Prozeduren werden bei Erkennung eines Schreib-Schreib-Konflikts im Rahmen einer Datenbanktransaktion auf Serverseite aufgerufen. Das System garantiert genau eine Ausführung der Mergeprozedur im Rahmen des Commitprotokolls. Ihnen stehen viele Beispiele zum Testen zur Auswahl.
- Konfliktfrei replizierte Datentypen (Conflict-free-Replicated-Data-Types, CRDTs) stehen nativ im Kerntypsystem (ARS) unserer Datenbank-Engine zur Verfügung. Dies ermöglicht wiederum die automatische Lösung von Konflikten sowohl transaktional als auch direkt in der Datenbank-Engine im Rahmen des Commitprotokolls.
Fünf genau definierte Konsistenzmodelle
Sie können unabhängig davon, ob Sie Ihre Cosmos-Datenbank mit einer oder mit mehreren Schreibregionen konfigurieren, fünf genau definierte Konsistenzmodelle verwenden, die der Dienst anbietet. Aufgrund der neu eingeführten Unterstützung für die Aktivierung mehrerer Schreibregionen sollten die folgenden Aspekte von Konsistenzstufen berücksichtigt werden:
Wie bisher garantiert die Konsistenz mit begrenzter Veraltung, dass alle Lesevorgänge innerhalb von k Präfixen oder t Sekunden nach dem letzten Schreibvorgang in einer der Regionen liegen. Darüber hinaus werden für Lesevorgänge mit Konsistenz mit begrenzter Veraltung Monotonie und konsistente Präfixe garantiert. Das Anti-Entropie-Protokoll wird mit Ratenlimit ausgeführt. Es stellt sicher, dass die Präfixe sich nicht anhäufen und dass der Rückstau bei den Schreibanforderungen nicht angewandt werden muss. Wie bisher garantiert Sitzungskonsistenz monotone Lesevorgänge, monotone Schreibvorgänge, RYOW, Write-Follows-Read und konsistente Präfixe weltweit. Bei Datenbanken, die mit strikter Konsistenz konfiguriert wurden, wechselt das System zurück zu nur einer Schreibregion, indem in jeder Partitionsgruppe ein Leader festgelegt wird.
Die Semantik der fünf Konsistenzmodelle wird hier beschrieben und mathematisch anhand von TLA+-Spezifikationen hoher Ebenen veranschaulicht.
Zusammenfassung
Als eine global verteilte Datenbank repliziert Cosmos DB Ihre Daten transparent in einer beliebigen Anzahl von Azure-Regionen. Durch die neue, vollständig dezentrale Multimaster-Replikationsarchitektur können Sie Schreib- und Leseanforderungen flexibel auf alle Regionen skalieren, die Ihrer Cosmos-Datenbank zugeordnet sind. An der Möglichkeit der flexiblen Skalierung von Schreibvorgängen auf globaler Ebene durch das Schreiben lokaler Replikate der Cosmos-Datenbank an beliebigen Standorten auf der Welt wurde bereits seit einigen Jahren gearbeitet. Wir freuen uns, dass dieses Feature nun für jeden Benutzer allgemein verfügbar ist!
Danksagung
Azure Cosmos DB begann Ende 2010 als „Project Florence“, bevor das Projekt expandierte und sich zu seiner heutigen Form weiterentwickelte. Unser Dank gilt allen Teams bei Microsoft, die Azure Cosmos DB so stabil gemacht haben, indem sie es über die Jahre intensiv genutzt haben. Wir stehen auf den Schultern von Riesen – denn Azure Cosmos DB baut auf vielen Komponenten und Technologien auf, einschließlich Compute, Netzwerk und Service Fabric – und danken ihnen für ihre andauernde Unterstützung. Unser Dank geht an Dr. Leslie Lamport für die Inspiration und den Einfluss auf unseren Ansatz bei der Entwicklung verteilter Systeme. Wir möchten uns auch bei unseren Kunden bedanken, die sich bei der Entwicklung ihrer wichtigen Apps auf Cosmos DB verlassen und die Grenzen des Diensts immer weiter verschieben, indem sie stets das Optimum verlangen. Und zu guter Letzt danken wir all den großartigen Cosmonauts für ihr Engagement und Sorgfalt.
- Grammatiken wie JSON, BSON und CQL stellen eine strikte Teilmenge des ARS-Typensystems dar.