次の方法で共有

開発者向けエラスティック テーブル

  • [アーティクル]

Dataverse のエラスティック テーブルは Azure Cosmos DB を利用しています。 自動的に水平方向にスケーリングして、大量のデータと高レベルのスループットを低遅延で処理します。 エラスティック テーブルは、ワークロードが予測不可能で急増したり、急速に増大したりするアプリケーションに適しています。

この記事では、開発者がエラスティック テーブルの使用について知っておく必要がある情報に焦点を当てています。 エラスティック テーブルの機能とサポート内容の詳細については、エラスティック テーブルの作成と編集 を参照してください。

エラスティック テーブルを使用するタイミング

データとアプリケーションの特定の要件によって、エラスティック テーブルと標準テーブルのどちらを使用すべきかが決まります。

次の状況ではエラスティック テーブルを使用します。

  • データが非構造化または半構造化されているか、あるいはデータ モデルが常に変化している可能性があります。
  • 時間の経過とともに増大するワークロードや、特定の時点でのバースト的なワークロードに対処するには、水平方向のスケーリングが必要です。
  • 大量の読み取りと書き込み要求を処理する必要があります。

次の状況では標準テーブルを使用します。

  • アプリケーションには強固なデータの一貫性が必要です。
  • アプリケーションにはリレーショナル モデリングが必要で、テーブル間およびプラグインの実行段階でのトランザクション機能が必要です。
  • アプリケーションには複雑な結合が必要です。

エラスティック テーブルと標準テーブルの組み合わせは、データとアプリケーションに適している場合があります。

エラスティック テーブルのモデリングの違いの詳細については、次を参照してください:

パーティション分割と水平スケーリング

エラスティック テーブルは、Azure Cosmos DB パーティション分割を使用して、アプリケーションのパフォーマンス要件に合わせて個々のテーブルをスケーリングします。 すべてのエラスティック テーブルには、システム定義の パーティション ID 文字列列が含まれています。 この列にはスキーマ名 PartitionId と論理名 partitionid が含まれます。

Azure Cosmos DB は、テーブルの行を、各行の partitionid 列の値に基づいて形成される個別のサブセットに確実に分割します。 これらのサブセットは、論理パーティションと呼ばれます。

重要

エラスティック テーブルで使用できる最適なパフォーマンスを得るには、パーティション化戦略を選択し、一貫して適用する必要があります。 行ごとに partitionid 値を設定しない場合、値は null のままとなり、後で変更することはできません。

カスタム partitionid 値を使用する場合、主キー値には一意の制約がありません。 つまり、同じ主キーを持つ複数のレコードを作成できますが、partitionid の値は異なります。 エラスティック テーブルの一意の参照は、主キーと partitionid 値の組み合わせであることを理解することが重要です。

partitionId 値の選択

使用する必要のある partitionid 値は、データの性質によって異なります。 エラスティック テーブルの論理パーティションは、同じ partitionid 値を持つ行のセットで構成されます。 たとえば、さまざまな製品に関するデータが含まれるテーブルでは、テーブルの partitionid 値として製品カテゴリを使用できます。 その場合、Clothing、Books、Electronic Appliances 、Pet supplies など、製品カテゴリに特定の値を持つアイテムのグループは、個別の論理パーティションを形成します。

Dataverse テーブルに関連付けられた論理パーティションを透過的かつ自動的に管理します。 テーブル内の論理パーティションの数に制限はありません。 さらに、論理パーティションの基礎となる行が削除された場合でも、論理パーティションが削除されるリスクはありません。

すべてのエラスティック テーブルの partitionid 列は、これらの条件を満たす必要があります:

  • その値は変更されません。 partitionid 値を使用して行が作成されると、それを変更することはできません。
  • 高いカーディナリティ値を持つ必要があります。 言い換えれば、プロパティは広範囲の可能な値を持つ必要があります。 各論理パーティションには 20 ギガバイト (GB) のデータを保存できます。 そのため、可能な値の範囲が広い partitionid を選択することにより、特定の論理パーティションで限界に達することなくテーブルを拡張することができます。
  • すべての論理パーティション間でデータをできるだけ均等に分散します。
  • 1024 バイトを超える値はありません。
  • 値にスラッシュ (/)、山かっこ (<、 >)、アスタリスク (*)、パーセント記号 (%)、アンパサンド (&)、コロン (:) は含まれません。、バックスラッシュ (\)、疑問符 (?)、またはプラス記号 (+) は含まれません。 これらの文字は代替キーとしてサポートされていません。

行に partitionid 値が指定されない場合、Dataverse は主キー値を既定の partitionid 値として使用します。 あらゆるサイズでの書き込みの多いテーブルや、行の検索がほとんど主キーで行われるようなケースでは、当然主キーは partitionid 列に最適な選択となります。

整合性レベル

エラスティック テーブルは、論理セッション内での強い整合性をサポートします。 論理セッションは、クライアントと Dataverse 間の接続です。 クライアントがエラスティック テーブルに対して書き込み操作を行うと、論理セッションを一意に識別する セッション トークン を受け取ります。 強力な一貫性を確保するには、後続のすべての要求にセッション トークンを含めて、論理セッション コンテキストを維持する必要があります。

セッション トークンを使用すると、同じ論理セッション コンテキスト内で実行されたすべての読み取り操作が、その論理セッション内で行われた最新の書き込みを返します。 つまり、セッション トークンにより、読み取りが論理セッション内で read-your-writes、write-follows-reads を尊重することが保証されます。 別の論理セッションが書き込み操作を実行した場合、他の論理セッションはそれらの変更をすぐに検出できない可能性があります。

