Teilen über

Elastische Tabellen für Entwickler

  • Artikel

Dataverse elastische Tabellen werden von Azure Cosmos DB betrieben. Sie skalieren automatisch horizontal, um große Datenmengen und einen hohen Durchsatz bei geringer Latenz zu verarbeiten. Elastische Tabellen eignen sich für Anwendungen, die unvorhersehbare, spitzenmäßige oder schnell wachsende Workloads haben.

Dieser Artikel befasst sich mit Informationen, die Entwickler über die Verwendung elastischer Tabellen wissen müssen. Weitere Informationen über die Funktionalitäten von elastischen Tabellen und was unterstützt wird, finden Sie unter Elastische Tabellen erstellen und bearbeiten.

Wann Sie elastische Tabellen verwenden sollten

Die spezifischen Anforderungen Ihrer Daten und Ihrer Anwendung bestimmen, ob Sie elastische Tabellen oder Standardtabellen verwenden sollten.

Verwenden Sie in folgenden Situationen elastische Tabellen:

  • Ihre Daten können unstrukturiert oder halbstrukturiert sein, oder Ihr Datenmodell kann sich ständig ändern.
  • Sie benötigen eine horizontale Skalierung, um das Wachstum des Workloads im Laufe der Zeit oder den sprunghaften Anstieg des Workloads zu einem bestimmten Zeitpunkt zu bewältigen.
  • Sie müssen ein hohes Volumen an Lese- und Schreibanforderungen bewältigen.

Verwenden Sie in folgenden Situationen Standardtabellen:

  • Ihre Anwendung erfordert eine hohe Datenkonsistenz.
  • Ihre Anwendung erfordert eine relationale Modellierung und benötigt Funktionalitäten für Transaktionen zwischen Tabellen oder während der Ausführung von Plug-Ins.
  • Ihre Anwendung erfordert komplexe Verknüpfungen.

Für Ihre Daten und Ihre Anwendung könnte eine Kombination aus elastischen und Standardtabellen geeignet sein.

Weitere Informationen über die Unterschiede in der Modellierung elastischer Tabellen finden Sie unter:

Partitioning und horizontale Skalierung

Elastische Tabellen verwenden Azure Cosmos DB-Partitioning, um einzelne Tabellen so zu skalieren, dass sie den Leistungsanforderungen Ihrer Anwendung entsprechen. Alle elastischen Tabellen enthalten eine systemdefinierte Zeichenfolgenspalte Partitions-ID. Diese Spalte hat den Schemanamen PartitionId und den logischen Namen partitionid.

Azure Cosmos DB sorgt dafür, dass die Zeilen einer Tabelle in verschiedene Teilmengen unterteilt werden, auf der Grundlage des Werts der Spalte partitionid für jede Zeile. Diese Teilmengen werden logische Partitionen genannt.

Wichtig

Um die beste Leistung zu erhalten, die mit elastischen Tabellen verfügbar ist, müssen Sie eine Partitionierungsstrategie wählen und konsequent anwenden. Wenn Sie nicht für jede Zeile einen partitionid-Wert festlegen, bleibt der Wert null, und Sie können ihn später nicht mehr ändern.

Wenn Sie einen angepassten partitionid-Wert verwenden, verfügt der Primärschlüsselwert nicht über eine eindeutige Einschränkung. Mit anderen Worten: Sie können mehrere Datensätze erstellen, die denselben Primärschlüssel haben, aber unterschiedliche partitionid-Werte. Es ist wichtig zu verstehen, dass eindeutige Referenzen für elastische Tabellen eine Kombination aus dem Primärschlüssel und dem Wert partitionid sind.

Auswählen eines partitionid-Wertes

Welchen partitionid-Wert Sie verwenden sollten, hängt von der Art Ihrer Daten ab. Eine logische Partition in einer elastischen Tabelle besteht aus einer Reihe von Zeilen, die den gleichen partitionid-Wert haben. In einer Tabelle, die Daten über verschiedene Produkte enthält, können Sie zum Beispiel die Produktkategorie als partitionid-Wert für die Tabelle verwenden. In diesem Fall bilden Gruppen von Elementen, die bestimmte Werte für die Produktkategorie haben, wie Clothing, Books, Electronic Appliances und Pet supplies, unterschiedliche logische Partitionen.

Dataverse verwaltet transparent und automatisch logische Partitionen, die mit einer Tabelle verbunden sind. Es gibt keine Begrenzung für die Anzahl der logischen Partitionen, die Sie in einer Tabelle haben können. Darüber hinaus besteht kein Risiko, dass eine logische Partition gelöscht wird, wenn die zugrunde liegenden Zeilen gelöscht werden.

