MongoDBにおけるページネーションパターン

フィード、商品リスト、または検索結果ページを構築しているとします。コレクションが数百万のドキュメントに成長すると、突然ページネーションクエリがミリ秒ではなく秒単位で時間がかかるようになります。原因はほぼ常に同じです:大規模なデータに対してskipとlimitを使用しているのです。

この記事では、MongoDBの主要なページネーションパターン(オフセットベースとカーソル/キーセットベース)を取り上げ、それぞれがどのような場合に有効で、どのような場合に有効でないかを説明します。フレームワーク固有のアドバイスではなく、データが成長しても有効なパターンを紹介します。

MongoDB Skip Limit ページネーション:馴染みのあるアプローチ

オフセットベースのページネーションは、skip()とlimit()を使用して結果をページに分割します。直感的で、「ページ1、ページ2、ページ3」というUIパターンに直接対応します。

db.posts.find()
  .sort({ createdAt: -1 })
  .skip((page - 1) * pageSize)
  .limit(pageSize)

このパターンは、浅いページング(結果の最初の数ページ)、限られたデータを持つ管理ダッシュボード、またはパフォーマンスが重要でない内部ツールには問題なく機能します。

Skipが大規模データで劣化する理由

MongoDBのインデックスはB-tree構造であり、配列ではありません。データベースはインデックス内を効率的にシークできますが、要求されたオフセットに到達するためにスキップされたエントリを順に進む必要があります。10ドキュメントをスキップすると10個のインデックスエントリを通過します。100,000をスキップすると100,000個のエントリを通過します。

つまり、ページ1は高速ですが、ページ100は遅くなり、ページ10,000はさらに大幅に遅くなります。CPU使用率は、ページサイズに関係なく、オフセット値に比例して増加します。

オフセットページネーションを使用すべき場合:

• ユーザーが最初の数ページを超えてナビゲートすることがほとんどない場合
• 総データセットが小規模(10,000ドキュメント未満)の場合
• 「ページXにジャンプ」機能が必要で、トレードオフを受け入れられる場合
• クエリ時間がそれほど重要でない内部ツールを構築する場合

MongoDB カーソルベースページネーション:一貫したパフォーマンス

MongoDBキーセットページネーション(カーソルベースページネーションとも呼ばれる)は、位置的なオフセットの代わりに範囲クエリを使用します。「1,000ドキュメントをスキップ」と言う代わりに、「この特定のポイント以降のドキュメントを取得」と指定します。

db.posts.find({ createdAt: { $lt: lastSeenDate } })
  .sort({ createdAt: -1 })
  .limit(pageSize)

データベースは効率的なインデックスシークを実行して開始点を特定し、必要なドキュメントのみを読み取ります。ページ1とページ10,000は同一のパフォーマンス特性を持ちます。

タイブレーカーの必要性

単一のソートフィールドは、値が一意でない場合に問題を引き起こします。複数のドキュメントが同じcreatedAtタイムスタンプを共有している場合、一部がページ間でスキップされたり重複したりする可能性があります。

解決策は、一意のタイブレーカー(通常は_id)を使用した複合ソートです:

db.posts.find({
  $or: [
    { createdAt: { $lt: lastDate } },
    { createdAt: lastDate, _id: { $lt: lastId } }
  ]
})
.sort({ createdAt: -1, _id: -1 })
.limit(pageSize)

これには、対応する複合インデックスが必要です:

db.posts.createIndex({ createdAt: -1, _id: -1 })

最適なパフォーマンスを得るには、インデックスフィールドの順序がソート順序と一致する必要があります。

一貫性に関する注意点

カーソルベースのページネーションはオフセットページネーションよりも安定していますが、魔法のように一貫性があるわけではありません。リクエスト間でドキュメントが挿入、削除された場合、または可変のソートフィールドが変更された場合、ユーザーは依然として重複を見たり、アイテムを見逃したりする可能性があります。違いは、キーセットページネーションが位置ではなく特定の値に固定されるため、同時書き込みによって発生する可視的な異常が通常少なくなることです。

完全な一貫性が必要ないフィードやリストの場合、このトレードオフは通常許容されます。

Atlas Search ページネーション:異なるメカニズム

MongoDB Atlas Searchを$searchステージで使用している場合、ページネーションの動作は異なります。Atlas Searchは、_idカーソルではなく、searchAfterおよびsearchBeforeパラメータを使用して、独自のトークンベースシステム(内部的にはsearchSequenceToken経由)を使用します。これらのアプローチを混在させないでください。クエリタイプに合ったページネーション方法を使用してください。

適切なパターンの選択

決定はしばしばUI要件に依存します。ユーザーが任意のページにジャンプする必要がある場合、オフセットページネーションまたはハイブリッドアプローチに制約されます。順次ナビゲーション(次へ、前へ、さらに読み込む)で十分な場合、キーセットページネーションの方がスケーラビリティに優れています。

結論

skipとlimitを使用したオフセットページネーションはシンプルですが、オフセットサイズに比例して線形的に劣化します。浅いページングまたは小規模データセット用に予約してください。

キーセットページネーションは位置に関係なく一貫したパフォーマンスを維持しますが、一意のタイブレーカーを使用した決定論的なソートが必要です。フィード、リスト、およびユーザーが大規模な結果セットを順次ナビゲートするインターフェースには、こちらの方が適しています。

どちらのパターンも普遍的に間違っているわけではありません。データサイズ、アクセスパターン、UI要件に基づいて選択してください。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.