Azure Cosmos DB for MongoDB 仮想コアでの水平方向のスケーラビリティのシャーディング

Azure Cosmos DB for MongoDB では、データおよびトラフィックを水平方向に分散するためのシャーディングがサポートされています。 コレクション内のドキュメントは、論理シャードと呼ばれるチャンクに分割されます。

シャーディングは、コレクションのドキュメント構造の指定されたシャード キーを使用してコレクションごとに個別に定義されます。 データはチャンクにバケット化され、各チャンクは論理パーティションに対応します。 シャード キー プロパティの各一意の値のドキュメントは、同じ論理シャード内に存在します。

シャード化されたコレクションに挿入されたドキュメントごとに、シャード キー プロパティの値がハッシュされ、指定された論理シャードが計算されます。 論理シャードを配置し、クラスター内のすべての論理シャードを分散するというユーザーの負担は取り除かれ、サービスによって完全に管理されます。

論理シャード

同じ値のシャード キーを含むドキュメントはすべて、同じ論理シャードに属します。

たとえば、次のドキュメント構造を持つ Employees という名前のコレクションについて考えてみましょう。

次の表は、シャード キーの値と論理パーティションのマッピングを示しています。

• コレクションの論理シャードの数に制限はありません。 コレクションには、各ドキュメント内のシャード キー プロパティの値が一意であるドキュメントと同じ数の論理シャードを含めることができます。

• また、1 つの論理シャードのサイズにも制限はありません。

• さらに、このサービスでは、トランザクションを論理シャードのスコープに制限しません。 Azure Cosmos DB for MongoDB の仮想コア ベースのサービスでは、クラスター内の複数の論理シャードおよび複数の物理シャードに適用可能な読み取りおよび書き込みトランザクションをサポートします。

物理シャード

物理シャードは、データの永続化 と データベース トランザクションの実行を担当する基になるマシンとディスクです。 論理シャードとは異なり、サービスは物理シャードを内部で管理します。

物理シャードの数は、クラスターの作成時に定義され、時間の経過と同時にデータベース サイズが大きくなると増やすことができます。 単一シャード クラスターには、クラスターのストレージとデータベースのトランザクションを完全に担当する 1 つの物理シャード (ノード) があります。 マルチハード クラスターは、クラスター内の物理シャード間でデータとトランザクション ボリュームを分散します。

論理シャードと物理シャードのマッピング

新しい論理シャードが追加されると、クラスターでは、論理シャードと物理シャードのマッピングがシームレスに更新されます。 同様に、新しい物理シャードがクラスターに追加されると、各物理シャードへのアドレス空間の割り当てが変更され、その後、論理シャードがクラスター全体で再調整されます。

論理シャードと物理シャードのマッピングに使用されるハッシュ範囲は、クラスター内の物理シャード間で均等に分散されます。 各物理シャードは、ハッシュ範囲の均等にサイズ設定されたバケットを所有します。 書き込まれるすべてのドキュメントについて、シャード キー プロパティの値がハッシュされ、ハッシュ値によって、ドキュメントと基になる物理シャードのマッピングが決定されます。 内部的には、複数の論理シャードが 1 つの物理シャードにマッピングされます。 さらに、論理シャードが物理シャード間で分割されることはなく、論理シャードのドキュメントは 1 つの物理シャードにのみマッピングされます。

次の表は、2 つの物理シャードがあるクラスターを使用した前述の例を基に、ドキュメントと物理シャードのマッピングのサンプルを示しています。

物理シャードの容量

クラスターのプロビジョニング時に選択されるクラスター レベルによって、物理シャードの CPU とメモリの容量が決まります。 同様に、ストレージ SKU によって、物理シャードのストレージと IOPS の容量が決まります。 クラスター レベルが大きいほど、コンピューティング能力が高くなり、メモリ容量が多くなります。また、ストレージ ディスクが大きいほど、ストレージ容量と IOPS が多くなります。 読み取り負荷の高いワークロードにはより大きなクラスター レベルが役立ち、書き込み負荷の高いワークロードにはより大きなストレージ SKU が役立ちます。 クラスター レベルは、クラスターの作成後、アプリケーションのニーズの変化に基づいてスケールアップおよびスケールダウンできます。

マルチハード クラスターでは、各物理シャードの容量は同じです。 クラスター レベルまたはストレージ SKU をスケールアップしても、物理シャード上の論理シャードの配置は変更されません。 スケールアップ操作後も物理シャードの数は変わらないため、クラスター内のデータを再調整する必要はありません。

物理シャードのコンピューティング、メモリ、ストレージ、IOPS の容量によって、論理シャードに使用できるリソースが決まります。 ストレージおよび要求のボリュームが均等に分散されていないシャード キーによって、クラスター内でのストレージとスループットの消費量が不均一になる可能性があります。 ホット パーティションによって、物理シャードの利用が不均一になり、予測できないスループットやパフォーマンスを引き起こす可能性があります。 このため、シャード化されたクラスターについては、アプリケーションの要件が時間の経過と共に変化しても一貫したパフォーマンスを維持できるように、事前に慎重に計画する必要があります。

レプリカ セット

各物理シャードは一連のレプリカで構成されます。これはレプリカ セットとも呼ばれます。 各レプリカによって、データベース エンジンのインスタンスがホストされます。 レプリカ セットにより、物理シャード内のデータ ストアの耐久性、高可用性、一貫性が確保されます。 物理シャードを構成する各レプリカは、物理シャードのストレージとコンピューティングの容量を継承します。 レプリカ セットは、Azure Cosmos DB for MongoDB 仮想コアによって自動的に管理されます。

データのシャーディングに関するベスト プラクティス

• コレクションのストレージおよびトランザクションのボリュームが 1 つの物理シャードの容量を超えない限り、Azure Cosmos DB for MongoDB 仮想コアでのシャーディングは必要ありません。 たとえば、このサービスではシャードあたり 32 TB のディスクが提供されます。 コレクションに 32 TB を超えるサイズが必要な場合は、シャード化する必要があります。

• クラスター内のすべてのコレクションを複数の物理シャードにシャード化する必要はありません。 シャード化されたコレクションとシャード化されていないコレクションは、同じクラスター内に共存できます。 このサービスは、クラスター内のコレクションを最適に分散して、クラスターのコンピューティングおよびストレージ リソースを可能な限り均等に利用します。

• 読み取り負荷の高いアプリケーションの場合、最も頻繁に実行されるクエリ パターンに基づいてシャード キーを選択する必要があります。 検索を 1 つの物理シャードにローカライズして、データベース トランザクションの最も高い割合を最適化するには、コレクションで最もよく使用されるクエリ フィルターをシャード キーとして選択する必要があります。

• 読み取りよりも書き込みパフォーマンスを優先する書き込み負荷の高いアプリケーションの場合、物理シャード間でデータを均等に分散するようにシャード キーを選択する必要があります。 カーディナリティが最も高いシャード キーは、可能な限り均等に分散するのに最も適しています。

• 最適なパフォーマンスを得るには、論理シャードのストレージ サイズを 4 TB 未満にする必要があります。

• 最適なパフォーマンスを得るには、クラスターの物理シャード間で、ストレージおよび要求のボリュームの論理シャードを均等に分散する必要があります。

コレクションをシャード化する方法

'cosmicworks' データベースと 'employee' コレクション内の次のドキュメントについて検討します

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

次のサンプルは、cosmicworks データベース内の従業員コレクションを firstName プロパティでシャード化します。

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

コレクションは、admin コマンドを使用してシャード化することもできます。

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

コレクションがストレージ ボリュームで大幅に増加した後にシャード キーを変更することは理想的ではありませんが、reshardCollection コマンドを使用してシャード キーを変更できます。

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

コレクションは、admin コマンドを使用して再シャード化することもできます。

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

ベスト プラクティスとして、シャード キー プロパティでインデックスを作成する必要があります。

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

次のステップ

• Azure Cosmos DB for MongoDB 仮想コア クラスターのスケーリング方法を理解する
• インデックス作成のベスト プラクティスを確認する