Design patterns - MongoDB in Action - page 258

This gives the application good locality. When you query for recent visits, you're
always querying a single collection that's relatively small compared with the overall
analytics history. If you need to delete data, you can drop a time-scoped collection
rather than removing some subset of documents from a larger collection. That latter
operation may result in on-disk fragmentation.
The other principle at work here is precomputation . Sometime near the beginning of
the month, you insert a template document with zeroed values for each day of the
month. As a result, the document will never change size as you increment the counters
therein because you'll never actually be adding fields; you'll only be changing their val-
ues in-place. This is important because it keeps the document from being relocated on
disk as you write to it. Relocation is slow and often results in fragmentation.

B.2 Anti-patterns

MongoDB lacks constraints, which can lead to poorly organized data. Here are a few
issues commonly found in problematic production deployments.

B.2.1 Careless indexing

When users experience performance problems, it's not unusual to discover a whole
slew of unused or inefficient indexes. The most efficient set of indexes for an applica-
tion will always be based on an analysis of the queries being run. Be disciplined about
the optimization methods presented in chapter 7.

B.2.2 Motley types

Ensure that keys of the same name within a collection all share the same type. If you
store a phone number, for instance, then store it consistently, either as a string or an
integer (but not as both). The mixing of types in a single key's value makes the appli-
cation logic complex, and makes BSON documents difficult to parse in certain
strongly typed languages.

B.2.3 Bucket collections

Collections should be used for one type of entity only; don't put products and users in
the same collection. Because collections are cheap, each type within your application
should get its own collection.

B.2.4 Large, deeply nested documents

There are two misunderstandings about MongoDB's document data model. One is
that you should never build relationships between collections, but rather represent all
relationships in the same document. This frequently degenerates into a mess, but
users nevertheless sometimes try it. The second misunderstanding stems from an
overly literal interpretation of the word document . A document, these users reason, is a
single entity just like a real-life document. This leads to large documents that are diffi-
cult to query and update, let alone comprehend.