Für alle elastischen Tabellen sollte die Spalte partitionid diese Kriterien erfüllen:

  • Die Werte darin ändern sich nicht. Nachdem eine Zeile erstellt wurde, die einen partitionid-Wert hat, können Sie sie nicht mehr ändern.
  • Sie hat einen hohen Kardinalitätswert. Mit anderen Worten, die Eigenschaft sollte eine große Bandbreite an möglichen Werten haben. Jede logische Partition kann 20 Gigabyte (GB) an Daten speichern. Wenn Sie also einen partitionid-Wert wählen, der eine große Bandbreite möglicher Werte hat, stellen Sie sicher, dass die Tabelle skaliert werden kann, ohne für eine bestimmte logische Partition Grenzwerte zu erreichen.
  • Die Daten werden so gleichmäßig wie möglich auf alle logischen Partitionen verteilt.
  • Keine Werte sind größer als 1.024 Byte.
  • Keine Werte enthalten Schrägstriche (/), spitze Klammern (<, >), Sternchen (*), Prozentzeichen (%), kaufmännische Und-Zeichen (&), Doppelpunkte (:), Backslashes (\), Fragezeichen (?) oder Pluszeichen (+). Diese Zeichen werden für Alternativschlüssel nicht unterstützt.

Wenn für eine Zeile kein partitionid-Wert angegeben wird, verwendet Dataverse den Primärschlüsselwert als standardmäßigen partitionid-Wert. Für schreibintensive Tabellen jeder Größe oder für Fälle, in denen Zeilen hauptsächlich mithilfe des Primärschlüssels abgerufen werden, ist der Primärschlüssel eine gute Wahl für die Spalte partitionid.

Konsistenzebene

Elastische Tabelle unterstützt starke Konsistenz während einer logischen Sitzung. Eine logische Sitzung ist eine Verbindung zwischen einem Client und Dataverse. Wenn ein Client einen Schreibvorgang auf einer elastischen Tabelle durchführt, erhält er ein Sitzungstoken, das die logische Sitzung eindeutig identifiziert. Um eine starke Konsistenz zu haben, müssen Sie den logischen Sitzungskontext aufrechterhalten, indem Sie das Sitzungstoken mit allen nachfolgenden Anforderungen aufnehmen.

Sitzungstoken stellen sicher, dass alle Schreibvorgänge, die während desselben logischen Sitzungskontexts durchgeführt werden, den letzten Schreibvorgang zurückgeben, der während dieser logischen Sitzung gemacht wurde. Mit anderen Worten, Sitzungstoken stellen sicher, dass Lesevorgänge immer Lesen der eigenen Schreibvorgänge und Schreibvorgänge folgen Lesevorgängen während einer logischen Sitzung garantiert einhalten. Wenn eine andere logische Sitzung einen Schreibvorgang durchführt, erkennen andere logische Sitzungen diese Änderungen möglicherweise nicht sofort.

Das Sitzungstoken ist als ein x-ms-session-token-Wert in der Antwort auf alle Schreibvorgänge verfügbar. Sie müssen diesen Wert einschließen, wenn Sie Daten abrufen, um die aktuelle Zeile abrufen zu können.

  • Wenn Sie das SDK verwenden, verwenden Sie den optionalen Parameter SessionToken.
  • Wenn Sie die Web-API verwenden, verwenden Sie den Anforderungsheader MSCRM.SessionToken.

Wenn Sie einen Datensatz ohne ein Sitzungstoken abrufen, werden die kürzlich vorgenommenen Änderungen möglicherweise nicht übernommen. Stattdessen werden sie möglicherweise in nachfolgenden Anforderungen zurückgegeben.

Weitere Informationen zur Verwendung des Sitzungstokens.

Transaktionelles Verhalten

Elastische Tabellen unterstützen keine Transaktionen mit mehreren Datensätzen. Bei der Ausführung einer einzelnen Anforderung sind mehrere Schreibvorgänge, die während derselben synchronen Plug-In-Phase oder während verschiedenen synchronen Plug-In-Phasen stattfinden, nicht miteinander transaktional.

Beispielsweise verfügen Sie über einen synchronen Plug-In-Schritt, der in der PostOperation-Phase der Create-Nachricht in einer elastischen Tabelle registriert ist. In diesem Fall führt ein im Plug-In auftretender Fehler nicht zu einem Rollback des Datensatzes, der in Dataverse erstellt wurde. Sie sollten immer vermeiden, einen Vorgang absichtlich abzubrechen, indem Sie InvalidPluginExecutionException in den synchronen Phasen PreOperation oder PostOperation auslösen. Wenn der Fehler nach dem Vorgang Main ausgelöst wird, gibt die Anforderung einen Fehler zurück, aber der Datenvorgang ist erfolgreich. Alle Schreibvorgänge, die in der PreOperation-Phase gestartet werden, sind erfolgreich.

Sie sollten jedoch immer Validierungsregeln in einem Plug-In anwenden, das für die synchrone Phase PreValidation registriert ist. Die Validierung ist der Zweck dieser Phase. Auch wenn Sie elastische Tabellen verwenden, gibt die Anforderung einen Fehler zurück, und der Datenvorgang wird nicht gestartet. Weitere Informationen über die Ereignisausführungspipeline.

Elastische Tabellen unterstützen auch nicht die Gruppierung von Anforderungen in einer einzelnen Datenbanktransaktion, die die SDK-ExecuteTransactionRequest-Klasse verwendet, oder in einem $batch-Vorgangs-Changeset einer Web-API. Zurzeit sind diese Vorgänge erfolgreich, aber nicht atomar. In der Zukunft wird ein Fehler ausgelöst.

