Freigeben über

Flexible Tabellen für Entwickler

Elastic-Tabellen von Dataverse werden von Azure Cosmos DB unterstützt. Sie werden automatisch horizontal skaliert, um große Datenmengen und einen hohen Durchsatz mit geringer Latenz zu verarbeiten. Elastische Tabellen eignen sich für Anwendungen, die unvorhersehbare, spitzenartige oder schnell wachsende Belastungen 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 erhalten 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 über die Unterschiede in der Modellierung elastischer 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, müssen Sie eine Partitionierungsstrategie auswählen und konsistent anwenden. 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 sollten, 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 darin enthaltenen Werte werden nicht geändert. Nachdem eine Zeile mit einem partitionid Wert erstellt wurde, 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) 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 für eine Zeile partitionid kein Wert angegeben ist, verwendet Dataverse den Primärschlüssel als den Standardwert für 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.

Beispielsweise verfügen Sie über einen synchronen Plug-In-Schritt, der in der PostOperation Phase der Create Nachricht auf einer elastischen Tabelle registriert ist. In diesem Fall führt ein Fehler, der im Plug-In auftritt, kein Rollback des Datensatzes durch, der in Dataverse erstellt wurde. Vermeiden Sie es, einen Vorgang absichtlich durch das Auslösen von InvalidPluginExecutionException in der PreOperation oder PostOperation synchronen Phase abzubrechen. 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.

Sie sollten jedoch immer Gültigkeitsprüfungsregeln in einem Plug-In anwenden, das für die PreValidation synchrone Phase registriert ist. Die Validierung ist der Zweck dieser Phase. Selbst 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 der Zukunft wird ein Fehler ausgelöst.

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 Datensätzen 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 ein Wert in dieser Spalte festgelegt wird, definiert er die Zeitspanne in Sekunden, bevor die Zeile abläuft und automatisch aus der Datenbank gelöscht wird. Wenn kein Wert festgelegt ist, wird der Datensatz unbegrenzt beibehalten, genau wie Standardtabellen.

Scenario

Die Beispiele in verwandten Artikeln verwenden dieses Szenario.

Contoso betreibt eine große Anzahl von Internet of Things (IoT)-Geräten, die das Unternehmen auf der ganzen Welt bereitgestellt hat. Contoso muss große Mengen von Sensordaten speichern und abfragen, die von den IoT-Geräten ausgegeben werden, damit es deren Zustand überwachen und weitere Erkenntnisse gewinnen kann.

Um das große Volumen von 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 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