データベースのパーティショニング

「データの保存方法」ページで説明されているように、パーティション分割されたデータベースでは、アプリケーションはドキュメントパーティションキーを使用して同じシャード上にドキュメントを共存させることができます。このページはデータモデルがパーティショニングされたデータベースでの使用に適しているかどうかを調べるのに役立ちます。

IBM® Cloudant® for IBM Cloud® では、次の 2 つのタイプのデータベースがサポートされます。

Non-partitioned: デフォルトのタイプ。ドキュメントは、ワークロードのバランスをとるために、データベースによって自動的にシャードに割り当てられる。
パーティションド ：ドキュメントIDは、データがシャードにどのように割り当てられるかに影響する、アプリケーション指定のパーティション・キーを含む。

IBM Cloudant データモデル上、ドキュメントを多数の（500以上）パーティションに論理的に分割できる場合にのみ、パーティション化されたデータベースを使用することを推奨します。アプリケーションがパーティションド・データベースを使用できるかどうかを理解するには、パーティションド・データベースの適合性を判断するを参照してください。

アプリケーションの観点から見ると、パーティション分割されていないデータベースとパーティション分割されたデータベースの重要な違いは、どのようにデータを照会できるかという点です：

パーティション分割されていないデータベースでは、グローバルなセカンダリ・インデックスの作成とクエリのみが可能です。
パーティショニングされたデータベースでは、グローバル・インデックスとパーティショニングされたセカンダリ・インデックスの両方を作成し、照会することができます。

この文書には、各インデックス・タイプの使用例についての詳細が記載されている。

パーティショニングされたデータベースの制限

パーティショニングされたデータベースには、インデックスの数と、同じパーティション・キーを持つすべてのドキュメントの合計サイズに制限があります。には制限がある。

パーティションにスコープされたクエリは、グローバルクエリよりもサービス強制タイムアウトが短く、1回のクエリで取得できるドキュメント総数の制限も小さくなります。クエリよりもサービス強制タイムアウトが短く、1回のリクエストで取得できるドキュメント総数の制限も小さくなります。 HTTP 制限を小さくすることができます。

これらの制限の詳細については、 IBM Cloudant Limitsを参照のこと。

パーティショニングされたデータベースを使う理由

パーティショニングされたデータベースは、関連ドキュメントをグループ化することでアプリケーションにメリットがあり、予測可能でスケーラブルなクエリ・パフォーマンスが必要な場合に最適です。

パーティション化されたデータベースでは、パーティション範囲内のクエリとグローバルなクエリの両方が利用可能です。パーティション・スコープのクエリは、与えられたパーティション・キーとドキュメントの位置関係を利用する。より効率的でスケーラブルなクエリ・パフォーマンスを可能にする。パーティション・キーで表現できるワークロードの場合、これはクエリの待ち時間を大幅に短縮し、コストを削減します。クエリの待ち時間を大幅に短縮し、コストを削減することができます。

パーティショニングは、アプリケーションに予測可能なパフォーマンスが必要な場合に特に有効です。アプリケーションで特に価値があります。インデックスを効果的に利用するパーティション・スコープのクエリは、データセットが大きくなっても高速なままである。インデックスを効果的に利用するクエリは、データセットが大きくなっても高速性を維持し、最大64シャードにわたって効率的にスケールできる。 64シャードまで効率的に拡張できる。このため、パーティショニングされたデータベースは、次のような作業負荷に適している。高スループット、低レイテンシのワークロードに適している。

一般的に、データセットが多くのデータベースシャードを必要とする場合、アプリケーションはレイテンシを重視した操作にパーティションスコープクエリを使用します。アプリケーションは、レイテンシを重視する処理にはパーティションにスコープされたクエリを使用し、バッチ処理などのタイムクリティカルでない処理にはグローバルクエリを使用します。は、バッチ処理など、あまりタイムクリティカルでないタスクのために予約されます。

パーティショニングされたデータベースが適さない理由

パーティショニングされたデータベースは、慎重なデータモデリングが必要であり、インデックスを重複させる必要があるかもしれない。インデックスの複製が必要になる場合があります。多くのユースケースでは、この余分な努力は報われない。

パーティショニングされたデータベースは、適切に使用されればパフォーマンス上のメリットがある、すべてのワークロードに合致するわけではない制約をもたらす。次のことが必要です。関連するドキュメントをグループ化し、効率的なクエリをサポートするためにを定義する必要があります。各文書が一意のキーを持つ場合、あるいはパーティション・キーが少なすぎる場合、パーティション化されたデータベースは、パーティション化されていないデータベースよりもパフォーマンスが落ちる可能性が高い。が悪くなる可能性が高い。

パーティションがスコープされたクエリでは、パーティショニングされたインデックスを作成する必要があります。そのためアプリケーションのアクセス・パターンによっては、グローバル・インデックスとパーティションド・インデックスの両方を維持する必要があります。を維持する必要があるかもしれません。

パーティショニングされたデータベースの適合性を判断する

これでパーティションド・データベースの利点と欠点が理解できただろう、次のステップは、あなたのデータモデルがパーティショニングされたデータベースでうまく機能するかどうかを理解することです。を理解することです。

データモデルとアプリケーションのニーズを以下の基準に照らして評価します。パーティショニング・データベースの適合性を判断します：

パーティション・キーのカーディナリティを高くすることが不可欠である。異なるパーティション・キーの数は、シャードの数より_はるかに多くなければ_ならない。
クエリーの負荷は均等に分散されなければならない。ほとんどのクエリーが1つのパーティション・キーをターゲットにすると、ホットスポットができてパフォーマンスが低下する可能性がある。
パーティション・キーは、関連する文書をグループ化する必要がある。各キーが1つの文書にしかマッピングされない場合、パーティショニングのメリットはほとんどない。

