Sharding für horizontale Skalierbarkeit in Azure DocumentDB

Azure DocumentDB unterstützt Sharding zum horizontalen Verteilen von Daten und Datenverkehr. Die Dokumente in einer Sammlung werden in Blöcke unterteilt, die als logische Shards bezeichnet werden.

Sharding wird für jede Collection individuell mithilfe eines zugewiesenen Shardschlüssels aus der Dokumentstruktur der Collection definiert. Daten werden dann in Blöcke zusammengefasst, wobei jeder Block einer logischen Partition entspricht. Dokumente für jeden eindeutigen Wert der Shard-Schlüssel-Eigenschaft befinden sich im selben logischen Shard.

Für jedes Dokument, das in eine Shardsammlung eingefügt wurde, wird der Wert der Shardschlüsseleigenschaft als Hash dargestellt, um die jeweiligen logischen Shards zu berechnen. Das Platzieren des logischen Shards und die Verteilung aller logischen Shards innerhalb des Clusters werden vom Benutzer abstrahiert und vollständig vom Dienst verwaltet.

Logische Teilstücke

Alle Dokumente, die denselben Wert für den Shardschlüssel enthalten, gehören zum gleichen logischen Shard.

Betrachten wir beispielsweise eine Sammlung namens "Employees" mit der folgenden Dokumentstruktur.

Diese Tabelle zeigt eine Zuordnung von Shardschlüsselwerten zu logischen Partitionen.

• Es gibt keine Begrenzungen für die Anzahl der logischen Shards einer Sammlung. Eine Sammlung kann so viele logische Shards aufweisen wie Dokumente mit einem eindeutigen Wert für die Shardschlüsseleigenschaft in jedem Dokument.

• Es gibt auch keine Grenzen für die Größe eines einzelnen logischen Shards.

• Darüber hinaus schränkt der Dienst keine Transaktionen auf den Umfang eines logischen Shards ein. Azure DocumentDB unterstützt Lese- und Schreibvorgänge, die über mehrere logische Shards und über mehrere physische Shards im Cluster hinweg anwendbar sind.

Physische Bruchstücke

Physische Shards sind die zugrunde liegenden Server und Festplatten, die für die Speicherung der Daten und die Durchführung von Datenbanktransaktionen verantwortlich sind. Im Gegensatz zu logischen Shards verwaltet der Dienst physische Shards im Hintergrund.

Die Anzahl der physischen Shards wird definiert, wenn ein Cluster erstellt wird und erhöht werden kann, wenn die Datenbankgröße im Laufe der Zeit wächst. Einzelne Shardcluster verfügen über einen physischen Shard (Knoten), der vollständig für die Speicher- und Datenbanktransaktionen des Clusters verantwortlich ist. Multishardcluster verteilen das Daten- und Transaktionsvolumen über die physischen Shards im Cluster.

Zuordnung von logischen Shards zu physischen Shards

Wenn neue logische Shards hinzugefügt werden, aktualisiert der Cluster nahtlos die Zuordnung von logischen zu physischen Shards. Ebenso wird die Zuordnung des Adressraums zu jedem physischen Shard geändert, da dem Cluster neue physische Shards hinzugefügt werden, nach denen logische Shards im gesamten Cluster neu ausgeglichen werden.

Der Hashbereich, der zum Zuordnen logischer und physischer Shards verwendet wird, wird gleichmäßig über die physischen Shards im Cluster verteilt. Jeder physische Shard besitzt einen Bucket mit gleichmäßiger Größe des Hashbereichs. Für jedes Dokument, das geschrieben wird, wird der Wert der Shard-Schlüsseleigenschaft mit Hash versehen, und der Hashwert bestimmt die Zuordnung des Dokuments zum zugrunde liegenden physischen Shard. Intern werden mehrere logische Shards einem einzigen physischen Shard zugewiesen. Darüber hinaus werden logische Shards niemals auf physische Shards aufgeteilt, und alle Dokumente für einen logischen Shard werden nur einem physischen Shard zugeordnet.

Basierend auf dem vorherigen Beispiel mit einem Cluster mit zwei physischen Shards zeigt diese Tabelle eine Beispielzuordnung von Dokumenten zu physischen Shards.

Kapazität physischer Shards

Die Clusterebene, die ausgewählt wird, wenn der Cluster bereitgestellt wird, bestimmt die CPU- und Arbeitsspeicherkapazität eines physischen Shards. Ebenso bestimmt die Speicher-SKU die Speicher- und IOPS-Kapazität eines physischen Shards. Größere Clusterebenen bieten mehr Rechenleistung und größeren Arbeitsspeicher, während größere Speicherdatenträger mehr Speicher und IOPS bieten. Leseintensive Workloads profitieren von einer größeren Clusterebene, während schreibintensive Workloads von einer größeren Speicher-SKU profitieren. Die Clusterebene kann nach der Erstellung des Clusters auf der Grundlage der sich ändernden Anforderungen der Anwendung nach oben und unten skaliert werden.

