ApsaraDB for MongoDB:過剰なデータベースとコレクションによるパフォーマンスの問題

不要なコレクションの削除

データベース内で削除できるコレクション (期限切れや使用されなくなったものなど) を特定します。dropCollection コマンドを使用してそれらを削除します。詳細については、「dropCollection()」をご参照ください。

次のコマンドを使用して、データベースとコレクションの情報を表示します。

• 次のコマンドを実行して、データベース内のコレクション数を表示します。

  db.getSiblingDB(<dbName>).getCollectionNames().length

• 次のコマンドを実行して、コレクション、インデックス、ドキュメントの数、および合計データサイズを含むデータベースの詳細情報を表示します。

  // 特定のデータベースの統計情報を表示します。
  db.getSiblingDB(<dbName>).stats()

• 次のコマンドを実行して、特定のコレクションの詳細情報を表示します。

  // 特定のコレクションの統計情報を表示します。
  db.getSiblingDB(<dbName>).<collectionName>.stats()

不要なインデックスの削除

インデックスの数を減らすと、ディスクファイルの数と、WiredTiger ストレージエンジンが維持する対応する dhandle 構造の数も減少します。これにより、この問題が緩和されます。

インデックス最適化のための基本的な原則は次のとおりです。

• 未使用のインデックスを避ける

  クエリが特定のフィールドにアクセスしない場合、そのフィールド上のインデックスは使用されません。このようなインデックスは未使用と見なされ、削除できます。

• インデックスのプレフィックスルールに従う

  例えば、{a:1} と {a:1,b:1} の両方のインデックスがある場合、最初のインデックスは 2 番目のインデックスの冗長なプレフィックスであり、削除できます。

• 等価性クエリのインデックスフィールドの順序を考慮する

  等価性マッチングの場合、複合インデックス内のフィールドの順序は重要ではありません。例えば、フィールド a と b に対するクエリでは、インデックス {a:1,b:1} と {b:1,a:1} は機能的に同等です。使用頻度の低い方を削除できます。

• 範囲クエリには ESR ルールを使用する

  クエリに最適な複合インデックスを構築するには、フィールドを Equality, Sort, Range (等価性、ソート、範囲) の順序で配置します。詳細については、「ESR (Equality, Sort, Range) ルール」をご参照ください。

• ヒット数が低いインデックスをレビューする

  ヒット数が低いインデックスは、より効率的なインデックスと重複していることがよくあります。関連するすべてのクエリパターンを分析して、安全に削除できるかどうかを判断します。

MongoDB の $indexStats 集約ステージを使用して、コレクション内のすべてのインデックスの統計情報を表示できます。次のコマンドを実行する前に、必要な権限があることを確認してください。

// 特定のコレクションのインデックス統計情報を表示します。
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

このコマンドは、次の例のような出力を返します。

{
   "name" : "item_1_quantity_1",
   "key" : { "item" : 1, "quantity" : 1 },
   "host" : "examplehost.local:27018",
   "accesses" : {
      "ops" : NumberLong(1),
      "since" : ISODate("2020-02-10T21:11:23.059Z")
   }
}

次の表は、返された情報内のパラメーターについて説明しています。

インデックスのヒット数が非常に低い場合、例えば accesses.ops が 1 の場合、それは冗長または未使用のインデックスである可能性が高く、削除を検討できます。MongoDB インスタンスのバージョンが 4.4 以降の場合は、hideIndex コマンドを使用して、インデックスを削除する前に非表示にすることができます。これにより、一定期間アプリケーションに悪影響がないことを確認でき、インデックス削除のリスクを軽減できます。

// players コレクション
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

複数のコレクションからのデータを統合

複数のコレクションからのデータを単一のコレクションに統合して、コレクションの総数を減らします。

例えば、temperatures という名前のデータベースがセンサーからの温度データを格納しているとします。センサーは午前 10:00 から午後 10:00 まで動作し、30 分ごとに温度データを読み取って保存します。各日の温度データは、日付にちなんで名付けられた別のコレクションに保存されます。

次のスニペットは、2 つのコレクション temperatures.march-09-2020 と temperatures.march-10-2020 の一部のデータを示しています。

• コレクション temperatures.march-09-2020

  {
    "_id": 1,
    "timestamp": "2020-03-09T010:00:00Z",
    "temperature": 29
  }
  {
    "_id": 2,
    "timestamp": "2020-03-09T010:30:00Z",
    "temperature": 30
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-09T022:00:00Z",
    "temperature": 26
  }

