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} のインデックスが存在するとします。 {a:1} インデックスは、他のインデックスのプレフィックスとして機能する冗長なインデックスです。 インデックスを削除できます。

• 等価クエリにおけるインデックスフィールドの順序

  たとえば、{a:1,b:1} と {b:1,a:1} のインデックスが存在するとします。 等価照合では、インデックスフィールドの順序は照合結果に影響しません。 ヒット数が最も少ないインデックスを削除できます。

• 範囲クエリにおける ESR ルールの参照

  実際のビジネスクエリ範囲に基づいて、quality、Sort、Range の順序で最適な複合インデックスを構築します。 詳細については、「ESR（Equality、Sort、Range）ルール」をご参照ください。

• ヒット数が少ないインデックスを確認する

  ほとんどの場合、ヒット数が少ないインデックスは、ヒット数が多い別のインデックスと重複しています。 すべてのクエリパターンに基づいて、インデックスを削除するかどうかを決定します。

ApsaraDB for MongoDB の $indexStats 集約ステージを使用して、コレクション内のすべてのインデックスの統計を表示できます。 集約ステージの詳細については、「$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 以降を実行している場合は、hiddenIndex コマンドを実行してインデックスを非表示にし、インスタンスが一定期間例外に遭遇しないことを確認してから、インデックスを削除します。 これにより、インデックスの削除によって引き起こされるリスクが軽減されます。 コマンドの詳細については、「db.collection.hideIndex()」をご参照ください。

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

複数のコレクションのデータを統合する

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

たとえば、temperatures という名前のデータベースが存在するとします。 データベースは、センサーから取得されたすべての温度データを格納するために使用されます。 センサーは 10:00 から 22:00 まで動作します。 動作中、センサーは 30 分ごとに温度データを読み取り、データベースに保存します。 毎日の温度データは、名前に日付が含まれるコレクションに格納されます。

次のデータは、temperatures.march-09-2020 と temperatures.march-10-2020 という名前の 2 つのコレクションに格納されています。

• 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
  }
  

データベース内のコレクションの数は時間の経過とともに増加しています。 ApsaraDB for MongoDB にはコレクションの数に明確な上限がなく、上記の例では明確なデータライフサイクル関係が指定されていません。 したがって、データベース内のコレクションの数と対応するインデックスの数は増加しています。

例で使用されているデータモデリングは、複数日にわたるクエリを容易にするものではありません。 複数日のデータをクエリして長期間の温度トレンドを取得する場合は、$lookup に基づいてクエリを実行します。 クエリのパフォーマンスは、同じコレクションに対するクエリよりも劣ります。

最適化されたデータモデリングでは、2 つのコレクションの温度データを単一のコレクションに統合し、毎日の温度データを単一のドキュメントに格納します。 次のサンプルコードは、最適化されたデータモデリングの例を示しています。

// 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
    }
  ]
}

最適化されたデータモデリングは、元のデータモデリングよりもはるかに少ないリソースを消費します。 毎日温度が読み取られる時刻に基づいてインデックスを作成する必要はありません。 temperatures.readings コレクションのデフォルトインデックス _id により、日付によるクエリが容易になります。 最適化されたデータモデリングは、コレクション数の増加という問題を解決します。

インスタンスの分割

ApsaraDB for MongoDB スタンドアロンインスタンスのコレクションの総数を減らすことができない場合は、インスタンスを分割し、インスタンスの構成を変更します。

次の表は、2 つのシナリオにおける分割ソリューションについて説明しています。

レプリカセットインスタンスのすべてのコレクションのデータをシャードクラスターインスタンスに移行し、シャードタグを使用してコレクションを管理する

すべてのコレクションがデータベースに分散されており、論理インスタンスによって管理する必要がある場合は、コレクションのデータをシャードクラスターインスタンスに移行し、コレクション管理にシャードタグを使用できます。 シャードタグを使用してコレクションを管理する場合は、sh.addShardTag コマンドと sh.addTagRange コマンドを実行する必要があります。 ただし、コレクションは引き続きシャードクラスターインスタンスによって管理され、ビジネス構成を変更する必要はありません。 元の接続文字列を網掛けクラスターインスタンスの接続文字列に置き換えるだけです。 コマンドの詳細については、「sh.addShardTag()」および「sh.addTagRange()」をご参照ください。

インスタンスに 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")

   説明

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

   • Data Management (DMS) は 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() コマンドを実行して、指定されたルールが有効になっていることを確認します。

7. すべてのコレクションのデータをシャードクラスターインスタンスに移行します。 詳細については、「ApsaraDB for MongoDB レプリカセットインスタンスから ApsaraDB for MongoDB レプリカセットまたはシャードクラスターインスタンスにデータを移行する」をご参照ください。

   説明

   シャードクラスターインスタンスでシャーディング操作を実行し、すべてのコレクション情報が存在します。 この場合、競合テーブルの処理モードパラメーターをエラーを無視して続行に設定します。

8. システムがデータの整合性をチェックした後、ビジネスをシャードクラスターインスタンスに切り替えます。

レプリカセットインスタンスのすべてのコレクションのデータをシャードクラスターインスタンスに移行し、ゾーンを使用してコレクションを管理する

ゾーンを使用して、移行されたコレクションを管理できます。 この方法は、シャードタグを使用する方法に似ています。 ゾーンを使用してコレクションを管理する場合は、sh.addShardToZone() コマンドと sh.updateZoneKeyRange() コマンドも実行する必要があります。 ゾーンの詳細については、「シャードゾーンの管理」をご参照ください。 コマンドの詳細については、「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("<dbNmae>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   この例では、_id がシャードキーとして使用されています。 シャードキーを実際のシャードキーに置き換えます。 すべてのクエリにシャードキーフィールドが含まれていることを確認してください。 シャードキーは、後続の操作のフィールド内のシャードキーと同じである必要があります。 [MinKey,MaxKey] で指定された境界値を使用して、単一のコレクション内のすべてのデータが単一のシャードにのみ格納されるようにします。

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

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

6. sh.status() コマンドを実行します。 コマンド出力は、指定されたルールが有効になっていることを示します。

7. すべてのコレクションのデータをシャードクラスターインスタンスに移行します。 詳細については、「ApsaraDB for MongoDB レプリカセットインスタンスから ApsaraDB for MongoDB レプリカセットまたはシャードクラスターインスタンスにデータを移行する」をご参照ください。

   説明

   シャードクラスターインスタンスでシャーディング操作を実行し、すべてのコレクション情報が存在します。 この場合、競合テーブルの処理モードパラメーターをエラーを無視して続行に設定します。

8. システムがデータの整合性をチェックした後、ビジネスをシャードクラスターインスタンスに切り替えます。