In einem Multishardcluster ist die Kapazität jeder physischen Shard identisch. Durch das Skalieren der Clusterebene oder der Speicher-SKU wird die Platzierung logischer Shards auf den physischen Shards nicht geändert. Nach einem Hochskalierungsvorgang bleibt die Anzahl der physischen Shards unverändert, wodurch die Notwendigkeit vermieden wird, die Daten im Cluster neu auszubalancieren.

Die Rechen-, Speicher-, Speicher- und IOPS-Kapazität des physischen Shards bestimmen die ressourcen, die für die logischen Shards verfügbar sind. Shardschlüssel, die nicht über eine gleichmäßige Verteilung von Speicher- und Anforderungsvolumes verfügen, können einen ungleichmäßigen Speicher- und Durchsatzverbrauch innerhalb des Clusters verursachen. Heiße Partitionen können dazu führen, dass physische Shards ungleichmäßig genutzt werden, was zu einem unvorhersehbaren Durchsatz und zu einer unvorhersehbaren Leistung führt. Daher erfordern shardierte Cluster eine sorgfältige Planung, um sicherzustellen, dass die Leistung im Laufe der Zeit konsistent bleibt, da sich die Anforderungen der Anwendung im Laufe der Zeit ändern.

Replikatgruppen

Jeder physische Shard besteht aus einer Reihe von Replikaten, die auch als Replikatsatz bezeichnet werden. Jedes Replikat hostet eine Instanz der Datenbank-Engine. Mit einer Replikatgruppe wird der Datenspeicher im physischen Shard dauerhaft, hochverfügbar und konsistent. Jedes Replikat, aus dem die physische Shard besteht, erbt die Speicher- und Computekapazität des physischen Shards. Azure DocumentDB verwaltet Replikatgruppen automatisch.

Bewährte Methoden zum Sharden von Daten

• Sharding in Azure DocumentDB ist nicht erforderlich, es sei denn, die Speicher- und Transaktionsvolumes der Sammlung können die Kapazität eines einzelnen physischen Shards überschreiten. Beispielsweise stellt der Dienst 32 TB Datenträger pro Shard bereit. Wenn eine Sammlung mehr als 32 TB erfordert, sollte sie abgeshardt werden.

• Es ist nicht erforderlich, jede Sammlung in einem Cluster mit mehreren physischen Shards zu partitionieren. Per Sharding partitionierte und nicht partitionierte Sammlungen können im selben Cluster vorhanden sein. Der Dienst verteilt die Sammlungen im Cluster optimal, um die Compute- und Speicherressourcen des Clusters gleichmäßig zu nutzen.

• Bei leseintensiven Anwendungen muss der Shardschlüssel basierend auf den am häufigsten verwendeten Abfragemustern ausgewählt werden. Der am häufigsten verwendete Abfragefilter für eine Auflistung sollte als Shardschlüssel ausgewählt werden, um den höchsten Prozentsatz der Datenbanktransaktionen zu optimieren, indem die Suche auf einen einzelnen physischen Shard lokalisiert wird.

• Bei Anwendungen mit hohem Schreibaufwand, die Schreiboperationen gegenüber Lesevorgängen bevorzugen, sollte ein Shard-Schlüssel gewählt werden, um die Daten gleichmäßig über die physischen Shards zu verteilen. Shard-Schlüssel mit der höchsten Kardinalität bieten die beste Möglichkeit für eine möglichst gleichmäßige Verteilung.

• Um eine optimale Leistung zu erzielen, sollte die Speichergröße eines logischen Shards kleiner als 4 TB sein.

• Um eine optimale Leistung zu erzielen, sollten logische Shards gleichmäßig im Speicher verteilt und das Anforderungsvolume über die physischen Shards des Clusters verteilt werden.

So partitioniert man eine Sammlung

Betrachten Sie das folgende Dokument aus der "cosmicworks"-Datenbank und der Sammlung "mitarbeiter"

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Im folgenden Beispiel wird die Mitarbeitersammlung in der Datenbank „cosmicworks“ per Sharding nach der firstName-Eigenschaft (Vorname) partitioniert.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

Die Sammlung kann auch mithilfe eines Administratorbefehls abgeshardt werden:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Obwohl es nicht ideal ist, den Shardschlüssel zu ändern, nachdem die Sammlung erheblich im Speichervolume gewachsen ist, kann der ReshardCollection-Befehl verwendet werden, um den Shardschlüssel zu ändern.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

Die Sammlung kann auch mithilfe eines Admin-Befehls umgeschichtet werden:

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

Als bewährte Methode muss für die Shard key-Eigenschaft ein Index erstellt werden.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Nächste Schritte

• Erfahren Sie, wie Sie den Azure DocumentDB-Cluster skalieren.
• Sehen Sie sich bewährte Methoden für die Indizierung an