• コレクション temperatures.march-10-2020

  {
    "_id": 1,
    "timestamp": "2020-03-10T010:00:00Z",
    "temperature": 30
  }
  {
    "_id": 2,
    "timestamp": "2020-03-10T010:30:00Z",
    "temperature": 32
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-10T022:00:00Z",
    "temperature": 28
  }
  

時間が経つにつれて、データベース内のコレクションの数は増加します。MongoDB はコレクション数に厳密な制限を課しておらず、このモデルには明確なデータライフサイクルポリシーがないため、コレクションとその対応するインデックスの数は無期限に増え続けます。

コレクション数が無限に増え続けるという問題に加えて、このデータモデルでは複数日にわたるクエリを実行することが困難です。長期的な温度傾向を分析するために数日間のデータをクエリするには、$lookup クエリを使用する必要がありますが、これは単一のコレクション内でクエリするよりもパフォーマンスが劣ります。

より良いデータモデルは、すべての温度測定値を単一のコレクションに格納し、各日のデータを単一のドキュメントに格納することです。このアプローチは、バケットパターンの例です。次の例は、最適化されたモデルを示しています。

// temperatures.readings
{
  "_id": ISODate("2020-03-09"),
  "readings": [
    {
      "timestamp": "2020-03-09T010:00:00Z",
      "temperature": 29
    },
    {
      "timestamp": "2020-03-09T010:30:00Z",
      "temperature": 30
    },
    ...
    {
      "timestamp": "2020-03-09T022:00:00Z",
      "temperature": 26
    }
  ]
}
{
  "_id": ISODate("2020-03-10"),
  "readings": [
    {
      "timestamp": "2020-03-10T010:00:00Z",
      "temperature": 30
    },
    {
      "timestamp": "2020-03-10T010:30:00Z",
      "temperature": 32
    },
    ...
    {
      "timestamp": "2020-03-10T022:00:00Z",
      "temperature": 28
    }
  ]
}

最適化されたモデルは、元のモデルよりもはるかに少ないリソースを消費します。時刻に基づいてインデックスを作成する必要がなくなり、コレクションのデフォルトの _id インデックスが日付によるクエリを容易にします。これにより、無制限のコレクション数の問題も解決されます。

インスタンスの分割

単一の MongoDB インスタンス内でデータベースとコレクションの総数を減らせない場合は、データベースインスタンスの論理的な分割と、それに対応するアプリケーションの変更を検討してください。

これには 2 つのシナリオでアプローチできます。

シャードタグを使用してシャードクラスターに移行

すべてのコレクションが単一のデータベースにあり、それらを単一の論理インスタンスとして管理したい場合は、データをシャードクラスターアーキテクチャに移行し、管理にシャードタグを使用することを検討してください。シャードタグ管理方法はやや複雑で、追加の操作手順 (sh.addShardTag と sh.addTagRange を使用) が必要です。しかし、単一の MongoDB インスタンスがすべてのコレクションを管理するため、アプリケーションへの変更は最小限で済みます。接続文字列を新しいシャードクラスターインスタンスのものに置き換えるだけで済みます。

例えば、インスタンスに 100,000 のアクティブなコレクションがある場合、新しい 10 シャードのシャードクラスターインスタンスを購入できます。以下のプロセスに従ってインスタンスを構成し、データを移行すると、シャードごとに 10,000 のアクティブなコレクションになります。手順は次のとおりです。

1. 新しいシャードクラスターインスタンスを購入します。この例では 2 シャードのインスタンスを使用します。シャードクラスターの作成方法については、「シャードクラスターインスタンスの作成」をご参照ください。

2. シャードクラスターインスタンスの mongos ノードに接続します。詳細については、「mongo シェルを使用して ApsaraDB for MongoDB シャードクラスターインスタンスに接続する」をご参照ください。

3. 次のコマンドを実行して、各シャードにシャードタグを追加します。

   sh.addShardTag("d-xxxxxxxxx1", "shard_tag1")
   sh.addShardTag("d-xxxxxxxxx2", "shard_tag2")

   説明

   • これらのコマンドを実行する前に、使用しているアカウントが必要な権限を持っていることを確認してください。

   • DMS (Data Management) は現在、sh.addShardTag コマンドをサポートしていません。mongo シェルまたは mongosh でインスタンスに接続してこれらのコマンドを実行することを推奨します。

