ApsaraDB for MongoDB:過剰なデータベースとテーブルによるインスタンスのコマ落ちまたは異常動作

スロークエリの診断

多数のコレクションによるロック競合がスロークエリを引き起こす場合、スロークエリログには次のようなエントリが含まれます。

2024-03-07T15:59:16.856+0800 I  COMMAND  [conn4175155] command db.collections command: count { count: "xxxxxx", query: { A: 1, B: 1 },
$readPreference: { mode: "secondaryPreferred" }, $db: "db" } planSummary: COLLSCAN keysExamined:0 keysExaminedBySizeInBytes:0
docsExamined:1 docsExaminedBySizeInBytes:208 numYields:1 queryHash:916BD9E3 planCacheKey:916BD9E3 reslen:185
locks:{ ReplicationStateTransition: { acquireCount: { w: 2 } }, Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 2 } },
Collection: { acquireCount: { r: 2 } }, Mutex: { acquireCount: { r: 1 } } } storage:{ data: { bytesRead: 304, timeReadingMicros: 4 },
timeWaitingMicros: { handleLock: 40, schemaLock: 134101710 } } protocol:op_query 134268ms

この例では、単一ドキュメントコレクションに対する count 操作に 134,268 ms かかりました。キーフィールドは timeWaitingMicros: { handleLock: 40, schemaLock: 134101710 } であり、読み取りリクエストが実際の作業を実行するのではなく、基盤となるストレージレイヤーでハンドルロックとスキーマロックを取得するのを待機するのにほとんどの時間を費やしたことを示しています。

次の表は、スロークエリログエントリの主要フィールドについて説明しています。

アクションを実行する前に、次のコマンドを使用してコレクションとインデックスの数を診断します。

// Count collections in a database
db.getSiblingDB(<dbName>).getCollectionNames().length

// View database statistics (collection count, index count, document count, total size)
db.getSiblingDB(<dbName>).stats()

// View statistics for a specific collection
db.getSiblingDB(<dbName>).<collectionName>.stats()

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

期限切れまたは不要になったコレクションを特定し、dropCollection を使用して削除します。詳細については、「dropCollection()」をご参照ください。

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

各インデックスは WiredTiger で個別のディスクファイルを作成し、対応する dhandle を追加します。インデックス数を減らすことで、dhandle の負荷を直接軽減できます。

$indexStats 集約ステージを使用して、使用頻度の低いインデックスを特定します。変更を加える前に、次のコマンドを実行します (適切な権限が必要です)。

// View access statistics for all indexes in a collection
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")
   }
}

次の表は、出力の主要フィールドについて説明しています。

削除するインデックスを決定する際に、次のルールを適用します。

• 無効なインデックス：どのクエリもアクセスしないフィールドのインデックスを削除します。

• インデックスプレフィックスの冗長性：{a:1} と {a:1,b:1} の両方が存在する場合、{a:1} は冗長です。{a:1,b:1} は、それを使用するすべてのクエリをカバーします。

• 等価クエリの順序：{a:1,b:1} と {b:1,a:1} の両方が存在する場合、ヒット数の少ない方を削除します。等価マッチングの場合、フィールドの順序は結果に影響しません。

• 範囲クエリの ESR ルール：Equality, Sort, Range 順序で結合インデックスを構築します。詳細については、「The ESR (Equality, Sort, Range) Rule」をご参照ください。

• ヒット数の少ないインデックス：これらは、よりヒット数の多いインデックスによって重複していることがよくあります。削除する前に、すべてのクエリパターンに対して評価してください。

インスタンスが MongoDB 4.4 以降を実行している場合は、db.collection.hideIndex() を使用して、インデックスを削除する前に非表示にします。インスタンスを一定期間監視して、どのクエリもインデックスに依存していないことを確認してから、完全に削除してください。詳細については、「db.collection.hideIndex()」をご参照ください。

// players collection - document structure
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

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

時間ベースのパーティショニングパターンによりコレクションが時間とともに増加する場合、それらを単一のコレクションにマージすることで、蓄積の問題が解消されます。

最適化前 — temperatures データベースは、日ごとの測定値を個別のコレクションに保存します。

// temperatures.march-09-2020
{ "_id": 1, "timestamp": "2020-03-09T010:00:00Z", "temperature": 29 }
{ "_id": 2, "timestamp": "2020-03-09T010:30:00Z", "temperature": 30 }
// ... 25 readings total (sensor runs 10:00-22:00, every 30 minutes)
{ "_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 インデックスが作成されます。日をまたぐクエリには $lookup が必要であり、これは単一コレクションに対するクエリよりもパフォーマンスが低下します。

最適化後 — 単一の temperatures.readings コレクションは、1 日あたり 1 つのドキュメントですべてのデータを保存します。デフォルトの _id インデックスは、各日の測定値に対して追加のインデックスなしで日付ベースのクエリをサポートします。

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

これにより、無制限のコレクション増加問題が解消され、各日のインデックスを作成する必要がなくなります。

時系列ワークロードの場合、時系列コレクション (MongoDB 5.0 以降) の使用を検討してください。詳細については、「Time Series」をご参照ください。

インスタンスの分割

ApsaraDB for MongoDB スタンドアロンインスタンスのコレクションの総数を削減できない場合は、複数のインスタンスにデータを分割します。

シャードタグを使用したシャードクラスターへの移行

すべてのコレクションが単一の論理インスタンスの下に留まり、削減できない場合、それらをシャードクラスターインスタンスに移行し、シャードタグを使用して各コレクションを特定のシャードにピン留めします。これにより、アプリケーションの変更なしに dhandle の負荷がシャード全体に分散されます。変更されるのは接続文字列のみです。

たとえば、100,000 のアクティブなコレクションを 10 シャードクラスターに移行すると、シャードあたり約 10,000 のコレクションになります。

詳細については、「sh.addShardTag()」および「sh.addTagRange()」をご参照ください。

ゾーンを使用したシャードクラスターへの移行

ゾーンはシャードタグと同じように機能しますが、新しい sh.addShardToZone() および sh.updateZoneKeyRange() コマンドを使用します。詳細については、「シャードゾーンの管理」、「sh.addShardToZone()」、および「sh.updateZoneKeyRange()」をご参照ください。

コレクション数の多いデータベースで dropDatabase を実行しないこと

dropDatabase を実行すると、WiredTiger が非同期で当該データベース内のすべてのコレクションのメタデータおよび物理ファイルを削除します。この処理により、プライマリからセカンダリへのレプリケーションに影響が及び、レプリケーションラグが継続的に増加する可能性があります。また、このプロセス中には MongoDB のフローコントロール機構が有効化され、{writeConcern: majority} を指定したすべての書き込み操作が影響を受ける場合があります。

この問題を回避するには、以下のいずれかの方法をご利用ください：

• 各コレクションを個別に削除し、削除間隔を設けたうえで、すべてのコレクションが削除された後に dropDatabase を実行します。

• DTS またはその他の移行ツールを用いて、保持したいデータベースおよびコレクションを新しいインスタンスへ移行し、切り替え完了後に元のインスタンスを廃止します。

ご利用のインスタンスでレプリケーションラグのアラートを設定してください。万一この問題が発生した場合は、チケットを送信してテクニカルサポートをご利用ください。チケットを送信チケットを送信