Elastische Tabellen unterstützen nicht tiefes Einfügen wie es Standardtabellen tun. Sie erhalten diesen Fehler:Cannot create related entities. Create has to be called individually for each entity.

Weitere Informationen zu Transaktionen mit mehreren Datensätzen finden Sie unter:

Daten mithilfe von Time-to-Live ablaufen lassen

Dataverse enthält automatisch eine Integerspalte Gültigkeitsdauer mit elastischen Tabellen. Diese Spalte hat den Schemanamen TTLInSeconds und den logischen Namen ttlinseconds.

Wenn in dieser Spalte ein Wert festgelegt wird, definiert er die Zeit in Sekunden, bevor die Zeile abläuft und automatisch aus der Datenbank gelöscht wird. Wenn kein Wert festgelegt wird, bleibt der Datensatz wie bei Standardtabellen auf unbestimmte Zeit erhalten.

Szenario

Die Beispiele in den verwandten Artikeln verwenden dieses Szenario.

Contoso betreibt eine große Anzahl von Internet of Things (IoT)-Geräten, die von der Firma auf der ganzen Welt bereitgestellt wurden. Contoso muss große Mengen an Sensordaten, die von den IoT-Geräten ausgegeben werden, speichern und abfragen, um deren Integrität zu überwachen und andere Erkenntnisse zu gewinnen.

Um die große Menge an IoT-Daten zu speichern und abzufragen, erstellt Contoso eine elastische Tabelle mit dem Namen contoso_SensorData. Sie verwendet eine Zeichenfolgenspalte mit dem Namen contoso_DeviceId als partitionid-Wert für jede Zeile, die einem Gerät entspricht. Da jeder contoso_DeviceId-Wert für ein Gerät eindeutig ist und Contoso Abfragen meist im Zusammenhang mit einem bestimmten contoso_DeviceId-Wert durchführt, ist dies eine gute Partitionierungsstrategie für das gesamte Dataset.

Ähnliche Artikel:

Bekannte Probleme

Die folgenden bekannten Probleme mit elastischen Tabellen sollten behoben werden, bevor diese Funktion allgemein verfügbar wird.

Kein Fehler wird zurückgegeben, wenn Vorgänge für Daten elastischer Tabellen in einer Transaktion gruppiert werden

Dataverse gibt keinen Fehler zurück, wenn Sie Datenvorgänge mithilfe der SDK-ExecuteTransactionRequest-Klasse oder einem $batch-Vorgangs-Changeset einer Web-API gruppieren. Obwohl diese Datenvorgänge abgeschlossen werden, wird keine Transaktion angewendet. Da keine Transaktion angewendet werden kann, sollten diese Vorgänge fehlschlagen und einen Fehler zurückgeben.

Kein x-ms-session-token-Wert wird bei Löschvorgängen zurückgegeben

Dataverse gibt bei Löschvorgängen nicht den Wert x-ms-session-token zurück. Erfahren Sie mehr darüber, wie dieser Wert für verwaltete Datenkonsistenz verwendet wird.

Der optionale partitionId-Parameter ist nicht für alle Nachrichten verfügbar

Immer wenn ein Datensatz, der einen angepassten partitionid-Wert verwendet, identifiziert werden muss, z. B. für Retrieve-, Update- oder Upsert-Vorgänge, benötigen Sie eine Möglichkeit, auf den partitionid-Wert zu verweisen. In diesem Fall können Sie den Alternativschlüssel verwenden, um auf den Datensatz zu verweisen. Wenn Sie dies bevorzugen, sollten Sie auch in der Lage sein, den Stil für den optionalen Parameter partitionId zu verwenden. Aktuell unterstützen nur die Vorgänge Retrieve und Delete die Verwendung des optionalen Parameters partitionId. Weitere Informationen zur Verwendung des partitionId-Parameters.

Wenn Gültigkeitsdauer (Time To Live, TTL) für eine Zeile verwendet wird, wird die Zeile aus der elastischen Tabelle gelöscht, wenn die TTL abgelaufen ist. Wenn sie mit Synapse Link for Dataverse mit einem Data Lake vor TTL-Ablauf synchronisiert wird, wird sie nicht aus dem Data Lake gelöscht.

Häufig gestellte Fragen

Dieser Abschnitt wird alle häufig gestellten Fragen (FAQ) enthalten. Wenn Sie eine Frage haben, die in der Dokumentation nicht behandelt wird, wählen Sie die Schaltfläche Diese Seite im Abschnitt Feedback unten auf der Seite. Sie benötigen ein GitHub-Konto, um Fragen auf diese Weise zu senden.

Nächste Schritte,

Erstellen Sie elastische Tabellen mit Code

Siehe auch

Elastische Tabellen mit Code verwenden
Abfrage von JSON-Spalten in elastischen Tabellen
Massenvorgang für Nachrichten
Beispielcode für elastische Tabellen
Partitionierung und horizontale Skalierung in Azure Cosmos DB