NoSQL Design Principles & Architecture
Data Modeling in NoSQL
Data modeling refers to the process of deciding how data is structured, stored, and accessed in a
database.
In relational databases, data modeling follows strict rules such as tables, rows, columns,
normalization, and fixed schemas. However, in NoSQL databases, data modeling follows a
different and more flexible approach, focusing mainly on application requirements, performance,
and scalability rather than rigid structure.
NoSQL databases are designed to handle large volumes of data, high user traffic, and distributed
systems, which is why their data modeling techniques differ from traditional SQL databases.
1. Core Principles of NoSQL Data Modeling
Unlike traditional SQL modeling, NoSQL follows a "Query-First" approach.
Query-Driven Design: In NoSQL, you must define your application's access patterns
(how you will query the data) before designing the database structure.
Denormalization: Instead of splitting data into multiple tables to reduce redundancy (as
in SQL), NoSQL encourages storing related data together. This removes the need for
expensive "Joins" and increases read speed.
o Rule of Denormalization: In SQL, we use separate tables. In NoSQL, we "Copy-
Paste" data to keep it together.
Schema Flexibility: NoSQL supports "Schema-on-read," meaning each record
(document) can have a different structure. This allows developers to add new fields
without migrating the entire database.
Embedding vs. Referencing:
o Embedding: Storing related data inside a single document (Best for 1-to-1 or
small 1-to-many relationships).
o Example : If you have a Blog post and its comments, in NoSQL, you put the
comments inside the post document. This way, the database doesn't have to look
in two places; it gets everything in one "click."
o Referencing: Storing an ID to link to another document (Best for large datasets
that change frequently).
o Example: If a piece of data grows too large (e.g., millions of followers), we don't
embed it. We just store an "ID" as a link to avoid making the file too heavy.
2. Scalability: The "Bus" Analogy
Vertical Scaling (SQL): Think of a single bus. If more passengers come, you try to add
more seats to the same bus. Eventually, you run out of space. This is expensive and
limited.
Horizontal Scaling (NoSQL): If more passengers come, you simply start a second bus.
You can add as many buses (servers) as you want. This is how Facebook and Google
handle billions of users.
3. Availability: The "Global Backup" Concept
NoSQL is built to stay "Online" 24/7.
Example: Imagine your data is stored on three different servers: one in Pakistan, one in
Dubai, and one in the USA. If the Dubai server crashes due to a power outage, the system
automatically pulls data from the USA server. The user never sees an "Error" or "System
Down" message.
4. CAP Theorem: The "Three-Way" Choice
The CAP Theorem states that a distributed system can only provide two out of the
three following guarantees at the same time:
1. Consistency (C): Every user sees the exact same data at the same time, no matter which
server they connect to.
2. Availability (A): The system always responds to requests, even if the data isn't perfectly
up-to-date.
3. Partition Tolerance (P): The system continues to work even if the network connection
between servers is broken.
ATM Example (Consistency + Partition Tolerance): If the bank's network is down, the
ATM will refuse to give you money. Why? Because Consistency is vital—the bank must
be 100% sure of your balance before you withdraw.
Social Media Example (Availability + Partition Tolerance): If you "Like" a post on
Instagram while the connection is weak, the app won't stop working. It might show 98
likes instead of 100 for a moment, but it stays online. Here, Availability is more
important than perfect accuracy.
5. BASE Properties: The "YouTube Views" Example
NoSQL follows the BASE model, which is "relaxed" compared to SQL’s strict ACID model.
Basically Available: The system will always give you a response.
Soft State: The data can change or be "in-between" for a short time.
Eventual Consistency: This is the most important part. It means the data will be 100%
correct eventually.
Example: When a famous YouTuber uploads a video, the view count might show 1,000
views for you and 950 views for your friend. However, after a few seconds, all servers
sync up and show the same number (e.g., 1,200). It wasn't perfect immediately, but it
became consistent eventually.
6. Comparison
Feature SQL (Relational) NoSQL (Non-Relational)
Philosophy "Data First" "Query First"
Structure Fixed Tables Flexible Documents
Growth Bigger Server (Vertical) More Servers (Horizontal)
Accuracy 100% Immediate (ACID) Eventually Consistent (BASE)
Modeling Challenges in NoSQL
Although NoSQL databases are flexible, data modeling in NoSQL introduces several challenges.
One major challenge is the lack of traditional joins. Unlike relational databases, NoSQL
systems either do not support joins or support them in a limited way. Because of this, developers
must decide in advance whether related data should be embedded in a single document or
stored separately and referenced. This decision greatly affects performance and scalability.
Another challenge is data duplication. To improve read performance, NoSQL databases often
store the same data in multiple places. While this makes data retrieval faster, it creates problems
when data needs to be updated, because all duplicated copies must be changed to maintain
consistency.
A third challenge is query-based data modeling. In NoSQL, data is modeled based on how the
application will query it. If application queries change in the future, the existing data model may
no longer be efficient, and redesigning the data structure can be time-consuming.
Finally, consistency management is a challenge in distributed NoSQL systems. Many NoSQL
databases prioritize availability and performance over strict consistency, which means developers
must carefully handle data accuracy at the application level.
Schema-less Design in NoSQL
Schema-less design does not mean that there is no structure at all. It means that the database
does not force a fixed schema on the data.
In NoSQL databases such as MongoDB, each document can have a different structure. For
example, one student document may include a phone number, while another may not. The
database does not reject such differences.
This flexibility allows applications to evolve easily. New fields can be added without modifying
existing records or performing complex schema migrations.
However, schema-less design also shifts responsibility from the database to the developer. If
proper rules are not enforced at the application level, data inconsistency may occur, such as
storing the same field in different formats across documents.
Impact of Schema-less Design on Data Modeling
Because NoSQL databases are schema-less, data modeling becomes application-driven.
Developers first analyze how data will be read and written, and then design documents
accordingly.
A common practice is embedding, where related data is stored inside a single document to
improve read performance. This is useful for frequently accessed data. However, if documents
grow too large, performance issues may arise.
Another approach is referencing, where related data is stored in separate collections and linked
using identifiers. This approach improves scalability but may require multiple queries to retrieve
complete information.
Case Study: Student Management System Using NoSQL
System Overview
Consider a University Student Management System built using a NoSQL database. The
system manages:
Student profiles
Courses
Enrollments
Attendance records
The application requires fast access to student data, high scalability, and minimal query latency.
Limitation of SQL Approach
In a traditional SQL database, separate tables would be created for students, courses,
enrollments, and attendance. Data would be retrieved using multiple joins.
However, since student profiles and their course details are accessed frequently and together, this
approach may reduce performance in high-traffic systems. Therefore, a NoSQL approach is more
suitable.
NoSQL Data Modeling Solution
1. Schema-less Student Document
Each student is stored as a document. The structure may vary from one student to another.
Example:
{
"_id": "S101",
"name": "Ali Khan",
"program": "BSCS",
"email": "ali@[Link]"
}
Additional fields can be added without affecting existing documents.
2. Handling Relationships Without Joins
Since NoSQL avoids joins, course data is embedded inside the student document.
{
"_id": "S101",
"name": "Ali Khan",
"program": "BSCS",
"courses": [
{
"course_id": "CS501",
"course_name": "Advanced Database Systems",
"credit_hours": 3
}
]
}
Advantage
Student profile and course data can be retrieved in a single read operation, improving
performance.
Disadvantage
If course information changes, it must be updated in multiple student documents, leading to data
duplication.
3. Attendance Modeling Challenge
Attendance data grows rapidly and is updated frequently.
Poor Design (Embedding Attendance)
Embedding attendance inside student documents can cause documents to become too large,
reducing performance.
Better Design (Referencing Attendance)
Attendance is stored in a separate collection and linked using student and course IDs.
This approach improves scalability but requires additional queries to retrieve complete
information.
4. Schema-less Consistency Issue
Because there is no enforced schema, the same field may be stored in different formats across
documents, leading to inconsistency.
This issue must be handled using:
Application-level validation
Data standards
Optional schema validation rules
This case study shows that NoSQL data modeling is query-driven and flexible, but not
automatic. Developers must carefully balance performance, scalability, and data consistency.
Schema-less design provides freedom, but disciplined design practices are essential.