MongoDB – Data Modelling

MongoDB is a NoSQL database that uses a document-oriented data model, where data is stored in BSON (Binary JSON) format as documents within collections. This approach is different from traditional relational databases (RDBMS), which use tables and rows.

Here’s a brief overview of data modeling in MongoDB:

1. Collections

• A collection is a group of documents (similar to a table in RDBMS).
• Collections do not require a predefined schema (i.e., fields and their data types can vary across documents).
• Documents in a collection can have different structures, allowing flexibility.

2. Documents

• A document is a data record in MongoDB, represented in BSON format (binary JSON).
• Each document has a unique identifier, typically the _id field (automatically generated by MongoDB unless specified).
• Documents are key-value pairs where the key is a field name and the value is the data (e.g., string, number, date, array, or even nested documents).

3. Schema-less Design

• MongoDB does not enforce a strict schema for collections. This allows for easy and flexible changes in data structure over time without requiring migrations.
• This flexibility is ideal for applications with evolving data models.

4. Embedding vs. Referencing

MongoDB supports two main approaches for modeling relationships between documents:

Embedding

• In embedding, related data is stored within a single document, creating a denormalized data structure.
• Use cases: This approach is suitable when data is read together frequently or when relationships are one-to-many.
• Example: Storing user profile with embedded address, order history, and other sub-documents.

{
   "_id": 1,
   "name": "John Doe",
   "addresses": [
       { "street": "123 Elm St", "city": "Springfield" },
       { "street": "456 Oak St", "city": "Shelbyville" }
   ]
}

Referencing

• In referencing, related data is stored in separate documents, and references are used to link them.
• Use cases: When data is too large or frequently updated, or when the relationship is many-to-many.
• Example: Storing user and order as separate documents and linking them via references.

{
   "_id": 1,
   "name": "John Doe",
   "orders": [ { "$ref": "orders", "$id": 101 }, { "$ref": "orders", "$id": 102 } ]
}

5. Indexing

• MongoDB supports indexing, which allows fast searching and querying on documents based on specific fields.
• Common index types include single field indexes, compound indexes, and geospatial indexes.
• Indexing helps improve read performance, but excessive indexing can impact write performance.

6. Sharding

• Sharding is the process of splitting data across multiple servers to scale horizontally.
• MongoDB automatically handles the distribution of documents across shards based on a shard key.

7. Data Model Design Considerations

• Data Duplication: In MongoDB, data duplication is allowed and sometimes beneficial for performance, especially for embedding.
• Consistency vs. Performance: In some cases, referencing may introduce performance overhead due to joins, but embedding can provide faster reads.
• Scalability: MongoDB’s horizontal scalability (via sharding) makes it suitable for applications with massive data volumes.

Example Use Cases for MongoDB Data Modeling

• E-commerce platforms: Products, customers, orders, and reviews can be modeled using embedding (for product details) and referencing (for orders).
• Social Media: Users and their posts can be embedded, but followers and relationships can be referenced.
• IoT Applications: Storing sensor data and device logs in documents with dynamic fields.

Conclusion

MongoDB provides a flexible, schema-less data model where you can choose between embedding or referencing data based on the specific needs of your application. It excels in use cases where data structures change frequently, and scalability and performance are key priorities.