MongoDB and Python by Niall O'Higgins

Author:Niall O'Higgins [Niall O'Higgins]
Language: eng
Format: epub
Tags: COMPUTERS / Programming Languages / Python
ISBN: 9781449310363
Publisher: O'Reilly Media
Published: 2011-09-15T16:00:00+00:00

Note

Note that the $ operator cannot be used with upserts (see section on upserts later in this chapter) additionally it only works with the first matched element.

When working with embedding, it is important to be aware of the performance characteristics of documents and sub-documents in MongoDB. First and foremost, when a document is fetched from the database to answer a query, the entire document—including any and all embedded sub-documents—is loaded into memory. This means that there is no extra cost (aside from the additional network and decode/encode CPU overhead incurred by a larger result set) to fetch embedded data. Once the top-level document has been retrieved, its sub-documents are immediately avaialble, too. Contrast this with a relational schema design utilizing joins, where the database may need to read from one or more additional tables to fetch associated data. Depending on the situation, these joins could impact query performance considerably.

Secondly, it is also very important to be aware that there is a size limit on documents in MongoDB. Additionally, the document size limit has been increased over successive major MongoDB releases. In MongoDB 1.4.x and 1.6.x, the maximum document size was 4MB but in 1.8.x it was increased to 16MB. One can expect that this limit may continue to increase—perhaps eventually to be arbitrarily large—but for now, keep in mind that documents have a finite size when modeling your data.

In practice, it is rare to reach even a 4MB document size, unless the design is such that documents continue to grow over time. For example, a scenario where new properties are created on an hourly or daily basis. In such cases, it is wise to ensure there is some application logic to handle purging old/expired embedded sub-documents to prevent the limit being hit.

Another example would be building a document publishing platform which embedded every single document posted by a user as a sub-document inside of the user document. While performance would be excellent since a single query for the user document could retieve all their published documents in a single shot, it is quite likely that some users would eventually publish more than 16MB of content.

Hence there is often a judgement call to be made when designing MongoDB schemas: To embed, or not to embed.

The alternative to embedding is storing the documents in a separate collection and performing a join in your own application code, by querying twice or more. Usually many-to-many relationships are modeled in this way, while one-to-many relationships are embedded.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.