https://github.com/ramnes/awesome-mongodb
https://www.mongodb.com/blog/post/performance-best-practices-mongodb-data-modeling-and-memory-sizing
https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1
https://docs.mongodb.com/manual/data-modeling/
https://www.mongodb.com/blog/post/building-with-patterns-a-summary
Multi document transactions in mongodb:
https://www.mongodb.com/blog/post/quick-start-nodejs--mongodb--how-to-implement-transactions
Schema design
Modelling 1 to N relationships:
Establish the cardinality of the relationship: 1 to few, 1 to many(a few thousands) or 1 to squillions.
For 1 to few(embedding):
Consider embedding the N part as an array of documents into the parent document. Advantages: all of embedded docs. Disadvantages: We'll always need parent doc to access the embedded docs. Embedded docs cannot be accessed as stand-alone docs. For certain use-cases where we might need to access the embedded docs only, queries will not be simple. For eg, consider books written by an author are embedded inside the author document. Now to get all books written in the current year, we'll need to got through all the authors.
For 1 to many(child referencing):
Creating a stand-alone collection for the N side and putting their references into an array in the parent document. Advantages: Embedded docs can be used by multiple parent docs(relationship becomes N to M), they can be accessed as stand-alone entities. Disadvantage: joins have to be performed to get details. Problem of re-indexing when the array of references grows.
Application level joins: First fetch the parent doc, get the array of references. Then perform a query with $in condition on the sub-document.
For 1 to Squillions(parent referencing):
When number of elements in the array of references(in the parent array) goes too large, 16MB document size might get exceeded. Also, when an array field grows, there is a risk of re-indexing(mongo stores whole doc in a single memory location, if doc exceeds the allocated size, then it is moved to a separate location). Use parent references: add a parent id field to the N side of relationship. Application level join will look different here: first get the parent _id. Then look for items in N side where parent = parent._id.
Other techniques: