Freigeben über

Flexible Tabellen für Entwickler

Dataverse Elastic Tables verwenden Azure Cosmos DB. Sie werden automatisch horizontal skaliert, um große Datenmengen und einen hohen Durchsatz mit geringer Latenz zu verarbeiten. Elastische Tabellen funktionieren gut für Anwendungen, die unvorhersehbare, spitzenartige oder schnell wachsende Arbeitslasten aufweisen.

Dieser Artikel konzentriert sich auf Informationen, die Entwickler über die Verwendung von elastischen Tabellen wissen müssen. Weitere Informationen zu den Funktionen von elastischen Tabellen und den unterstützten Funktionen finden Sie unter Erstellen und Bearbeiten von elastischen Tabellen.

Wann man elastische Tabellen verwenden sollte

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

Verwenden Sie in diesen Situationen elastische Tabellen:

  • Ihre Daten sind möglicherweise unstrukturiert oder halbstrukturiert, oder Ihr Datenmodell ändert sich ständig.
  • Sie benötigen eine horizontale Skalierung, um das Wachstum der Arbeitsauslastung im Laufe der Zeit oder um spontan anfallende Arbeitslast zu einem bestimmten Zeitpunkt zu bewältigen.
  • Sie müssen eine hohe Anzahl von Lese- und Schreibanforderungen verarbeiten.

Verwenden Sie Standardtabellen in diesen Situationen:

  • Ihre Anwendung erfordert eine starke Datenkonsistenz.
  • Ihre Anwendung erfordert relationale Modellierung und benötigt Transaktionsfunktionen über Tabellen oder während der Plug-In-Ausführung.
  • Ihre Anwendung erfordert komplexe Verknüpfungen.

Eine Kombination aus elastischen und Standardtabellen eignet sich möglicherweise für Ihre Daten und Ihre Anwendung.

Weitere Informationen zu Unterschieden bei der Modellierung von elastischen Tabellen finden Sie unter:

Partitionierung und horizontale Skalierung

Flexible Tabellen verwenden die Azure Cosmos DB-Partitionierung, um einzelne Tabellen zu skalieren, um die Leistungsanforderungen Ihrer Anwendung zu erfüllen. Alle elastischen Tabellen enthalten eine systemdefinierte Partitions-ID-Zeichenfolgenspalte . Diese Spalte weist den Schemanamen PartitionId und den logischen Namen auf partitionid.

Azure Cosmos DB stellt sicher, dass die Zeilen in einer Tabelle basierend auf dem Wert der partitionid Spalte für jede Zeile in unterschiedliche Teilmengen unterteilt sind. Diese Teilmengen werden als logische Partitionen bezeichnet.

Von Bedeutung

Um die beste Leistung zu erzielen, die mit elastischen Tabellen verfügbar ist, wählen Sie eine Partitionierungsstrategie aus und wenden sie konsequent an. Wenn Sie keinen Wert für jede Zeile festlegen partitionid , bleibt der Wert null, und Sie können ihn später nicht ändern.

Wenn Sie einen benutzerdefinierten partitionid Wert verwenden, hat der Primärschlüsselwert keine eindeutige Einschränkung. Mit anderen Worten, Sie können mehrere Datensätze erstellen, die denselben Primärschlüssel, aber unterschiedliche partitionid Werte aufweisen. Es ist wichtig zu verstehen, dass eindeutige Verweise für elastische Tabellen eine Kombination aus Primärschlüssel und partitionid Wert sind.

Auswählen eines Partitionid-Werts

Der partitionid wert, den Sie verwenden, hängt von der Art Ihrer Daten ab. Eine logische Partition in einer elastischen Tabelle besteht aus einer Reihe von Zeilen, die denselben partitionid Wert aufweisen. Beispielsweise können Sie in einer Tabelle, die Daten zu verschiedenen Produkten enthält, die Produktkategorie als partitionid Wert für die Tabelle verwenden. In diesem Fall bilden Gruppen von Elementen, die bestimmte Werte für die Produktkategorie, z. B. Clothing, Books, Electronic Appliances und Pet supplies aufweisen, unterschiedliche logische Partitionen.