良いパーティションと悪いパーティションの主な例

その根拠として、いくつかの使用例と、パーティション・キーの良い選択と悪い選択を見てみよう。パーティション・キーの良い選択と悪い選択を見てみよう。

パーティションキーの良い選択と悪い選択
ユース・ケース	パーティション・キー	良し悪し	理由
e-コマース・システム - オーダー	`customer_id`	Good	カーディナリティが高く、クエリが多くの顧客に分散している。
e-コマース・システム - オーダー	`order_id`	誤った～	1つのパーティションに1つの文書。グループ化や再利用は不可。
e-コマース・システム - オーダー	`status`	誤った～	ステータス値（仮払い、支払い済み、払い戻し、キャンセル）のカーディナリティが低いため、パーティションが少なすぎる。
e-コマース・システム - オーダー	`country_code`	誤った～	カーディナリティが低く、少数の国がトラフィックを独占している。
IOT - センサー信号。	`device_id`	Good	多くの機器がデータを生成し、負荷を均等に分散する。
IOT - センサー信号。	`reading_id`	誤った～	文書ごとに一意。パーティションには1つの項目しか含まれない。
IOT - センサー信号。	`date`	誤った～	ほとんどのクエリは最近の日付をターゲットにしており、ホットスポットを引き起こしている。
IOT - センサー信号。	`region`	誤った～	少数の地域がトラフィックを独占し、不均衡を招く可能性がある。

パーティションキーとして適切な選択肢が存在しないユースケースもいくつかあります。こうした状況では、パーティション化されていないデータベースが最適な選択肢となります。例えば、E メール・アドレス、パスワード・ハッシュ、および最終ログイン日付が保管されている、ユーザーのデータベースがこれにあたります。これらのフィールドはいずれも適切なパーティションキーにはなり得ないため、代わりにパーティション化されていないデータベースを使用する必要があります。

パーティショニングされたデータベースとインデックスの作成

データベースの作成時にパーティションを作成するかどうかを決定する必要があります。データベースを作成するときに、partitioned 照会ストリング・パラメーターを使用して、データベースをパーティション化するかどうかを設定します。 partitioned のデフォルトは false。

同様に、インデックスも_グローバルか_ _パーティショニングの_どちらかです。デザイン・ドキュメントの partitioned フィールドを使用してインデックスを作成するときに設定します。すべてのの partitioned フィールドを継承します。フィールドを継承します。パーティション分割されたインデックスをクエリする場合は、リクエストにクエリするパーティションキーを含む_パーティションスコープのクエリ_を使用します。

インデックスやデータベースのパーティショニング・タイプは、作成後に変更することはできません。

パーティションにスコープされたクエリは、パーティション化されたインデックスに対してのみ実行できます。同様にグローバルクエリはグローバルインデックスに対してのみ実行できます。

照会

IBM Cloudant はグローバルとパーティション・スコープの両方をサポートしている。両方のタイプを効果的に使うには、クエリスコープごとに別々のインデックスを作成する必要があります。を作成する必要があります。

グローバルクエリは、シャード数が少ない（16以下）データベースではうまく機能する、しかし、シャード数が増えるにつれて、待ち時間を重視する操作には適さなくなります。シャードの数が増えるにつれて、待ち時間を重視する操作には適さなくなる。対照的に、パーティション・スコープのクエリは、シャード数が大きいほど効率的にスケールする。大規模なデータセットに対して予測可能な低レイテンシ・パフォーマンスを必要とするアプリケーションでは、シャード数が多いほど効率的に拡張されます。大規模なデータセットに対して予測可能で低レイテンシのパフォーマンスを必要とするアプリケーションに適したオプションです。

パーティション・スコープのクエリの恩恵を受けるには、アプリケーション・クエリの大半は、特定のパーティション・キーをターゲットにしなければならない。は特定のパーティション・キーをターゲットにしなければなりません。これにより、データベースは以下の利点を活用できる。ドキュメントのコロケーションを活用し、一貫したパフォーマンスをスケーラブルに提供します。

グローバル・クエリとパーティション・スコープのクエリがデータベース操作のパフォーマンスに与える影響の詳細については、「シャーディングがデータベースのパフォーマンスに与える影響」を参照してください。

グローバル照会

を使ってグローバルクエリーを行うことができる：

グローバル・インデックスの作成はデフォルトですが、デザイン・ドキュメントで "options.partitioned": false を使用して明示的にグローバル・インデックスを作成することもできます：

{
  "options": {
    "partitioned": false
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

パーティション・スコープのクエリ

を使ってパーティション・スコープのクエリーを作ることができる：

パーティション・スコープ・クエリーをサポートするパーティションド・インデックスを作成するには、デザイン・ドキュメントで "options.partitioned": true ：

{
  "options": {
    "partitioned": true
  },
  "views": {
    "by-device": {
      "map": "function(doc) { emit(doc.deviceID, doc.infrastructureID) }"
    }
  }
}

パーティション・データベースのチュートリアル

パーティショニングされたデータベースは、抽象的に理解するのが難しい。この2つの例で、そのコンセプトを実際に見ることができる：

パーティションデータベースを使用した IoT ヒストリアンの作成を読んで、いくつかのプログラミング言語の例とともにパーティションデータベースについて詳しく学んでください。
このブログ記事では、パーティション化されたデータベースと Node.js について解説しています。パーティション化されたデータベースの作成方法、検索、ビュー、グローバルインデックスについても紹介しています。