Operational Intelligence - MongoDB Applied Design Patterns - page 55

Capped collections

Strategy: Depending on your data retention requirements as well as your reporting and ana-
lytics needs, you may consider using a capped collection to store your events. Capped collec-
tions have a fixed size, and drop old data automatically when inserting new data after reaching
cap.

WARNING

In the current version, it is not possible to shard capped collections.

TTL collections

Strategy: If you want something like capped collections that can be sharded, you might con-
sider using a “time to live” (TTL) index on that collection. If you define a TTL index on a
collection, then periodically MongoDB will remove() old documents from the collection. To
create a TTL index that will remove documents more than one hour old, for instance, you can
use the following command:

>>> >>> db . events . ensureIndex ( 'time' , expireAfterSeconds = 3600 )

Although TTL indexes are convenient, they do not possess the performance advantages of
capped collections. Since TTL remove() operations aren't optimized beyond regular re-
move() operations, they may still lead to data fragmentation (capped collections are never
fragmented) and still incur an index lookup on removal (capped collections don't require in-
dex lookups).

Multiple collections, single database
Strategy: Periodically rename your event collection so that your data collection rotates in
much the same way that you might rotate logfiles. When needed, you can drop the oldest col-
lection from the database.

This approach has several advantages over the single collection approach:

▪ Collection renames are fast and atomic.

▪ MongoDB does not bring any documents into memory to drop a collection.