Mongo Sandbox

In Mongodb, collections are just named containers, like tables in relational databases. A collection is comprised of documents. Documents can contain embedded documents within them. Every top-level (collection root) document gets a unique _id. _ids are optional for sub-documents. It is these _ids that make Mongodb a NoSQL database. You don't need primary keys, as in a SQL database, to find what you are looking for. You simply use _ids. Many of the complexities of SQL are eliminated. Mongo is lightening fast.

When running an app in stateless node, you don't want your data structures' data cached in memory--or, at least, you want it cached to volatile storage for as little time as possible. You want your arrays read directly from and written directly to non-volatile storage. The mongodb driver for node.js supports this, with some limitations. When node.js app writes data, the data is mostly persisted immediately to durable storage. Every transaction is immediately journaled so that you can recover any data that is lost in the event that the database crashes before data is written to it. Information that is lost due to server crash during journaling can't be recovered, but that's extremely rare. There are OS and devops configurations and techniques that are used to ensure that journaling completes in every instance. With replication, mongodb scales like a dream. However, you can write only to the primary mongo node:

• https://docs.mongodb.com/manual/replication/
• https://github.com/williamkapke/mongo-mock

Please note that:

• Modern MongoDB uses document-level locking for writes.
• Two clients can update different documents in the same collection concurrently.
• Two clients trying to update the same document may contend with each other.
• MongoDB does not lock individual fields within a document.

If you need local databases that contain a subset of the "mother" database for offline access, use solutions like CouchDB. Mongo won't help you much there.