ApsaraDB for MongoDB:ApsaraDB for MongoDBシャードクラスターインスタンスの概要

シナリオ

シャードノード数とmongosノード数

シャーキーの選択

• ApsaraDB for MongoDBは、次のシャーディング戦略をサポートしています。
  • これは、シャードキー値によって決定される連続した範囲にデータを分割するために使用されます。
  • 構成されたシャードノード間でデータを分散するために使用されるハッシュシャーディング
  • タグ認識シャーディング。配布されるチャンクに基づいてルールをカスタマイズするために使用されます。
    説明

    • シャーディング戦略の仕組み
      1. ApsaraDB for MongoDBは、sh.addShardTag() メソッドを呼び出して、タグAをシャードノードに追加します。
      2. ApsaraDB for MongoDBは、sh.addTagRange() メソッドを呼び出して、コレクションの特定のチャンク範囲にタグAを追加します。 このようにして、ApsaraDB for MongoDBは、タグAでラベル付けされたチャンク範囲内のデータをタグAでラベル付けされたシャードノードに配信できます。ApsaraDB for MongoDBは、タグAでラベル付けされたチャンク範囲のスーパーセット内のデータをタグAでラベル付けされたシャードノードに配信することもできます。
    • シナリオ
      • シャードノードがデプロイされているデータセンターに基づいて、タグをシャードノードに追加します。 これにより、ApsaraDB for MongoDBは、チャンク範囲内のデータを、チャンク範囲と同じタグを持つデータセンターに配信できます。
      • シャードノードのQPS値に基づいて、タグをシャードノードに追加します。 これにより、ApsaraDB for MongoDBは、高いQPSを提供するシャードノードにより多くのチャンクを配布できます。
    • 使用上の注意

      ApsaraDB for MongoDBは、指定されたタグでラベル付けされたシャードノードにチャンクを直接配布することはできません。 チャンクの分割と移行は挿入と更新操作によって頻繁にトリガーされるため、チャンクは徐々に分散されます。 配布プロセス中にbalancerが有効になっていることを確認します。 タグがチャンク範囲に追加された後、書き込まれたデータは、チャンク範囲と同じタグを持つシャードノードに配信されない可能性があります。

    詳細については、「タグ対応シャーディング」をご参照ください。

• レンジシャーディングとハッシュシャーディングは、次の問題を解決できません。
  • シャードキーの値の範囲が小さい。 たとえば、データセンターがシャードキーとして選択された場合、データセンターの数が限られているため、シャーディングは非効率的です。
  • シャードキーの特定の値は、多数のドキュメントに含まれています。 この場合、1つのチャンクに多数の文書が格納されることがある。 チャンク内のドキュメントのサイズがチャンクあたりのサイズを超える場合、チャンクはジャンボチャンクとしてラベル付けされ、balancerによって移行することはできません。
  • シャードキーではなく条件に基づいてデータをクエリおよび更新すると、すべての操作が分散収集クエリになり、時間がかかります。
• シャーディングは、シャードキーに次の特性がある場合に効率的です。
  • 十分なカーディナリティ
  • 均等に分散された書き込み操作
  • ターゲット読み取り操作Targeted read operations

例：

IoTアプリケーションは、シャードクラスタインスタンスを使用して、数百万のデバイスのログを保存します。 各デバイスは、10秒ごとに1回、シャードクラスターインスタンスにログを送信します。 ログには、デバイスIDやタイムスタンプなどの情報が含まれます。 特定の時間範囲にわたって特定のデバイスに対して生成されたログは、頻繁に照会されます。

以下のシャーディング方法が提供されます。

• 方法1: 推奨。 デバイスIDとタイムスタンプの組み合わせをシャードキーとして使用し、範囲分割を実行します。
  • 書き込まれたデータは、複数のシャードノードに均等に分散されます。
  • 同じデバイスIDを搬送するデータは、データのタイムスタンプに基づいて複数のチャンクにさらに分割および分散され得る。
  • 特定の時間範囲にわたって特定のデバイスに対して生成されたログをクエリする場合、ApsaraDB for MongoDBはデバイスIDとタイムスタンプを組み合わせて複合インデックスを作成し、それに基づいてクエリを完了できます。
• 方法2: タイムスタンプをシャードキーとして使用し、レンジシャーディングを実行します。
  • 連続したタイムスタンプを持つ書き込みデータは、同じシャードノードに配布されます。 これは、書き込まれたデータの不均一な分布を引き起こす。
  • デバイスIDベースのクエリは、すべてのシャードノードに分散されます。 これは、クエリ効率を低下させる。
• 方法3: タイムスタンプをシャードキーとして使用し、ハッシュシャーディングを実行します。
  • 書き込まれたデータは、複数のシャードノードに均等に分散されます。
  • デバイスIDベースのクエリは、すべてのシャードノードに分散されます。 これは、クエリ効率を低下させる。
• 方法4: デバイスIDをシャードキーとして使用し、ハッシュシャーディングを実行します。
  説明 デバイスIDにルールが適用されていない場合は、レンジドシャーディングを実行できます。
  • 書き込まれたデータは、複数のシャードノードに均等に分散されます。
  • 同じデバイスIDを持つデータは、同じチャンクにのみ配布できます。 これにより、ジャンボチャンクが発生します。 各デバイスIDベースのクエリは、単一のシャードノードにのみ配布でき、シャードノードは、クエリで指定されたタイムスタンプ範囲に基づいてすべてのテーブルをスキャンしてソートする必要があります。

ジャンボチャンクとチャンクあたりのサイズ

シャードクラスタインスタンスのチャンクあたりのデフォルトサイズは64 MBです。 チャンクのサイズが64 MBを超え、チャンクを分割できない場合、チャンクはジャンボチャンクとしてラベル付けされます。 たとえば、すべてのドキュメントが同じシャードキー値を持つ場合、これらのドキュメントは同じチャンクに格納され、分割できません。 バランサーは、負荷の不均衡を引き起こす可能性があるジャンボチャンクを移行できません。 ジャンボチャンクを防ぐことを推奨します。

バランサー

シャードクラスタインスタンスの自動負荷分散は、インスタンスのmongosノードで実行されるバックグラウンドスレッドによって実装されます。 特定の時点で、各コレクションに対して実行できる移行タスクは1つだけです。 負荷分散は、各シャードノードのコレクションごとのチャンク数に基づいてトリガーされます。 シャードノード上のコレクションのチャンク数とコレクションのチャンク総数の差が指定されたしきい値に達すると、ApsaraDB for MongoDBはコレクションのチャンクをシャードノードから他のシャードノードに移行し始めます。 チャンクの総数に基づいてしきい値を指定する必要があります。

use config
                db.settings.update(
                { _id: "balancer" },
                { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
                { upsert: true }
                )
            

sh.stopBalancer()

moveChunkコマンドでのアーカイブ設定

シャードクラスタインスタンスがMongoDB 3.0以前を実行している場合、データ書き込みが停止した後でも、データカタログのディスク領域使用量が増加し続けることがあります。

上記の問題は、moveChunkコマンドのsharding.archiveMovedChunksパラメーターの値が原因です。 MongoDB 3.0以前では、このパラメーターのデフォルト値はtrueです。 値trueは、チャンクがシャードAからシャードBに移行された後にシャードAにアーカイブされることを示します。シャードBのチャンクが破損した場合、シャードAからチャンクを復元できます。チャンクはシャードAとシャードBの両方のストレージスペースを占有します。