Today I was testing MongoDB capped collections for viability as a fast-access key/value store. My go-to solution for that is usually Redis, but this is for a project that is already using MongoDB and I didn’t want to introduce a separate dependency.
As with Redis, we ended up going with TTLs for this instead, but here are some things I found out about capped collections:
MongoDB capped collections don’t use _id to determine insertion order.
As you may know, the first 8 bytes of each document’s ObjectId is a hexadecimal Unix timestamp. I didn’t know if MongoDB used this to determine insertion order.
In other words, if I use my own custom _id to achieve constant time lookups based on some key that’s meaningful to me (say, a SHA-1 hash), will MongoDB get confused about which documents are the oldest and therefore should be removed first?
Turns out that MongoDB apparently keeps internal timestamp information for capped collections, because the custom _id makes no difference.
The `size` parameter is in bytes, not documents.
Obvious, perhaps–it’s in the documentation–but worth mentioning.
The minimum capped collection size is 4096.
See this issue. If the size is specified less than 4096, it will silently round up.