Docs Menu

上限付きコレクション

上限付きコレクションとは、挿入順序に基づいてドキュメントを挿入、取得する固定サイズのコレクションです。機能方法は循環バッファと同様で、コレクションの割り当て領域に達すると、内部の最も古いドキュメントを上書きすることで、新しいドキュメントに空き領域が作成されます。

  • 上限付きコレクションはシャーディングできません。

  • サーバーレスインスタンスでは上限付きコレクションは作成できません。

  • 上限付きコレクションは、Stable API V1. ではサポートされていません。

  • トランザクションでは上限付きコレクションへの書き込み (write) はできません。

  • $out 集計パイプライン ステージでは 上限付きコレクションに結果を書き込めません。

次の例では、最大サイズが 100,000 バイトの log という名前の上限付きコレクションを作成します。

db.createCollection( "log", { capped: true, size: 100000 } )

上限付きコレクションの作成の詳細については、「createCollection()」または「create」を参照してください。

一般的に、 TTL(Time To Live)インデックスは、Cappedコレクションよりも優れたパフォーマンスと柔軟性を提供します。 TTL インデックスは期限切れとなり、日付型フィールドの値とインデックスの TTL 値に基づいて、通常のコレクションからデータを削除します。

Capped コレクションでは書込み操作がシリアル化されるため、それ以外のコレクションよりも同時挿入、更新、削除のパフォーマンスは低くなります。 Capped コレクションを作成する前に、TTL インデックスで代替できないかを検討しましょう。

上限付きコレクションの最も一般的なユースケースは、ログ情報の保存です。上限付きコレクションが最大サイズに達すると、古いログ エントリは自動的に新しいエントリで上書きされます。

上限付きコレクションを作成し、クエリするには、次のページを参照してください。

上限付きコレクションについては、上記の詳しい動作を考慮してください。

操作のログをレプリカセットにストアする oplog.rs コレクションには、上限付きコレクションが使われます。

他の上限付きコレクションとは異なり、oplog は、 majority commit pointが削除されないように、構成されたサイズ制限を超えて大きくなる可能性があります。

注意

MongoDB では、oplog の上限サイズを、256 の倍数の最も近い整数に切り上げます(単位はバイト)。

上限付きコレクションには、デフォルトで _id フィールドと _id フィールドにインデックスがあります。

上限付きコレクションのデータはアップデートしないでください。このコレクションはサイズが固定されており、アップデートするとコレクションの割り当て領域を超えてデータが拡大し、予期しない動作が発生する恐れがあります。

コレクションから最後に挿入された要素を効率的に検索するには、自然な順序付け機能を使用します。この機能を用いると、ログファイルに対して tail コマンドを使用するのと同様の結果が得られます。

上限付きコレクションでは、追尾可能 (tailable) カーソルを使用できます。Unix tail -f コマンドと同様に、追尾可能 (tailable) カーソルは、上限付きコレクションの最後に「追尾」します。新しいドキュメントが上限付きコレクションに挿入されたら、追尾可能 (tailable) カーソルを使用してドキュメントの検索を続行できます。

追尾可能 (tailable) カーソルの作成の詳細については、「追尾可能 (tailable) カーソル」を参照してください。

Capped コレクションへの同時書込み(write)が存在する場合、MongoDB はドキュメントが挿入順で返されることを保証しません。

MongoDB 8.0 以降では、上限付きコレクションで読み取り保証 (read concern) "snapshot" を使用できます。