4. すべてのシャードコレクションに対して、タグベースの範囲分散ルールを事前に構成します。

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.addTagRange("<dbName>.test", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag1")
   sh.addTagRange("<dbName>.test1", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag2")

   この例では、シャードキーとして _id を使用しています。ワークロードに適したシャードキーを選択し、すべてのクエリ操作にシャードキーフィールドが含まれるようにしてください。シャードキーは、次のステップで使用するフィールドと一致している必要があります。また、単一のコレクションのすべてのデータが単一のシャードに存在するように、[MinKey,MaxKey] の境界を使用する必要があります。

5. 移行するすべてのコレクションに対して shardCollection 操作を実行します。

   sh.shardCollection("<dbName>.test", {"_id":1})
   sh.shardCollection("<dbName>.test1", {"_id":1})

6. sh.status() コマンドを実行して、ルールが有効であることを確認します。

   zhongli.test
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag1  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
   zhongli.test1
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag2  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. レプリカセットインスタンスからシャードクラスターインスタンスへのデータ移行。

   説明

   宛先インスタンスでコレクションを事前にシャーディングしているため、すべてのデータベースとコレクション情報はすでに存在します。したがって、DTS タスクで競合するテーブルの処理モードをエラーを無視して続行に設定する必要があります。

8. データ整合性を確認した後、アプリケーションを新しいシャードクラスターインスタンスにアクセスするように切り替えます。

ゾーンを使用してシャードクラスターに移行

この方法はシャードタグの使用に似ていますが、代わりに MongoDB の ゾーン 機能を使用します。これには追加の操作手順、具体的には sh.addShardToZone() と sh.updateZoneKeyRange() が必要です。

手順は次のとおりです。

1. 新しいシャードクラスターインスタンスを購入します。この例では 2 シャードのインスタンスを使用します。シャードクラスターの作成方法については、「シャードクラスターインスタンスの作成」をご参照ください。

2. シャードクラスターインスタンスの mongos ノードに接続します。詳細については、「mongo シェルを使用して ApsaraDB for MongoDB シャードクラスターインスタンスに接続する」をご参照ください。

3. 次のコマンドを実行して、各シャードをゾーンに割り当てます。

   sh.addShardToZone("d-xxxxxxxxx1", "ZoneA")
   sh.addShardToZone("d-xxxxxxxxx2", "ZoneB")

   説明

   • これらのコマンドを実行する前に、使用しているアカウントが必要な権限を持っていることを確認してください。

   • DMS は現在、sh.addShardToZone コマンドをサポートしていません。mongo シェルまたは mongosh でインスタンスに接続してこれらのコマンドを実行することを推奨します。

4. すべてのコレクションに対して、ゾーンベースの範囲分散ルールを事前に構成します。

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.updateZoneKeyRange("<dbName>.test", { "_id": MinKey }, { "_id": MaxKey }, "ZoneA")
   sh.updateZoneKeyRange("<dbName>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   この例では、シャードキーとして _id を使用しています。ワークロードに適したシャードキーを選択し、すべてのクエリ操作にシャードキーフィールドが含まれるようにしてください。シャードキーは、次のステップで使用するフィールドと一致している必要があります。また、単一のコレクションのすべてのデータが単一のシャードに存在するように、[MinKey,MaxKey] の境界を使用する必要があります。

5. 移行するすべてのコレクションに対して shardCollection 操作を実行します。

   sh.shardCollection("<dbName>.test", { "_id": 1 })
   sh.shardCollection("<dbName>.test1", { "_id": 1 })

6. sh.status() コマンドを実行してシャーディングの分散状況を表示し、ゾーン構成が有効であることを確認します。出力例は次のとおりです。

   {  "_id" : "shardDistributionDB",  "primary" : "d-xxx24",  "partitioned" : false,  "version" : {  "uuid" : UUID("1dc635xxx"),  "lastMod" : 1 } }
           shardDistributionDB.test
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2ze9797089ef3704      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx04 Timestamp(1, 0)
                    tag: ZoneA  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
           shardDistributionDB.test1
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2zed2e752c35af24      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx24 Timestamp(1, 0)
                    tag: ZoneB  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. レプリカセットインスタンスからシャードクラスターインスタンスへのデータ移行。

   説明

   宛先インスタンスでコレクションを事前にシャーディングしているため、すべてのデータベースとコレクション情報はすでに存在します。したがって、DTS タスクで競合するテーブルの処理モードをエラーを無視して続行に設定する必要があります。

8. データ整合性を確認した後、アプリケーションを新しいシャードクラスターインスタンスにアクセスするように切り替えます。