Documentdb-quick-guide
DocumentDB-はじめに
この章では、NoSQLおよびドキュメントデータベースに関する主要な概念について簡単に説明します。 DocumentDBの概要も簡単に説明します。
NoSQLドキュメントデータベース
DocumentDBはMicrosoftの最新のNoSQLドキュメントデータベースです。したがって、NoSQLドキュメントデータベースと言うと、NoSQLとドキュメントデータベースとは正確に何を意味するのでしょうか。
- SQLは、リレーショナルデータベースの従来のクエリ言語である構造化クエリ言語を意味します。 SQLは、多くの場合、リレーショナルデータベースと同一視されます。
- NoSQLデータベースを非リレーショナルデータベースと考えると、非常に便利です。したがって、NoSQLは本当に非リレーショナルを意味します。
次のようなキー値ストアを含むさまざまな種類のNoSQLデータベースがあります-
- Azureテーブルストレージ。
- Cassandraのような列ベースのストア。
- NEO4のようなグラフデータベース。
- MongoDBやAzure DocumentDBなどのドキュメントデータベース。
Azure DocumentDB
Microsoftは2015年4月8日に正式にAzure DocumentDBを開始しました。これは確かに典型的なNoSQLドキュメントデータベースとして特徴付けられます。 非常にスケーラブルであり、スキーマフリーのJSONドキュメントで動作します。
- DocumentDBは、現代のモバイルおよびWebアプリケーション向けに設計された真のスキーマフリーのNoSQLドキュメントデータベースサービスです。
- また、一貫して高速な読み取りと書き込み、スキーマの柔軟性、およびデータベースを必要に応じて簡単にスケールアップおよびスケールダウンする機能も提供します。
- インデックスを作成するJSONドキュメントのスキーマを想定または要求しません。
- DocumentDBは、ドキュメントがデータベースに追加されるとすぐに、ドキュメント内のすべてのプロパティに自動的にインデックスを付けます。
- DocumentDBは、SQL言語を使用した複雑なアドホッククエリを可能にし、すべてのドキュメントは作成された瞬間にすぐにクエリ可能であり、ドキュメント階層内の任意のプロパティを検索できます。
DocumentDB –価格
DocumentDBは、データベースアカウントに含まれるコレクションの数に基づいて請求されます。 各アカウントは1つ以上のデータベースを持つことができ、各データベースはコレクションの仮想的に無制限の数を持つことができますが、100の初期デフォルトクォータがあります。 このクォータは、Azureサポートに連絡することで解除できます。
- コレクションはスケールの単位であるだけでなく、コストの単位でもあるため、DocumentDBではコレクションごとに支払います。これには最大10 GBのストレージ容量があります。
- 月に約25ドルかかるデータベースにドキュメントを保存するには、少なくとも1つのS1コレクションが必要です。これは、Azureサブスクリプションに対して請求されます。
- データベースのサイズが大きくなり、10 GBを超えると、追加のデータを含めるために別のコレクションを購入する必要があります。
- 各S1コレクションは1秒あたり250リクエストユニットを提供しますが、それで十分でない場合は、コレクションをS2に拡大し、1か月あたり約50ドルで1000リクエストユニットを取得できます。
- また、S3まですべての方法で有効にして、月額約100ドルを支払うこともできます。
DocumentDB-利点
DocumentDBは、非常にユニークな機能を備えています。 Azure DocumentDBは、次の主要な機能と利点を提供します。
スキーマフリー
リレーショナルデータベースでは、すべてのテーブルに、テーブル内の各行が準拠する必要がある列とデータ型を定義するスキーマがあります。
対照的に、ドキュメントデータベースにはスキーマが定義されておらず、すべてのドキュメントを異なる構造にすることができます。
SQL構文
DocumentDBは、SQL言語を使用した複雑なアドホッククエリを可能にし、すべてのドキュメントは作成された瞬間に即座にクエリ可能です。 ドキュメント階層内の任意の場所で任意のプロパティを検索できます。
調整可能な一貫性
細かく、明確に定義された一貫性レベルを提供します。これにより、一貫性、可用性、待機時間の間で適切なトレードオフを行うことができます。
4つの明確に定義された一貫性レベルから選択して、一貫性とパフォーマンスの最適なトレードオフを実現できます。 クエリと読み取り操作について、DocumentDBは4つの異なる一貫性レベルを提供します-
- 強い
- 限定された陳腐化
- セッション
- 最終的に
弾性スケール
スケーラビリティはNoSQLを使用したゲームの名前であり、DocumentDBが提供します。 DocumentDBはすでにその規模が証明されています。
- Office OneNoteやXboxなどの主要なサービスは、数十テラバイトのJSONドキュメント、100万人を超えるアクティブユーザーを含み、99.95%の可用性で一貫して動作するデータベースを備えたDocumentDBによって既にサポートされています。
- アプリケーションの成長に応じてより多くのユニットを作成することにより、予測可能なパフォーマンスでDocumentDBを柔軟に拡張できます。
完全管理
DocumentDBは、Azure上で実行されるサービスとして、完全に管理されたクラウドベースのプラットフォームとして利用できます。
- インストールまたは管理するものは何もありません。
- サーバー、ケーブル、オペレーティングシステムまたは更新プログラム、セットアップするレプリカはありません。
- マイクロソフトはすべての作業を行い、サービスを実行し続けます。
- 文字通り数分以内に、ブラウザーとAzureサブスクリプションだけを使用してDocumentDBの使用を開始できます。
DocumentDB-環境設定
Microsoftは、SQL Serverを含むVisual Studioの無料バージョンを提供しており、https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx [[[1]] .visualstudio.com]
インストール
- ステップ1 *-ダウンロードが完了したら、インストーラーを実行します。 次のダイアログが表示されます。
- ステップ2 *-[インストール]ボタンをクリックすると、インストールプロセスが開始されます。
- ステップ3 *-インストールプロセスが正常に完了すると、次のダイアログが表示されます。
- ステップ4 *-このダイアログを閉じて、必要に応じてコンピューターを再起動します。
- ステップ5 *-次のダイアログを開く[スタート]メニューからVisual Studioを開きます。 準備のためだけに初めて時間がかかります。
すべてが完了すると、Visual Studioのメインウィンドウが表示されます。
- ステップ6 *-ファイル→新規→プロジェクトから新しいプロジェクトを作成しましょう。
- ステップ7 *-コンソールアプリケーションを選択し、[名前]フィールドにDocumentDBDemoと入力して[OK]ボタンをクリックします。
- ステップ8 *-ソリューションエクスプローラーで、プロジェクトを右クリックします。
- ステップ9 *-[NuGetパッケージの管理]を選択すると、Visual Studioで次のウィンドウが開き、[オンライン検索]入力ボックスでDocumentDB Client Libraryが検索されます。
- ステップ10 *-インストールボタンをクリックして最新バージョンをインストールします。
- ステップ11 *-[同意する]をクリックします。 インストールが完了すると、出力ウィンドウにメッセージが表示されます。
これで、アプリケーションを開始する準備ができました。
DocumentDB-アカウントの作成
Microsoft Azure DocumentDBを使用するには、DocumentDBアカウントを作成する必要があります。 この章では、Azureポータルを使用してDocumentDBアカウントを作成します。
- ステップ1 *-Azureサブスクリプションを既にお持ちの場合は、オンラインhttps://portal.azure.comにログインします。それ以外の場合は、最初にサインインする必要があります。
メインのダッシュボードが表示されます。 完全にカスタマイズできるので、これらのタイルを好きなように配置したり、サイズを変更したり、頻繁に使用する、または使用しなくなったタイルを追加および削除したりできます。
- ステップ2 *-ページの左上にある[新規]オプションを選択します。
- ステップ3 *-データ+を選択します。 [ストレージ]> [Azure DocumentDB]オプションを選択すると、次の[新しいDocumentDBアカウント]セクションが表示されます。
グローバルに一意の名前(ID)を作成する必要があります。これは.documents.azure.comと組み合わせて、DocumentDBアカウントへのパブリックにアドレス可能なエンドポイントです。 このアカウントの下に作成するすべてのデータベースには、このエンドポイントを使用してインターネット経由でアクセスできます。
- ステップ4 *-azuredocdbdemoという名前を付けて、[リソースグループ]→[new_resource]をクリックします。
- ステップ5 *-場所、つまり、このアカウントをホストするMicrosoftデータセンターを選択します。 場所を選択し、地域を選択します。
- ステップ6 *-[ダッシュボードに固定]チェックボックスをオンにし、[作成]ボタンをクリックします。
タイルが既にダッシュボードに追加されており、アカウントが作成されていることがわかります。 DocumentDBがエンドポイントを割り当て、レプリカをプロビジョニングし、バックグラウンドで他の作業を実行している間、実際には新しいアカウントの設定に数分かかる場合があります。
完了すると、ダッシュボードが表示されます。
- ステップ7 *-作成されたDocumentDBアカウントをクリックすると、次の画像のような詳細画面が表示されます。
DocumentDB-アカウントの接続
DocumentDBに対するプログラミングを開始するとき、最初のステップは接続です。 したがって、DocumentDBアカウントに接続するには、2つのことが必要です。
- 終点
- 認証キー
終点
エンドポイントはDocumentDBアカウントのURLであり、DocumentDBアカウント名と.documents.azure.comを組み合わせて作成されます。 ダッシュボードに行きましょう。
次に、作成したDocumentDBアカウントをクリックします。 次の図に示すように、詳細が表示されます。
[キー]オプションを選択すると、次の画像に示すように追加情報が表示されます。 また、エンドポイントとして使用できるDocumentDBアカウントのURLも表示されます。
認証キー
認証キーには資格情報が含まれ、2種類のキーがあります。 マスターキーはアカウント内のすべてのリソースへのフルアクセスを許可し、リソーストークンは特定のリソースへの制限付きアクセスを許可します。
マスターキー
- マスターキーでできないことは何もありません。 マスターキーを使用して、必要に応じてデータベース全体を削除できます。
- このため、マスターキーを共有したり、クライアント環境に配布したりすることは絶対に望まないでしょう。 追加のセキュリティ対策として、頻繁に変更することをお勧めします。
- 上記のスクリーンショットで強調表示されているように、実際には各データベースアカウントにプライマリキーとセカンダリキーの2つのマスターキーがあります。
リソーストークン
- マスターキーの代わりにリソーストークンを使用することもできます。
- リソーストークンに基づく接続は、トークンで指定されたリソースにのみアクセスでき、他のリソースにはアクセスできません。
- リソーストークンはユーザー権限に基づいているため、最初に1人以上のユーザーを作成します。これらのユーザーはデータベースレベルで定義されます。
- 各ユーザーにアクセスを許可するリソースに基づいて、各ユーザーに1つ以上のアクセス許可を作成します。
- 各アクセス許可は、特定のリソースへの読み取り専用アクセスまたはフルアクセスのいずれかを許可し、データベース内の任意のユーザーリソースにできるリソーストークンを生成します。
第3章で作成したコンソールアプリケーションに行きましょう。
- ステップ1 *-Program.csファイルに次の参照を追加します。
- ステップ2 *-エンドポイントURLと認証キーを追加します。 この例では、主キーを認証キーとして使用します。
あなたの場合、エンドポイントURLと認証キーの両方が異なる必要があることに注意してください。
- ステップ3 *-CreateDocumentClientと呼ばれる非同期タスクでDocumentClientの新しいインスタンスを作成し、新しいDocumentClientをインスタンス化します。
- ステップ4 *-Mainメソッドから非同期タスクを呼び出します。
以下は、これまでの完全なProgram.csファイルです。
この章では、DocumentDBアカウントに接続し、DocumentClientクラスのインスタンスを作成する方法を学びました。
DocumentDB-データベースの作成
この章では、データベースの作成方法を学びます。 Microsoft Azure DocumentDBを使用するには、DocumentDBアカウント、データベース、コレクション、およびドキュメントが必要です。 私たちはすでにDocumentDBアカウントを持っています、今データベースを作成するために2つのオプションがあります-
- Microsoft Azure Portalまたは
- .Net SDK
Microsoft Azureポータルを使用してDocumentDBのデータベースを作成する
ポータルを使用してデータベースを作成するには、次の手順に従います。
- ステップ1 *-Azureポータルにログインすると、ダッシュボードが表示されます。
- ステップ2 *-作成されたDocumentDBアカウントをクリックすると、次のスクリーンショットに示すように詳細が表示されます。
- ステップ3 *-[データベースの追加]オプションを選択し、データベースのIDを指定します。
- ステップ4 *-[OK]をクリックします。
データベースが追加されていることがわかります。 現時点ではコレクションはありませんが、後でJSONドキュメントを格納するコンテナであるコレクションを追加できます。 IDとリソースIDの両方があることに注意してください。
.Net SDKを使用してDocumentDB用のデータベースを作成する
Net SDKを使用してデータベースを作成するには、次の手順に従います。.
- ステップ1 *-前の章のVisual Studioでコンソールアプリケーションを開きます。
- ステップ2 *-新しいデータベースオブジェクトを作成して、新しいデータベースを作成します。 新しいデータベースを作成するには、CreateDatabaseタスクで「mynewdb」に設定しているIdプロパティを割り当てるだけです。
- ステップ3 *-このdatabaseDefinitionをCreateDatabaseAsyncに渡し、Resourceプロパティで結果を取得します。 すべてのオブジェクト作成メソッドは、作成されたアイテム(この場合はデータベース)を説明するResourceプロパティを返します。
Resourceプロパティから新しいデータベースオブジェクトを取得し、DocumentDBが割り当てたリソースIDとともにコンソールに表示されます。
- ステップ4 *-DocumentClientがインスタンス化された後、CreateDocumentClientタスクからCreateDatabaseタスクを呼び出します。
以下は、これまでの完全なProgram.csファイルです。
上記のコードをコンパイルして実行すると、データベースとリソースIDを含む次の出力を受け取ります。
DocumentDB-データベースのリスト
これまで、DocumentDBアカウントに2つのデータベースを作成しました。1つ目はAzureポータルを使用して作成され、2つ目は.Net SDKを使用して作成されます。 これらのデータベースを表示するには、Azureポータルを使用できます。
AzureポータルでDocumentDBアカウントに移動すると、2つのデータベースが表示されます。
Net SDKを使用して、コードからデータベースを表示またはリストすることもできます。 以下は関連する手順です。.
- ステップ1 *-完全なリストを返すパラメータなしでデータベースクエリを発行しますが、特定のデータベースを検索するクエリを渡すこともできます。
コレクション、ドキュメント、ユーザー、およびその他のリソースを見つけるためのこれらのCreateQueryメソッドが多数あることがわかります。 これらのメソッドは実際にクエリを実行するのではなく、クエリを定義して反復可能なオブジェクトを返すだけです。
クエリを実際に実行し、結果を繰り返し、リストで返すのは、ToList()の呼び出しです。
- ステップ2 *-DocumentClientがインスタンス化された後、CreateDocumentClientタスクからGetDatabasesメソッドを呼び出します。
- ステップ3 *-CreateDatabaseタスクにコメントするか、データベースIDを変更する必要もあります。そうしないと、データベースが存在するというエラーメッセージが表示されます。
以下は、これまでの完全なProgram.csファイルです。
上記のコードをコンパイルして実行すると、両方のデータベースのデータベースIDとリソースIDを含む次の出力が表示されます。 最後に、データベースの合計数も表示されます。
DocumentDB-データベースの削除
Net SDKを使用して、ポータルおよびコードからデータベースを削除できます。 ここでは、DocumentDBにデータベースをドロップする方法を段階的に説明します。.
- ステップ1 *-AzureポータルでDocumentDBアカウントに移動します。 デモの目的で、次のスクリーンショットに示すように、さらに2つのデータベースを追加しました。
- ステップ2 *-データベースを削除するには、そのデータベースをクリックする必要があります。 tempdbを選択して、次のページが表示されたら、[データベースの削除]オプションを選択します。
- ステップ3 *-確認メッセージが表示されたら、[はい]ボタンをクリックします。
tempdbがダッシュボードで使用できなくなっていることがわかります。
Net SDKを使用して、コードからデータベースを削除することもできます。 以下が手順です。.
- ステップ1 *-削除するデータベースのIDを指定してデータベースを削除しますが、SelfLinkが必要です。
- ステップ2 *-以前と同様にCreateDatabaseQueryを呼び出していますが、今回はID tempdb1を持つ1つのデータベースのみを返すクエリを実際に提供しています。
- ステップ3 *-今回は、実際にはリストオブジェクトが必要ないため、ToList()の代わりにAsEnumerableを呼び出すことができます。 結果のみを期待し、AsEnumerableを呼び出すだけで、First()を使用してクエリによって返される最初のデータベースオブジェクトを取得できます。 これはtempdb1のデータベースオブジェクトであり、データベースを削除するDeleteDatabaseAsyncを呼び出すために使用できるSelfLinkがあります。
- ステップ4 *-DocumentClientがインスタンス化された後、CreateDocumentClientタスクからDeleteDatabaseタスクを呼び出す必要もあります。
- ステップ5 *-指定したデータベースを削除した後、データベースのリストを表示するには、GetDatabasesメソッドを再度呼び出します。
以下は、これまでの完全なProgram.csファイルです。
上記のコードがコンパイルおよび実行されると、3つのデータベースのデータベースIDとリソースID、およびデータベースの総数を含む次の出力を受け取ります。
データベースを削除すると、最後にDocumentDBアカウントに2つのデータベースのみが残っていることもわかります。
DocumentDB-コレクションの作成
この章では、コレクションを作成する方法を学びます。 データベースの作成に似ています。 .Net SDKを使用して、ポータルまたはコードからコレクションを作成できます。
- ステップ1 *-Azureポータルのメインダッシュボードに移動します。
- ステップ2 *-データベースリストからmyfirstdbを選択します。
- ステップ3 *-[コレクションの追加]オプションをクリックして、コレクションのIDを指定します。 別のオプションの価格帯を選択します。
- ステップ4 *-S1 Standardを選択して、選択→OKボタンをクリックします。
ご覧のとおり、MyCollectionがmyfirstdbに追加されています。
Net SDKを使用して、コードからコレクションを作成することもできます。 コードからコレクションを追加する次の手順を見てみましょう。.
- ステップ1 *-Visual Studioでコンソールアプリケーションを開きます。
- ステップ2 *-コレクションを作成するには、まずCreateDocumentClientタスクでそのIDによってmyfirstdbデータベースを取得します。
以下は、CreateCollectionタスクの実装です。
CreateDocumentCollectionAsyncメソッドの目的のIDを使用して新しいコレクションを定義する新しいDocumentCollectionオブジェクトを作成します。このメソッドは、ここで使用するoptionsパラメーターも受け入れ、offerTypeを呼び出す新しいコレクションのパフォーマンス層を設定します。
これはデフォルトでS1になり、MyCollection1に対してofferTypeを渡さなかったため、これはS1コレクションになり、MyCollection2に対しては、上記に示すようにこれをS2にするS2を渡しました。
以下は、ViewCollectionメソッドの実装です。
以下は、コレクション用のprogram.csファイルの完全な実装です。
上記のコードをコンパイルして実行すると、コレクションに関連するすべての情報を含む次の出力を受け取ります。
DocumentDB-コレクションの削除
1つまたは複数のコレクションをドロップするには、.Net SDKを使用して、ポータルおよびコードから同じことを実行できます。
- ステップ1 *-AzureポータルでDocumentDBアカウントに移動します。 デモの目的で、次のスクリーンショットに示すように、さらに2つのコレクションを追加しました。
- ステップ2 *-コレクションを削除するには、そのコレクションをクリックする必要があります。 TempCollection1を選択しましょう。 次のページが表示されます。[コレクションを削除]オプションを選択します。
- ステップ3 *-確認メッセージが表示されます。 [はい]ボタンをクリックします。
TempCollection1がダッシュボードで使用できなくなっていることがわかります。
Net SDKを使用して、コードからコレクションを削除することもできます。 それを行うには、次の手順に従います。.
- ステップ1 *-削除するコレクションのIDを指定して、コレクションを削除しましょう。
リソースを削除するために必要なselfLinksを取得するための、Idによるクエリの通常のパターンです。
ここでは、パラメーター化されたクエリを作成する好ましい方法を示します。 collectionIdをハードコーディングしていないため、このメソッドを使用してコレクションを削除できます。 このSqlQuerySpecのパラメーターのプロパティに割り当てられたこのSqlParameterCollectionでIdパラメーターが定義されている場合、Idによって特定のコレクションを照会しています。
次に、SDKは、その内部にcollectionIdが埋め込まれたDocumentDBの最終クエリ文字列を構築する作業を行います。
- ステップ2 *-クエリを実行し、SelfLinkを使用してCreateDocumentClientタスクからコレクションを削除します。
以下は、Program.csファイルの完全な実装です。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
DocumentDB-文書の挿入
この章では、コレクション内の実際のドキュメントを操作します。 Azureポータルまたは.Net SDKを使用してドキュメントを作成できます。
Azure Portalでドキュメントを作成する
コレクションにドキュメントを追加するには、次の手順を見てみましょう。
- ステップ1 *-myfirstdbに新しいコレクションファミリーのS1価格設定層を追加します。
- ステップ2 *-ファミリコレクションを選択し、[ドキュメントの作成]オプションをクリックして、[新しいドキュメント]ブレードを開きます。
これは、新しいドキュメントのJSONを入力できるシンプルなテキストエディターです。
- ステップ3 *-これは生データの入力なので、最初のドキュメントを入力しましょう。
上記のドキュメントを入力すると、次の画面が表示されます。
ドキュメントのidを指定したことに注意してください。 id値は常に必須であり、同じコレクション内の他のすべてのドキュメントで一意である必要があります。 省略すると、GUIDまたはグローバル一意識別子を使用してDocumentDBが自動的に生成します。
idは常に文字列であり、数値、日付、ブール値、または別のオブジェクトにすることはできません。また、255文字を超えることはできません。
また、必要なidのようないくつかのトップレベルプロパティ、lastName、isRegisteredがありますが、ネストされたプロパティもあるドキュメントの階層構造に注目してください。
たとえば、parentsプロパティは、角括弧で示されるJSON配列として提供されます。 この例では、配列に子が1つしかない場合でも、子用の別の配列もあります。
- ステップ4 *-[保存]ボタンをクリックしてドキュメントを保存すると、最初のドキュメントが作成されました。
かなりの書式設定がJSONに適用されていることがわかります。これにより、各プロパティのネストレベルを伝えるために空白でインデントされた独自の行のすべてのプロパティが分割されます。
ポータルにはドキュメントエクスプローラーが含まれているため、ここで作成したドキュメントを取得するために使用します。
- ステップ5 *-データベースとデータベース内のコレクションを選択して、そのコレクション内のドキュメントを表示します。 現在、Familysという1つのコレクションを持つmyfirstdbという名前のデータベースが1つだけあり、両方のドロップダウンリストで事前に選択されています。
デフォルトでは、ドキュメントエクスプローラにはコレクション内のドキュメントのフィルタリングされていないリストが表示されますが、特定のドキュメントをIDで検索したり、部分的なIDのワイルドカード検索に基づいて複数のドキュメントを検索したりすることもできます。
これまでのコレクションにはドキュメントが1つしかなく、そのIDは次の画面AndersonFamilyに表示されます。
- ステップ6 *-IDをクリックしてドキュメントを表示します。
.NET SDKを使用したドキュメントの作成
ドキュメントは別の種類のリソースであり、SDKを使用してリソースを処理する方法に既に慣れていることはご存じでしょう。
- ドキュメントと他のリソースの大きな違いの1つは、もちろん、スキーマが無料であることです。
- したがって、多くのオプションがあります。 当然、JSONオブジェクトグラフまたはJSONテキストの生の文字列だけで作業できますが、コンパイル時にクラスを定義せずに実行時にプロパティにバインドできる動的オブジェクトを使用することもできます。
- また、実際のC#オブジェクト、またはそれらが呼び出されたエンティティ(ビジネスドメインクラス)を操作することもできます。
Net SDKを使用してドキュメントの作成を始めましょう。 手順は次のとおりです。.
- ステップ1 *-DocumentClientをインスタンス化し、myfirstdbデータベースを照会してから、MyCollectionコレクションを照会します。MyCollectionコレクションは、このプライベート変数コレクションに格納し、クラス全体でアクセスできるようにします。
- ステップ2 *-CreateDocumentsタスクでいくつかのドキュメントを作成します。
最初のドキュメントは、この動的オブジェクトから生成されます。 これはJSONのように見えるかもしれませんが、もちろんそうではありません。 これはC#コードであり、実際の.NETオブジェクトを作成していますが、クラス定義はありません。 代わりに、プロパティはオブジェクトの初期化方法から推測されます。
このドキュメントのIdプロパティを指定していないことに注意してください。
それでは、CreateDocumentを見てみましょう。 データベースとコレクションの作成で見たのと同じパターンのように見えます。
- ステップ3 *-今回は、ドキュメントを追加するコレクションのSelfLinkを指定してCreateDocumentAsyncを呼び出します。 この場合、システムによって生成されたプロパティを持つ新しいドキュメントを表すリソースプロパティを持つ応答が返されます。
Documentオブジェクトは、リソースから継承するSDKで定義されたクラスであるため、すべての共通リソースプロパティがありますが、スキーマフリードキュメント自体を定義する動的プロパティも含まれています。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
ご覧のとおり、IDは提供していませんが、DocumentDBが新しいドキュメント用にこのIDを生成しました。
DocumentDB-クエリドキュメント
DocumentDBでは、実際にSQLを使用してドキュメントを照会するため、この章では、DocumentDBの特別なSQL構文を使用した照会について説明します。 .NET開発を行っている場合は、使用でき、LINQクエリから適切なSQLを生成できるLINQプロバイダーもあります。
ポータルを使用したドキュメントのクエリ
Azureポータルには、DocumentDBデータベースに対してSQLクエリを実行できるクエリエクスプローラーがあります。
クエリエクスプローラーを使用して、可能な限り単純なクエリから始めて、クエリ言語のさまざまな機能を紹介します。
- ステップ1 *-データベースブレードで、クリックしてQuery Explorerブレードを開きます。
クエリはコレクションのスコープ内で実行されるため、クエリエクスプローラーでは、このドロップダウンでコレクションを選択できます。
- ステップ2 *-ポータルを使用して以前に作成されたファミリコレクションを選択します。
クエリエクスプローラーは、コレクションからすべてのドキュメントを取得するだけの簡単なクエリSELECT * FROM cで開きます。
- ステップ3 *-[クエリの実行]ボタンをクリックして、このクエリを実行します。 次に、[結果]ブレードで完全なドキュメントが取得されることがわかります。
.Net SDKを使用したドキュメントのクエリ
以下は、.Net SDKを使用していくつかのドキュメントクエリを実行する手順です。
この例では、追加したばかりの新しく作成されたドキュメントを照会します。
- ステップ1 *-CreateDocumentQueryを呼び出し、コレクションを渡してSelfLinkとクエリテキストによってクエリを実行します。
このクエリはコレクション全体のすべてのドキュメントも返しますが、以前のようにCreateDocumentQueryで.ToListを呼び出していません。これにより、1行のコードですべての結果を取得するために必要な数のリクエストが発行されます。
- ステップ2 *-代わりに、AsDocumentQueryを呼び出すと、このメソッドはHasMoreResultsプロパティを持つクエリオブジェクトを返します。
- ステップ3 *-HasMoreResultsがtrueの場合、ExecuteNextAsyncを呼び出して次のチャンクを取得し、そのチャンクのすべての内容をダンプします。
- ステップ4 *-必要に応じて、SQLの代わりにLINQを使用してクエリすることもできます。 ここでは、qでLINQクエリを定義しましたが、.ToListを実行するまで実行されません。
SDKはLINQクエリをDocumentDBのSQL構文に変換し、LINQ構文に基づいてSELECT句とWHERE句を生成します
- ステップ5 *-CreateDocumentClientタスクから上記のクエリを呼び出します。
上記のコードが実行されると、次の出力が表示されます。
DocumentDB-ドキュメントの更新
この章では、ドキュメントを更新する方法を学びます。 Azureポータルを使用すると、ドキュメントエクスプローラーでドキュメントを開き、エディターでテキストファイルのように更新することで、ドキュメントを簡単に更新できます。
[保存]ボタンをクリックします。 これで、.Net SDKを使用してドキュメントを変更する必要がある場合、それを置き換えることができます。 削除して再作成する必要はありません。面倒なことに加えて、リソースIDも変更します。これは、ドキュメントを変更するだけでは不要です。 .Net SDKを使用してドキュメントを更新するための次の手順を示します。
次のReplaceDocumentsタスクを見てみましょう。isNewプロパティがtrueであるドキュメントを照会しますが、何もないので何も取得しません。 それでは、先ほど追加したドキュメントで、名前がNew Customerで始まるドキュメントを変更しましょう。
- ステップ1 *-これらのドキュメントにisNewプロパティを追加し、その値をtrueに設定します。
- ステップ2 *-同じSTARTSWITHクエリを使用して更新するドキュメントを取得します。これにより、動的オブジェクトとしてここに戻ってきたドキュメントが得られます。
- ステップ3 *-isNewプロパティを添付し、各ドキュメントに対してtrueに設定します。
- ステップ4 *-ReplaceDocumentAsyncを呼び出して、更新されたドキュメントとともにドキュメントのSelfLinkを渡します。
これが機能することを証明するために、isNewがtrueに等しいドキュメントを照会します。 CreateDocumentClientタスクから上記のクエリを呼び出しましょう。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
DocumentDB-ドキュメントの削除
この章では、DocumentDBアカウントからドキュメントを削除する方法を学びます。 Azure Portalを使用すると、ドキュメントエクスプローラーでドキュメントを開き、[削除]オプションをクリックして、ドキュメントを簡単に削除できます。
確認メッセージが表示されます。 [はい]ボタンを押すと、DocumentDBアカウントでドキュメントが使用できなくなっていることがわかります。
Net SDKを使用してドキュメントを削除する場合。.
- ステップ1 *-これは、新しいドキュメントごとにSelfLinksを取得するために最初にクエリを行う場所で見たパターンと同じです。 ここではSELECT *を使用しません。これはドキュメント全体を返すため、必要ありません。
- ステップ2 *-代わりに、SelfLinksをリストに選択し、SelfLinkごとにDeleteDocumentAsyncを一度に1つずつ呼び出して、コレクションからドキュメントを削除します。
- ステップ3 *-次に、CreateDocumentClientタスクから上記のDeleteDocumentsを呼び出します。
上記のコードが実行されると、次の出力が表示されます。
DocumentDB-データモデリング
DocumentDBのようなスキーマフリーデータベースを使用すると、データモデルへの変更を非常に簡単に取り入れることができますが、データについて考えるのにしばらく時間をかける必要があります。
- あなたにはたくさんの選択肢があります。 当然、JSONオブジェクトグラフまたはJSONテキストの生の文字列だけで作業できますが、コンパイル時にクラスを定義せずに実行時にプロパティにバインドできる動的オブジェクトを使用することもできます。
- また、実際のC#オブジェクト、またはそれらが呼び出されたエンティティ(ビジネスドメインクラス)を操作することもできます。
関係
ドキュメントの階層構造を見てみましょう。 必要なid、lastName、isRegisteredなどのトップレベルプロパティがいくつかありますが、ネストされたプロパティもあります。
- たとえば、parentsプロパティは、角括弧で示されるJSON配列として提供されます。
- この例では、配列に子が1つしかない場合でも、子用の別の配列もあります。 これが、ドキュメント内の1対多の関係に相当するものをモデル化する方法です。
- 単純に配列を使用します。配列内の各要素は、単純な値または別の複雑なオブジェクト、さらに別の配列になります。
- したがって、1つの家族は複数の親と複数の子を持つことができ、子オブジェクトを見ると、それ自体が子とペットの1対多の関係のネストされた配列であるペットのプロパティを持っています。
- locationプロパティについては、3つの関連するプロパティ、州、郡、市をオブジェクトに結合しています。
- オブジェクトの配列を埋め込むのではなく、この方法でオブジェクトを埋め込むことは、リレーショナルデータベースの別々のテーブルにある2つの行の間に1対1の関係を持たせることに似ています。
データを埋め込む
DocumentDBなどのドキュメントストアでデータのモデリングを開始するときは、エンティティをJSONで表される自己完結型ドキュメントとして扱うようにしてください。 リレーショナルデータベースを使用する場合、常にデータを正規化します。
- データを正規化するには、通常、顧客などのエンティティを取得し、連絡先の詳細や住所などの個別のデータに分割します。
- 連絡先の詳細と住所をすべて記載した顧客を読むには、JOINSを使用して実行時にデータを効果的に集約する必要があります。
ここで、ドキュメントデータベースの自己完結型エンティティと同じデータをモデル化する方法を見てみましょう。
ご覧のとおり、顧客のすべての情報が単一のJSONドキュメントに埋め込まれている顧客レコードを非正規化しています。
NoSQLには無料のスキーマがあるため、連絡先の詳細と住所を異なる形式で追加することもできます。 NoSQLでは、1回の読み取り操作でデータベースから顧客レコードを取得できます。 同様に、レコードの更新も単一の書き込み操作です。
以下は、.Net SDKを使用してドキュメントを作成する手順です。
- ステップ1 *-DocumentClientをインスタンス化します。 次に、myfirstdbデータベースを照会し、MyCollectionコレクションを照会します。MyCollectionコレクションは、このプライベート変数コレクションに格納し、クラス全体でアクセスできるようにします。
- ステップ2 *-CreateDocumentsタスクでいくつかのドキュメントを作成します。
最初のドキュメントは、この動的オブジェクトから生成されます。 これはJSONのように見えるかもしれませんが、もちろんそうではありません。 これはC#コードであり、実際の.NETオブジェクトを作成していますが、クラス定義はありません。 代わりに、プロパティはオブジェクトの初期化方法から推測されます。 また、このドキュメントのIdプロパティが提供されていないことにも気づくでしょう。
- ステップ3 *-次に、CreateDocumentを見てみましょう。データベースとコレクションの作成で見たのと同じパターンのように見えます。
- ステップ4 *-今回は、ドキュメントを追加するコレクションのSelfLinkを指定してCreateDocumentAsyncを呼び出します。 この場合、システムによって生成されたプロパティを持つ新しいドキュメントを表すリソースプロパティを持つ応答が返されます。
次のCreateDocumentsタスクでは、3つのドキュメントを作成しました。
- 最初のドキュメントでは、Documentオブジェクトはリソースから継承するSDKで定義されたクラスであるため、すべての共通リソースプロパティがありますが、スキーマフリードキュメント自体を定義する動的プロパティも含まれています。
- この2番目のドキュメントは、生のJSON文字列でのみ機能します。 ここで、JavaScriptSerializerを使用して文字列をオブジェクトに逆シリアル化するCreateDocumentのオーバーロードにステップインし、最初のドキュメントの作成に使用したのと同じCreateDocumentメソッドに渡します。
- 3番目のドキュメントでは、アプリケーションで定義されているC#オブジェクトCustomerを使用しました。
この顧客を見てみましょう。IDとアドレスのプロパティがあります。アドレスは、さらに別のネストされたオブジェクトである場所を含む独自のプロパティを持つネストされたオブジェクトです。
また、フェンスの両側で適切な規則を維持したいため、JSONプロパティ属性も用意されています。
したがって、ネストされた子オブジェクトと共にNew Customerオブジェクトを作成し、CreateDocumentをもう一度呼び出します。 顧客オブジェクトにはIdプロパティがありますが、値を提供しなかったため、DocumentDBは前の2つのドキュメントの場合と同様に、GUIDに基づいて値を生成しました。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
DocumentDB-データ型
JSONまたはJavaScript Object Notationは、人間が読めるデータ交換用に設計された軽量のテキストベースのオープンスタンダードであり、マシンが解析および生成するのも簡単です。 JSONはDocumentDBの中心です。 JSONをネットワーク経由で送信し、JSONをJSONとして保存し、JSONツリーにインデックスを付けて、完全なJSONドキュメントでクエリを実行できるようにします。
JSON形式は次のデータ型をサポートしています-
S.No. | Type & Description |
---|---|
1 |
Number JavaScriptの倍精度浮動小数点形式 |
2 |
String バックスラッシュをエスケープする二重引用符付きUnicode |
3 |
Boolean 正しいか間違っているか |
4 |
Array 値の順序付けられたシーケンス |
5 |
Value 文字列、数値、trueまたはfalse、nullなどを指定できます。 |
6 |
Object キーと値のペアの順不同のコレクション |
7 |
Whitespace トークンの任意のペア間で使用できます |
8 |
Null 空の |
単純なDateTime型の例を見てみましょう。 生年月日を顧客クラスに追加します。
次のコードに示すように、DateTimeを使用して保存、取得、クエリを実行できます。
上記のコードをコンパイルして実行し、ドキュメントを作成すると、生年月日が追加されたことがわかります。
DocumentDB-レコードの制限
Microsoftは最近、SQL文法のTOPキーワードなど、Azure DocumentDBのクエリ方法にいくつかの改善を追加しました。これにより、クエリの実行が速くなり、リソースの消費が少なくなり、クエリ演算子の制限が増加し、追加のLINQ演算子のサポートが追加されました.NET SDK。
最初の2つのレコードのみを取得する簡単な例を見てみましょう。 多数のレコードがあり、それらの一部のみを取得する場合は、Topキーワードを使用できます。 この例では、地震の記録がたくさんあります。
ここで、最初の2つのレコードのみを表示します
- ステップ1 *-クエリエクスプローラーに移動して、このクエリを実行します。
TOPキーワードをまだ指定していないため、4つのレコードが取得されていることがわかります。
- ステップ2 *-同じクエリでTOPキーワードを使用します。 ここでは、TOPキーワードを指定しました。「2」は、2つのレコードのみが必要であることを意味します。
- ステップ3 *-このクエリを実行すると、2つのレコードのみが取得されることがわかります。
同様に、.Net SDKを使用してコードでTOPキーワードを使用できます。 以下は実装です。
以下は、DocumentClientおよび地震データベースをインスタンス化するCreateDocumentClientタスクです。
上記のコードをコンパイルして実行すると、3つのレコードのみが取得されることがわかります。
DocumentDB-レコードの並べ替え
Microsoft Azure DocumentDBは、SQL over JSONドキュメントを使用したドキュメントのクエリをサポートしています。 クエリでORDER BY句を使用して、コレクション内のドキュメントを数字と文字列で並べ替えることができます。 句には、オプションのASC/DESC引数を含めて、結果を取得する必要がある順序を指定できます。
JSONドキュメントがある次の例を見てみましょう。
以下は、結果を降順で並べ替えるSQLクエリです。
上記のクエリを実行すると、次の出力が表示されます。
DocumentDB-レコードのインデックス作成
デフォルトでは、DocumentDBは、ドキュメントがデータベースに追加されるとすぐに、ドキュメント内のすべてのプロパティに自動的にインデックスを付けます。 ただし、インデックスを作成する必要のない特定のドキュメントやプロパティがある場合、ストレージと処理のオーバーヘッドを削減する独自のインデックスポリシーを制御および微調整できます。
すべてのプロパティに自動的にインデックスを付けるようにDocumentDBに指示するデフォルトのインデックスポリシーは、多くの一般的なシナリオに適しています。 ただし、インデックスを作成するものとしないものを正確に制御するカスタムポリシーや、インデックス作成に関するその他の機能を実装することもできます。
DocumentDBは、次の種類のインデックス作成をサポートしています-
- Hash
- 範囲
Hash
ハッシュインデックスを使用すると、等しいかどうかの効率的なクエリが可能になります。つまり、特定のプロパティがより小さい、より大きい、または間の値の範囲で一致するのではなく、正確な値に等しいドキュメントを検索します。
ハッシュインデックスを使用して範囲クエリを実行できますが、DocumentDBは一致するドキュメントを見つけるためにハッシュインデックスを使用できず、代わりに各ドキュメントを順次スキャンして範囲クエリで選択する必要があるかどうかを判断する必要があります。
ハッシュインデックスだけのプロパティでORDER BY句を使用してドキュメントを並べ替えることはできません。
範囲
プロパティに定義された範囲インデックス、DocumentDBにより、値の範囲に対してドキュメントを効率的に照会できます。 また、ORDER BYを使用して、そのプロパティのクエリ結果を並べ替えることができます。
DocumentDBでは、任意またはすべてのプロパティでハッシュと範囲インデックスの両方を定義できます。これにより、効率的な等価クエリと範囲クエリ、およびORDER BYが可能になります。
インデックス作成ポリシー
すべてのコレクションには、すべてのドキュメントのすべてのプロパティの数値と文字列に使用されるインデックスのタイプを指定するインデックスポリシーがあります。
- また、ドキュメントがコレクションに追加されるときに、ドキュメントのインデックスを自動的に作成するかどうかも制御できます。
- 自動インデックスはデフォルトで有効になっていますが、ドキュメントを追加するときにその動作をオーバーライドして、DocumentDBにその特定のドキュメントのインデックスを作成しないように指示できます。
- 自動インデックス作成を無効にして、デフォルトでドキュメントがコレクションに追加されたときにインデックスが作成されないようにすることができます。 同様に、ドキュメントレベルでこれをオーバーライドし、特定のドキュメントをコレクションに追加するときにDocumentDBにインデックスを作成するように指示できます。 これは、手動インデックス付けと呼ばれます。
インデックス作成を含める/除外する
インデックス作成ポリシーでは、インデックスに含めるパスまたは除外するパスを定義することもできます。 これは、クエリを実行しないドキュメントの特定の部分と実行する特定の部分があることがわかっている場合に役立ちます。
これらの場合、コレクションに追加された各ドキュメントの特定の部分のみをインデックス付けするようにDocumentDBに指示することにより、インデックス付けのオーバーヘッドを削減できます。
自動索引付け
自動インデックス作成の簡単な例を見てみましょう。
- ステップ1 *-最初に自動インデックス付けと呼ばれるコレクションを作成し、明示的にポリシーを指定せずに、このコレクションはデフォルトのインデックス付けポリシーを使用します。つまり、このコレクションで自動インデックス付けが有効になります。
ここでは、データベースのセルフリンクにIDベースのルーティングを使用しているため、コレクションを作成する前にリソースIDやクエリを知る必要はありません。 mydbというデータベースIDを使用できます。
- ステップ2 *-次に、姓がUpstonの2つのドキュメントを作成しましょう。
Mark Upstonのこの最初のものはコレクションに追加され、デフォルトのインデックス付けポリシーに基づいてすぐに自動的にインデックス付けされます。
しかし、Mark Upstonの2番目のドキュメントが追加されると、コレクションのインデックス付けポリシーにかかわらず、DocumentDBにこのドキュメントをインデックス付けしないように明示的に指示するIndexingDirective.Excludeを使用して要求オプションを渡しました。
最後に両方のドキュメントに対して異なるタイプのクエリがあります。
- ステップ3 *-CreateDocumentClientからAutomaticIndexingタスクを呼び出しましょう。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
ご覧のとおり、このようなドキュメントが2つありますが、Markのインデックスは作成されていないため、クエリはMarkのドキュメントのみを返します。 コレクション内のすべてのドキュメントを取得するWHERE句なしで再度クエリを実行すると、両方のドキュメントの結果セットが取得されます。これは、インデックス付けされていないドキュメントが常にWHERE句のないクエリによって返されるためです。
IDまたはセルフリンクによって、インデックス付けされていないドキュメントを取得することもできます。 したがって、MarkのIDであるMARKでドキュメントを照会すると、DocumentDBがコレクション内でインデックス付けされていなくてもドキュメントを返すことがわかります。
手動インデックス付け
自動インデックス作成を無効にして、手動インデックス作成の簡単な例を見てみましょう。
- ステップ1 *-最初に、手動インデックス作成と呼ばれるコレクションを作成し、自動インデックス作成を明示的に無効にしてデフォルトのポリシーをオーバーライドします。 つまり、別の方法でリクエストしない限り、このコレクションに追加された新しいドキュメントはインデックス付けされません。
- ステップ2 *-次に、以前と同じ2つのドキュメントを再度作成します。 コレクションのインデックス作成ポリシーにより、このドキュメントはインデックス化されないため、今回はMarkのドキュメントに特別なリクエストオプションを提供しません。
- ステップ3 *-Markに2番目のドキュメントを追加するとき、RequestOptionsをIndexingDirective.Includeとともに使用して、DocumentDBにこのドキュメントのインデックスを作成するように指示します。
最後に両方のドキュメントに対して異なるタイプのクエリがあります。
- ステップ4 *-CreateDocumentClientからManualIndexingタスクを呼び出しましょう。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
繰り返しますが、クエリは2つのドキュメントのうちの1つだけを返しますが、今回はJane Doeを返します。 ただし、以前と同様に、WHERE句なしでクエリを実行すると、Markのインデックス付けされていないドキュメントを含むコレクション内のすべてのドキュメントが取得されます。 また、IDによってインデックスが付けられていないドキュメントを照会することもできます。このIDは、インデックス付けされていなくてもDocumentDBから返されます。
DocumentDB-地理空間データ
Microsoftは*地理空間サポート*を追加しました。これにより、ドキュメントに位置データを保存し、ポイントとポリゴン間の距離と交差点の空間計算を実行できます。
空間データは、空間内のオブジェクトの位置と形状を表します。
通常は、人の位置、関心のある場所、都市の境界、または湖を表すために使用できます。
一般的なユースケースには、近接クエリが関係することがよくあります。 たとえば、「現在の場所の近くにあるすべての大学を検索する」。
大学の所在地を含む簡単な例を見てみましょう。
場所に基づいて大学名を取得するには、次のクエリを使用できます。
上記のクエリを実行すると、次の出力が表示されます。
.NETで地理空間データを使用してドキュメントを作成する
地理空間データを含むドキュメントを作成できます。大学のドキュメントが作成される簡単な例を見てみましょう。
UniversityProfileクラスの実装は次のとおりです。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
DocumentDB-パーティショニング
データベースが10GBを超えて大きくなり始めると、新しいコレクションを作成してから、さらに多くのコレクションにデータを分散またはパーティション分割するだけでスケールアウトできます。
遅かれ早かれ、10GBの容量を持つ単一のコレクションでは、データベースを含めるのに十分ではなくなります。 10GBはそれほど大きな数字には聞こえないかもしれませんが、JSONドキュメントを保存していることに注意してください。これは単なるテキストであり、インデックスのストレージオーバーヘッドを考慮しても、多くのプレーンテキストドキュメントを10GBに収めることができます。
スケーラビリティに関しては、ストレージだけが問題ではありません。 コレクションで使用可能な最大スループットは、S3コレクションで取得できる1秒あたり2.5リクエスト単位です。 したがって、より高いスループットが必要な場合は、複数のコレクションでパーティション化してスケールアウトする必要もあります。 スケールアウトパーティショニングは、*水平パーティショニング*とも呼ばれます。
Azure DocumentDBでデータをパーティション分割するために使用できる多くのアプローチがあります。 以下は最も一般的な戦略です-
- スピルオーバーパーティショニング
- 範囲分割
- ルックアップパーティショニング
- ハッシュ分割
スピルオーバーパーティショニング
スピルオーバーパーティショニングは、パーティションキーがないため、最も単純な戦略です。 多くのことについて確信が持てない場合は、多くの場合、最初から始めるのが良い選択です。 単一のコレクションを超えてスケールアウトする必要があるかどうか、追加する必要があるコレクションの数、または追加する必要のある速度を知ることはできません。
- スピルオーバーパーティショニングは単一のコレクションから始まり、パーティションキーはありません。
- コレクションは拡大し始め、その後、10GBの制限に近づくまで、さらに拡大し、さらに拡大します。
- 容量が90%に達すると、新しいコレクションにあふれて、新しいドキュメントに使用し始めます。
- データベースがより多くのコレクションにスケールアウトしたら、おそらくパーティションキーに基づく戦略に移行する必要があります。
- その場合、移行先の戦略に基づいてドキュメントを異なるコレクションに移動することにより、データのバランスを取り直す必要があります。
範囲分割
最も一般的な戦略の1つは、範囲分割です。 このアプローチでは、ドキュメントのパーティションキーが含まれる可能性のある値の範囲を決定し、その範囲に対応するコレクションにドキュメントを向けます。
- 定義された日付の範囲内のドキュメントを保持するコレクションを作成するこの戦略では、通常、日付が使用されます。 十分に小さい範囲を定義すると、コレクションが10GBの制限を超えることはないと確信できます。 たとえば、1つのコレクションで1か月間ドキュメントを合理的に処理できるシナリオがあります。
- また、ほとんどのユーザーが現在のデータ(今月またはおそらく先月のデータ)を照会している場合もありますが、はるかに古いデータを検索することはほとんどありません。 そのため、6月にS3コレクションを開始します。S3コレクションは、購入できる最も高価なコレクションであり、取得できる最高のスループットを提供します。
- 7月に別のS3コレクションを購入して7月のデータを保存し、6月のデータをより安価なS2コレクションに縮小します。 次に、8月に別のS3コレクションを取得し、7月をS2に、6月をS1に縮小します。 毎月、常に最新のデータを高いスループットで使用できるようにし、古いデータは低いスループットで使用できるようにします。
- クエリがパーティションキーを提供している限り、クエリが必要なコレクションのみがクエリされ、スピルオーバーパーティショニングで発生するようなデータベース内のすべてのコレクションはクエリされません。
ルックアップパーティショニング
ルックアップパーティション分割を使用すると、パーティションキーに基づいてドキュメントを特定のコレクションにルーティングするパーティションマップを定義できます。 たとえば、地域ごとにパーティションを分割できます。
- 1つのコレクションにすべての米国のドキュメント、別のコレクションにすべてのヨーロッパのドキュメント、および3番目のコレクションにある他の地域のすべてのドキュメントを保存します。
- このパーティションマップとルックアップパーティションリゾルバを使用すると、各ドキュメントに含まれるリージョンプロパティであるパーティションキーに基づいて、ドキュメントを作成するコレクションとクエリするコレクションを判別できます。
ハッシュ分割
ハッシュパーティション分割では、ハッシュ関数の値に基づいてパーティションが割り当てられるため、複数のパーティションにリクエストとデータを均等に分散できます。
これは一般に、多数の個別のクライアントから生成または消費されるデータを分割するために使用され、ユーザープロファイル、カタログアイテムなどの保存に役立ちます。
NET SDKが提供するRangePartitionResolverを使用した範囲分割の簡単な例を見てみましょう。.
- ステップ1 *-新しいDocumentClientを作成し、CreateCollectionsタスクで2つのコレクションを作成します。 1つはA〜Mで始まるユーザーIDを持つユーザー用のドキュメントを含み、もう1つはユーザーID N〜Zを持つドキュメントを含みます。
- ステップ2 *-データベースの範囲リゾルバーを登録します。
- ステップ3 *-新しいRangePartitionResolver <string>を作成します。これは、パーティションキーのデータ型です。 コンストラクターは、パーティションキーのプロパティ名と、シャードマップまたはパーティションマップであるディクショナリの2つのパラメーターを取ります。ディクショナリは、リゾルバー用に事前定義している範囲と対応するコレクションの単なるリストです。
ここでは、可能な限り最大のUTF-8値をエンコードする必要があります。 または、最初の範囲は、1つの単一のMを除くどのMでも一致せず、同様に2番目の範囲のZでも一致しません。 したがって、ここでエンコードされた値は、パーティションキーで一致するためのワイルドカードと考えることができます。
- ステップ4 *-リゾルバーを作成したら、現在のDocumentClientでデータベースに登録します。 それを行うには、PartitionResolverの辞書プロパティに割り当てます。
通常のコレクションではなく、データベースに対してドキュメントを作成およびクエリします。リゾルバーはこのマップを使用して、リクエストを適切なコレクションにルーティングします。
それでは、いくつかのドキュメントを作成しましょう。 最初に、userId Kirk用に1つ作成し、次にSpock用に1つ作成します。
ここでの最初のパラメーターは、特定のコレクションではなく、データベースへの自己リンクです。 これはパーティションリゾルバなしでは不可能ですが、1つを使用するとシームレスに機能します。
両方のドキュメントはデータベースmyfirstdbに保存されましたが、RangePartitionResolverが正常に機能している場合、KirkはAからMのコレクションに格納され、SpockはNからZのコレクションに格納されていることがわかります。
次のコードに示すように、これらをCreateDocumentClientタスクから呼び出しましょう。
上記のコードが実行されると、次の出力が表示されます。
ご覧のように、2つのドキュメントのセルフリンクは2つの別々のコレクションに存在するため、異なるリソースIDを持っています。
DocumentDB-データ移行
DocumentDBデータ移行ツールを使用すると、データをDocumentDBに簡単に移行できます。 DocumentDBデータ移行ツールは、Microsoftダウンロードセンターhttps://www.microsoft.com/enus/download/details.aspx?id=46436[[[2]] com/]
移行ツールは、多くのデータソースをサポートしています。それらの一部は以下にリストされています-
- リンク:/documentdb/documentdb_sql_server [SQL Server]
- リンク:/documentdb/documentdb_json_files [JSONファイル]
- リンク:/documentdb/documentdb_csv [カンマ区切り値(CSV)のフラットファイル]
- MongoDB
- Azureテーブルストレージ
- Amazon DynamoDB
- HBase、さらには他のDocumentDBデータベース
DocumentDB Data Migrationツールをダウンロードした後、zipファイルを抽出します。
次のスクリーンショットに示すように、このフォルダーには2つの実行可能ファイルがあります。
最初に、コマンドラインインターフェイスを備えたコンソールバージョンであるdt.exeがあり、次にグラフィカルユーザーインターフェイスを備えたデスクトップバージョンであるdtui.exeがあります。
GUIバージョンを起動しましょう。
Welcomeページが表示されます。 [ソース情報]ページの[次へ]をクリックします。
ここでデータソースを構成し、ドロップダウンメニューからサポートされている多くの選択肢を確認できます。
選択すると、ソース情報ページの残りの部分がそれに応じて変わります。
DocumentDBデータ移行ツールを使用して、DocumentDBにデータをインポートするのは非常に簡単です。 上記の例を実行し、他のデータファイルも使用することをお勧めします。
DocumentDB-アクセス制御
DocumentDBは、DocumentDBリソースへのアクセスを制御するための概念を提供します。 DocumentDBリソースへのアクセスは、マスターキートークンまたはリソーストークンによって管理されます。 リソーストークンに基づく接続は、トークンで指定されたリソースにのみアクセスでき、他のリソースにはアクセスできません。 リソーストークンは、ユーザーのアクセス許可に基づいています。
- 最初に1人以上のユーザーを作成します。これらのユーザーはデータベースレベルで定義されます。
- 次に、各ユーザーにアクセスを許可するリソースに基づいて、各ユーザーに1つ以上のアクセス許可を作成します。
- 各アクセス許可は、特定のリソースへの読み取り専用アクセスまたはフルアクセスのいずれかを許可し、データベース内の任意のユーザーリソースにできるリソーストークンを生成します。
- ユーザーはデータベースレベルで定義され、権限はユーザーごとに定義されます。 *ユーザーと権限は、データベース内のすべてのコレクションに適用されます。
DocumentDBで詳細なセキュリティを実現するためのユーザーとアクセス許可を定義する方法を学ぶ簡単な例を見てみましょう。
新しいDocumentClientから始めて、myfirstdbデータベースを照会します。
以下は、CreateUserの実装です。
- ステップ1 *-2人のユーザー、AliceとTomを作成するリソースと同様に作成し、目的のIdで定義オブジェクトを作成し、createメソッドを呼び出します。この場合、データベースのSelfLinkとuserDefinitionでCreateUserAsyncを呼び出します。 新しく作成されたユーザーオブジェクトを取得したリソースプロパティから結果を取得します。
次に、データベース内のこれら2人の新しいユーザーを表示します。
- ステップ2 *-データベースのUsersLinkに対してCreateUserQueryを呼び出して、すべてのユーザーのリストを取得します。 次に、それらをループし、プロパティを表示します。
まず、それらを作成する必要があります。 したがって、MyCollectionコレクションに対するAliceの読み取り/書き込み権限を許可したかったが、Tomはコレクション内のドキュメントのみを読み取ることができるとしましょう。
ステップ3-MyCollectionコレクションであるリソースにアクセス許可を作成して、そのリソースをSelfLinkにする必要があります。
- ステップ4 *-次に、このコレクションでAliceのPermission.Allを作成し、このコレクションでTomのPermission.Readを作成します。
以下は、CreatePermissionの実装です。
これで期待するように、IDとPermission.AllまたはPermission.ReadであるpermissionMode、および保護されているリソースのSelfLinkを含む新しいアクセス許可の定義オブジェクトを作成することでこれを行います許可によって。
- ステップ5 *-CreatePermissionAsyncを呼び出し、結果のリソースプロパティから作成されたアクセス許可を取得します。
作成された権限を表示するために、ViewPermissionsの実装を次に示します。
今回は、ユーザーのアクセス許可リンクに対するアクセス許可クエリであり、ユーザーに対して返された各アクセス許可を単純にリストします。
アリスとトムの許可を削除しましょう。
以下は、DeletePermissionの実装です。
- ステップ6 *-許可を削除するには、許可IDで照会してSelfLinkを取得し、SelfLinkを使用して許可を削除します。
次に、ユーザー自身を削除しましょう。 両方のユーザーを削除しましょう。
以下は、DeleteUserの実装です。
- ステップ7 *-最初にクエリを実行してSelfLinkを取得し、DeleteUserAsyncを呼び出してユーザーオブジェクトを削除します。
以下は、上記のすべてのタスクを呼び出すCreateDocumentClientタスクの実装です。
上記のコードをコンパイルして実行すると、次の出力が表示されます。
DocumentDB-データの視覚化
この章では、DocumentDBに保存されているデータを視覚化する方法を学びます。 マイクロソフトは、データをリッチなビジュアルに変換するPower BI Desktopツールを提供しました。 また、さまざまなデータソースからデータを取得し、データを結合および変換し、強力なレポートと視覚化を作成し、レポートをPower BIに発行できます。
Power BI Desktopの最新バージョンでは、MicrosoftはDocumentDBのサポートも追加し、DocumentDBアカウントに接続できるようになりました。 このツールは、https://powerbi.microsoft.com/en-us/desktop [https://powerbi.microsoft.com]リンクからダウンロードできます。
前の章でインポートした地震データを視覚化する例を見てみましょう。
- ステップ1 *-ツールをダウンロードしたら、Power BIデスクトップを起動します。
- ステップ2 *-[外部データ]グループの[ホーム]タブにある[データの取得]オプションをクリックすると、[データの取得]ページが表示されます。
- ステップ3 *-Microsoft Azure DocumentDB(ベータ)オプションを選択し、[接続]ボタンをクリックします。
- ステップ4 *-データを視覚化するAzure DocumentDBアカウント、データベース、およびコレクションのURLを入力し、[OK]を押します。
初めてこのエンドポイントに接続する場合は、アカウントキーの入力を求められます。
- ステップ5 *-Azureポータルで利用可能な各DocumentDBアカウントに固有のアカウントキー(プライマリキー)を入力し、[接続]をクリックします。
アカウントが正常に接続されると、指定されたデータベースからデータを取得します。 プレビューペインにはレコードアイテムのリストが表示され、ドキュメントはPower BIのレコードタイプとして表されます。
- ステップ6 *-[編集]ボタンをクリックして、クエリエディターを起動します。
- ステップ7 *-Power BIクエリエディターでは、中央のウィンドウにドキュメント列が表示され、ドキュメント列ヘッダーの右側にあるエキスパンダーをクリックして、表示する列を選択します。
ご覧のとおり、緯度と経度は別々の列になっていますが、緯度と経度の座標形式でデータを視覚化します。
- ステップ8 *-それを行うには、[列の追加]タブをクリックします。
- ステップ9 *-次のページを表示するカスタム列の追加を選択します。
- ステップ10 *-新しい列名、たとえばLatLongと、コンマで区切られた1つの列の緯度と経度を結合する式を指定します。 以下は式です。
- ステップ11 *-[OK]をクリックして続行すると、新しい列が追加されたことがわかります。
- ステップ12 *-[ホーム]タブに移動し、[閉じると適用]オプションをクリックします。
- ステップ13 *-フィールドをレポートキャンバスにドラッグアンドドロップしてレポートを作成できます。 右側に2つのペインがあります。1つは視覚化ペインで、もう1つはフィールドペインです。
各地震の場所を示すマップビューを作成しましょう。
- ステップ14 *-視覚化ペインからマップの視覚タイプをドラッグします。
- ステップ15 *-次に、LatLongフィールドを[フィールド]ペインから[視覚化]ペインの[場所]プロパティにドラッグアンドドロップします。 次に、マグニチュードフィールドをValuesプロパティにドラッグアンドドロップします。
- ステップ16 *-深度フィールドを[彩度]プロパティにドラッグアンドドロップします。
これで、マップのビジュアルに各地震の場所を示す一連のバブルが表示されます。