Additional Resource • Deploy a Geographically Redundant Replica Set (page 608). • Whitepaper: MongoDB Multi-Data Center Deployments 79 • Webinar: Multi-Data Center Deployment 80 MongoDB Documentation, Release 3.0.4 Capped collections are fixed-size collections that support high-throughput operations that insert and retrieve docu- ments based on insertion order. Capped collections work in a way similar to circular buffers: once a collection fills its allocated space, it makes room for new documents by overwriting the oldest documents in the collection. See createCollection() or create for more information on creating capped collections. Capped collections have the following behaviors: Capped Collections • Capped collections guarantee preservation of the insertion order. As a result, queries do not need an index to return documents in insertion order. Without this indexing overhead, they can support higher insertion through- put. • Capped collections guarantee that insertion order is identical to the order on disk ( natural order ) and do so by prohibiting updates that increase document size. Capped collections only allow updates that fit the original document size, which ensures a document does not change its location on disk. • Capped collections automatically remove the oldest documents in the collection without requiring scripts or explicit remove operations. For example, the oplog.rs collection that stores a log of the operations in a replica set uses a capped collection. Consider the following potential use cases for capped collections: • Store log information generated by high-volume systems. Inserting documents in a capped collection without an index is close to the speed of writing log information directly to a file system. Furthermore, the built-in first-in-first-out property maintains the order of events, while managing storage use. • Cache small amounts of data in a capped collections. Since caches are read rather than write heavy, you would either need to ensure that this collection always remains in the working set (i.e. in RAM) or accept some write penalty for the required index or indexes. • You can only make in-place updates of documents. If the update operation causes the document to grow beyond their original size, the update operation will fail. • If you update a document in a capped collection to a size smaller than its original size, and then a secondary resyncs from the primary, the secondary will replicate and allocate space based on the current smaller document size. If the primary then receives an update which increases the document back to its original size, the primary will accept the update but the secondary will fail with a failing update: objects in a capped ns cannot grow error message. If you plan to update documents in a capped collection, create an index so that these update operations do not require a table scan. Recommendations and Restrictions $^{79}$http://www.mongodb.com/lp/white-paper/multi-dc?jmp=docs $^{80}$https://www.mongodb.com/presentations/webinar-multi-data-center-deployment?jmp=docs 209 5.1. Administration Concepts