Dataverse transparent und automatisch verwaltet logische Partitionen, die einer Tabelle zugeordnet sind. Es gibt keine Beschränkung 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 partitionid Spalte diese Kriterien erfüllen:

  • Die Werte ändern sich nicht. Nachdem Sie eine Zeile mit einem partitionid Wert erstellt haben, können Sie sie nicht mehr ändern.
  • Sie hat einen hohen Kardinalitätswert. Mit anderen Worten, die Eigenschaft verfügt über einen breiten Bereich möglicher Werte. Jede logische Partition kann 20 Gigabyte (GB) von Daten speichern. Daher stellen Sie sicher, dass die Tabelle skaliert werden kann, indem Sie einen partitionid Wert auswählen, der über einen breiten Bereich möglicher Werte verfügt, ohne grenzwerte für eine bestimmte logische Partition zu erreichen.
  • Sie verteilt Daten so gleichmäßig wie möglich unter allen logischen Partitionen.
  • Keine Werte sind größer als 1.024 Byte.
  • Keine der Werte enthalten Schrägstriche (/), Winkelklammern (<, >), Sternchen (*), Prozentzeichen (%), Und-Zeichen (&), Doppelpunkte (:), umgekehrte Schrägstriche (\), Fragezeichen (?) oder Pluszeichen (+). Diese Zeichen werden für alternative Schlüssel nicht unterstützt.

Wenn Sie keinen Wert für eine Zeile angeben partitionid , verwendet Dataverse den Primärschlüsselwert als Standardwert partitionid . Bei schreibintensiven Tabellen mit beliebiger 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 partitionid Spalte.

Konsistenzebene

Die elastische Tabelle unterstützt eine starke Konsistenz während einer logischen Sitzung. Eine logische Sitzung ist eine Verbindung zwischen einem Client und Dataverse. Wenn ein Client einen Schreibvorgang für eine elastische Tabelle ausführt, empfängt er ein Sitzungstoken , das die logische Sitzung eindeutig identifiziert. Um eine starke Konsistenz zu haben, müssen Sie den logischen Sitzungskontext beibehalten, indem Sie das Sitzungstoken mit allen nachfolgenden Anforderungen einschließen.

Sitzungstoken stellen sicher, dass alle Lesevorgänge, die während desselben logischen Sitzungskontexts ausgeführt werden, den letzten Schreibvorgang zurückgeben, der während dieser logischen Sitzung vorgenommen 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 ausführt, erkennen andere logische Sitzungen diese Änderungen möglicherweise nicht sofort.

Das Sitzungstoken ist als x-ms-session-token Wert in der Antwort aller Schreibvorgänge verfügbar. Um die aktuellsten Zeile abzurufen, müssen Sie diesen Wert bei der Datenabfrage einschließen.

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

Wenn Sie einen Datensatz ohne Sitzungstoken abrufen, werden die zuletzt angewendeten Änderungen möglicherweise nicht angewendet. Stattdessen werden sie möglicherweise in nachfolgenden Anfragen zurückgegeben.

Erfahren Sie mehr über die Verwendung des Sitzungstokens.

Transaktionsverhalten

Flexible Tabellen unterstützen keine Transaktionen mit mehreren Datensätzen. Bei einer einzelnen Anforderungsausführung sind mehrere Schreibvorgänge, die während derselben synchronen Plug-in-Phase oder während unterschiedlicher synchroner Plug-in-Phasen auftreten, nicht transaktional miteinander verbunden.

Sie registrieren beispielsweise einen synchronen Plug-In-Schritt in der PostOperation Phase der Create Nachricht auf einer elastischen Tabelle. In diesem Fall führt ein Fehler, der im Plug-In auftritt, nicht dazu, dass der in Dataverse erstellte Datensatz zurückgesetzt wird. Vermeiden Sie es immer, irgendwelche Vorgänge absichtlich abzubrechen, indem Sie die InvalidPluginExecutionException in der PreOperation oder PostOperation synchronen Phase auslösen. Wenn der Fehler nach dem Main Vorgang ausgelöst wird, gibt die Anforderung einen Fehler zurück, der Datenvorgang ist jedoch erfolgreich. Alle Schreibvorgänge, die in der PreOperation Phase gestartet werden, sind erfolgreich.

Wenden Sie jedoch immer Gültigkeitsprüfungsregeln in einem Plug-In an, bei dem Sie die Registrierung für die PreValidation-synchronen Stufe durchführen. Die Validierung ist der Zweck dieser Phase. Auch wenn Sie elastische Tabellen verwenden, gibt die Anforderung einen Fehler zurück, und der Datenvorgang beginnt nicht. Erfahren Sie mehr ü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. Derzeit sind diese Vorgänge erfolgreich, sind aber nicht atomisch. In Zukunft lösen diese Vorgänge einen Fehler aus.

Elastische Tabellen unterstützen Deep Insert nicht, wie es Standardtabellen tun. Dieser Fehler wird angezeigt: Cannot create related entities. Create has to be called individually for each entity.

Weitere Informationen zu Transaktionen mit mehreren Datensatzen finden Sie unter:

Daten mithilfe von Time-to-Live ablaufen lassen

Dataverse enthält automatisch eine Time to live-Ganzzahlspalte mit elastischen Tabellen. Diese Spalte weist den Schemanamen TTLInSeconds und den logischen Namen auf ttlinseconds.

Wenn Sie einen Wert in dieser Spalte festlegen, definiert er die Zeitspanne in Sekunden, bevor die Zeile abläuft und automatisch aus der Datenbank gelöscht wird. Wenn Sie keinen Wert festlegen, wird der Datensatz auf unbestimmte Zeit beibehalten, genau wie Standardtabellen.

Scenario

Die Beispiele in verwandten Artikeln verwenden dieses Szenario.

Contoso betreibt eine große Anzahl von IoT-Geräten (Internet of Things), die das Unternehmen auf der ganzen Welt bereitstellt. Contoso muss große Mengen von Sensordaten speichern und abfragen, die von den IoT-Geräten ausgegeben werden, damit deren Zustand überwacht werden kann und weitere Einsichten gewonnen werden können.

Um das große Volumen von IoT-Daten zu speichern und abzufragen, erstellt Contoso eine elastische Tabelle mit dem Namen contoso_SensorData. Es verwendet eine Zeichenfolgenspalte namens 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 hauptsächlich im Kontext eines bestimmten contoso_DeviceId Werts ausführt, dient er als gute Partitionsstrategie für das gesamte Dataset.

Ähnliche Artikel:

Bekannte Probleme

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

Es wird kein Fehler zurückgegeben, wenn elastische Tabellendatenvorgänge in einer Transaktion gruppiert werden.

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

Für Löschvorgänge wird kein x-ms-session-token-Wert zurückgegeben.

Dataverse gibt den x-ms-session-token Wert für Löschvorgänge nicht zurück. Erfahren Sie mehr darüber, wie dieser Wert zur Konsistenz verwalteter Daten verwendet wird.

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

Wenn ein Datensatz, der einen benutzerdefinierten partitionid Wert verwendet, identifiziert werden muss, z. B. für Retrieve, Updateoder Upsert Vorgänge, benötigen Sie eine Möglichkeit, auf den partitionid Wert zu verweisen. In diesem Fall können Sie den alternativen Schlüssel verwenden, um den Datensatz zu referenzieren. Wenn Es Ihnen lieber ist, sollten Sie auch in der Lage sein, die partitionId optionale Parameterformatvorlage zu verwenden. Derzeit unterstützen nur Retrieve- und Delete-Operationen die Verwendung des optionalen Parameters partitionId. Erfahren Sie mehr über die Verwendung des partitionId-Parameters.

Wenn die Zeit zum Leben (TTL) in einer Zeile verwendet wird, wird die Zeile aus der elastischen Tabelle gelöscht, wenn TTL abgelaufen ist. Wenn sie mit einem Datensee synchronisiert wird, der Synapse Link for Dataverse verwendet, bevor TTL abläuft, wird sie nicht aus dem Datensee gelöscht.

Häufig gestellte Fragen

Dieser Abschnitt enthält alle häufig gestellten Fragen (FAQ). Wenn Sie eine Frage haben, die in der Dokumentation nicht adressiert ist, wählen Sie unten auf der Seite die Schaltfläche "Diese Seite " im Abschnitt "Feedback " aus. Sie müssen über ein GitHub-Konto verfügen, um Fragen auf diese Weise zu übermitteln.

Nächste Schritte

Elastische Tabellen mit Code erstellen

Siehe auch

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

  • Last updated on