セッション トークンは、すべての書き込み操作のレスポンスの x-ms-session-token 値として表示されます。 最新の行を取得するには、データを取得するときにこの値を含める必要があります。

  • SDK を使用している場合は、SessionToken オプションのパラメータを使用します。
  • Web API を使用している場合は、MSCRM.SessionToken 要求ヘッダーを使用します。

セッション トークンなしでレコードを取得した場合、最近適用された変更は適用されない可能性があります。 代わりに、後続の要求で返される可能性があります。

セッション トークンの使用に関する詳細については、こちらをご覧ください。

トランザクションの動作

エラスティック テーブルは複数レコード トランザクションに対応していません。 単一の要求の実行では、同じ同期プラグイン ステージまたは異なる同期プラグイン ステージで発生する複数の書き込み操作は相互にトランザクションではありません。

たとえば、エラスティック テーブル上の Create メッセージの PostOperation ステージに登録された同期プラグイン ステップがあるとします。 この場合、プラグインで発生したエラーは、Dataverse で作成されたレコードをロールバックしません。 PreOperation や PostOperation の同期ステージでは、InvalidPluginExecutionException をスローして意図的に操作をキャンセルすることは、常に避けてください。 Main 操作の後にエラーがスローされた場合、要求はエラーを返しますが、データ操作は成功します。 PreOperation ステージで開始される書き込み操作なら成功します。

ただし、PreValidation の同期ステージに登録されたプラグインでは、必ず検証のルールを適用する必要があります。 この段階の目的は検証です。 エラスティック テーブルを使用する場合でも、要求はエラーを返し、データ操作は開始されません。 イベント実行パイプラインの詳細をご覧ください。

また、エラスティック テーブルは、SDK ExecuteTransactionRequest クラス クラスを使用した単一のデータベース トランザクションや、Web API の$batch オペレーション変更セットでのリクエストのグループ化をサポートしていません。 現在、これらの操作は成功しますが、アトミックではありません。 将来的には、エラーがスローされます。

エラスティック テーブルは ディープ挿入 を標準テーブルがするようにサポートしません。 このエラーが発生します: Cannot create related entities. Create has to be called individually for each entity.

マルチレコード トランザクションの詳細については、次を参照してください:

Time to live を使用することでデータを失効させる

Dataverse は、エラスティック テーブルに Time to Live 整数列を自動的に含みます。 この列にはスキーマ名 TTLInSeconds と論理名 ttlinseconds が含まれます。

この列に値を設定すると、行の有効期限が切れてデータベースから自動的に削除されるまでの時間を秒単位で定義します。 値が設定されていない場合、レコードは標準のテーブルと同様に無期限に存続します。

シナリオ

関連記事の例では、このシナリオが使用されています。

Contoso は、同社が世界中で展開した多数のモノのインターネット (IoT) デバイスを運用しています。 Contoso は、その正常性を監視し、その他の洞察を収集できるように、IoT デバイスから送信される大量のセンサー データを保存してクエリする必要があります。

大量の IoT データを保存し、クエリを実行するために、Contoso は、contoso_SensorData という名前のエラスティック テーブルを作成します。 デバイスに対応する各行の contoso_DeviceId 値として、partitionid という名前の文字列列を使用します。 各 contoso_DeviceId は各デバイスに固有であり、Contoso は主に特定の contoso_DeviceId 値のコンテキストでクエリを実行するため、データセット全体に対する優れたパーティション戦略として機能します。

関連記事:

既知の問題

以下のエラスティック テーブルに関する既知の問題は、この機能が一般提供される前に解決する必要があります。

トランザクションでエラスティック テーブル データ操作をグループ化するときにエラーが返されない

SDK ExecuteTransactionRequest クラス または Web API $batch オペレーション変更セットを使用することによりデータ操作をグループ化しても、Dataverse がエラーを返さない。 これらのデータ操作は完了しますが、トランザクションは適用されません。 トランザクションを適用できないため、これらの操作は失敗し、エラーが返されます。

削除操作に対して x-ms-session-token no の値が返されない

Dataverse は削除操作の場合、x-ms-session-token の値を返さない。 この値がデータの一貫性を管理するためにどのように使用されるかについて詳しくは、をご覧ください。

PartitionId オプション パラメータはすべてのメッセージで使用できるわけではありません

Retrieve、Update、Upsert 操作の場合などのカスタム partitionid 値を使用するレコードを識別する場合、常に partitionid 値を参照する方法が必要となります。 この場合、代替キーを使用してレコードを参照できます。 必要に応じて、partitionId オプションのパラメーター スタイルを使用することもできます。 現在、Retrieve と Delete のオペレーションのみが、partitionId オプションのパラメータの使用をサポートしています。 partitionId パラメーターの使用に関しては、次を参照してください。

存続期間 (TTL) が行で使用されている場合、TTL の有効期限が切れると、その行はエラスティック テーブルから削除されます。 TTL の有効期限が切れる前に、Synapse Link for Dataverse を使用してデータ レイクに同期された場合、データ レイクから削除されません。

よく寄せられる質問

このセクションには、よく寄せられる質問 (FAQ) が含まれています。 ドキュメントに記載されていない質問がある場合は、ページの下部にあるセクション フィードバック の このページ ボタンを選択してください。 この方法で質問を投稿するには、GitHub のアカウントが必要です。

次の手順

コードを使用してエラスティック テーブルを作成する

参照

コードを使用してエラスティック テーブルを使用する
エラスティック テーブルの JSON 列をクエリする
一括操作メッセージ
エラスティック テーブル サンプル コード
Azure Cosmos DB におけるパーティション分割と水平スケーリング