Database Reference
In-Depth Information
The bottom line here is that you should keep documents small (well under 100 KB
per document unless you're storing raw binary data) and that you shouldn't nest
more than a few levels deep. A smaller size makes document updates cheaper
because, in the case where a document needs to be rewritten on disk completely,
there's less to rewrite. The other advantage is that the documents remain comprehen-
sible, which makes life easier for developers needing to understand the data model.
B.2.5
One collection per user
It's rarely a good idea to build out one collection per user. One problem with this is
that the namespaces (indexes plus collections) max out at 24,000 by default. Once
you grow beyond that, you have to allocate a new database. In addition, each collec-
tion and its indexes introduce extra overhead, making this strategy a waste of space.
B.2.6
Unshardable collections
If you expect a collection to grow large enough to merit sharding, be sure that you
can eventually shard it. A collection is shardable if you can define an efficient shard
key for that collection. Review the tips in chapter 9 on choosing a shard key.
Search WWH ::




Custom Search