Unit 1 — Introduction to NoSQL and the Fundamentals of MongoDB

Topics Covered

Syllabus topics: What is NoSQL DB? History and evolution of NoSQL, features of NoSQL databases, CAP theorem and BASE properties, types of NoSQL (key-value, document, column, graph), difference between RDBMS and NoSQL, why and when to use NoSQL, NoSQL database misconceptions, benefits and real-world use cases of NoSQL, comparison of popular NoSQL systems (Redis, Cassandra, CouchDB, Neo4j), introduction to JSON and BSON. Installation and setup, connecting via Mongo shell or GUI.

1.1 What NoSQL is

History

The driver was scale, not dissatisfaction with SQL. Google and Amazon had data that would not fit on one machine and traffic one machine could not serve. Sharding a relational database across hundreds of nodes while preserving joins and ACID is extremely hard; the NoSQL answer was to stop requiring it.

Features of NoSQL databases

1.2 The CAP theorem

                     C
                    / \
              CA   /   \   CP
                  /     \
                 /       \
                A ------- P
                    AP

⚠️ You do not actually get to choose all three pairs

This is the part that is usually taught badly, and stating it correctly earns marks.

Network partitions are not optional. Cables fail, switches reboot, packets are lost. In any real distributed system, P is a fact of the environment, not a design choice. So the real decision, when a partition happens, is:

• CP — refuse to answer rather than answer wrongly (sacrifice availability)
• AP — answer with possibly stale data rather than refuse (sacrifice consistency)

"CA" is not a meaningful choice for a distributed system. A single-node database is CA by default — there is nothing to partition — but as soon as you replicate, you must pick CP or AP.

MongoDB is tunable: read and write concerns let you move along the spectrum. w: "majority" is stronger, w: 1 is faster, and readPreference: secondary trades consistency for read scale.

1.3 The four types of NoSQL database

Key-value

"session:8842"  →  <opaque bytes>
"cart:21"       →  <opaque bytes>

The simplest and fastest model. The store does not know or care what the value contains, so you cannot query by its contents — only by key. Redis holds everything in memory, which makes it superb for caching and unsuitable as a system of record without care.

Document

{ "_id": 21, "name": "Asha", "dept": "DS",
  "marks": { "maths": 88, "stats": 91 },
  "subjects": ["DS", "Stats"] }

The step up from key–value is that the database understands the value. It can index dept, filter on marks.maths, and reach inside the subjects array. That is the whole difference, and it is why document stores are the most generally useful of the four.

Column-family

Not "a column store" in the analytics sense, despite the name. Data is stored by row key, with columns grouped into families, and each row may have different columns. Optimised for enormous write throughput and for reading ranges of rows.

Graph

Stores relationships as first-class objects. "Friends of friends who like jazz" is a three-hop traversal in Neo4j and a three-way self-join with a recursive CTE in SQL — the graph database is dramatically faster because the edges are pointers, not values to be matched.

1.4 Popular systems compared

Cassandra's masterless design is the real contrast with MongoDB. Every node is equal and accepts writes, so there is no primary to fail over — that is what makes it AP and what makes it linearly scalable for writes. The price is that you must know your queries before designing the tables, because there is no flexible ad-hoc querying.

1.5 RDBMS versus NoSQL

The vocabulary map — learn this table

"Foreign key: a reference, not enforced" is the row that matters. MongoDB will happily store an ObjectId pointing at a document that does not exist and will not stop you deleting the target. In Database Management Systems the database guaranteed referential integrity; here your application must.

1.6 When to use NoSQL — and when not

✅ Use a document database when

• You read and write one whole entity at a time — a user profile, a product page, an order with its lines

• The schema varies or evolves fast — a product catalogue where a book has an ISBN and a shirt has a size

• You need horizontal scale beyond one machine

• The data is naturally hierarchical — JSON from an API, nested configuration, event payloads

• Write throughput matters more than complex ad-hoc queries

• You are prototyping and the schema is not settled

❌ Do not use one when

• The data is highly relational and queried from many directions — a banking ledger, an ERP

• You need complex ad-hoc joins across many entities

• Strong multi-entity transactional guarantees are central — money, stock ledgers, seat reservations

• Reporting and BI tools must connect (they speak SQL)

• The team knows SQL and the data fits comfortably on one machine
• You are choosing it because it is fashionable — the honest and commonest wrong reason

⚠️ The misconceptions

The syllabus names this topic explicitly, and each of these is a frequently-marked answer.

That last row is worth knowing: MongoDB's early reputation for data loss was earned by a default setting, w: 0, which acknowledged a write before it was stored. The default is now w: 1 (and w: "majority" for replica sets). Being able to say what the criticism was and that it was fixed is a better answer than either defending or repeating it.

1.7 Real-world use cases

MongoDB's own headline users — Forbes, Toyota, Adobe, eBay — mostly use it for exactly this: catalogue and content data, read one entity at a time, where the schema varies by category.

1.8 JSON and BSON

The _id field

Every document has one, and it is the primary key.

{ "_id": ObjectId("66cd12f4a1b2c3d4e5f60718"), "name": "Asha" }

If you do not supply one, MongoDB generates an ObjectId: 12 bytes, made of

| 4 bytes timestamp | 5 bytes random per-process | 3 bytes counter |

Three consequences worth knowing:

1. It is unique without coordination. Any client can generate one without asking the server, which is what makes it work in a distributed system.

2. It embeds a creation time — ObjectId.getTimestamp() — so you often do not need a separate createdAt field.

3. It sorts roughly by creation time, because the timestamp is the leading bytes. Sorting by _id descending is a cheap "newest first".

You may use your own value instead — a roll number, an email — and it will be enforced unique. That is often better than an ObjectId when a natural key exists.

1.9 Installation and connecting

Installing

Atlas or Docker is the recommendation. A local install commits you to managing a service; the free Atlas tier gives you a real replica set, which the local install does not.

(The verification environment for these notes can do none of the three — MongoDB's own download hosts are blocked there — so it runs conda-forge's build of MongoDB 8.3.7, unpacked by tools/data-science/setup_mongodb.sh, and every mongosh script in lab.md ran on it. Updated October 2026: until then it ran no server at all, and the labs paired each script with a mongomock equivalent, which they still do.)

Connecting

mongosh                                        # localhost:27017
mongosh "mongodb://localhost:27017"
mongosh "mongodb+srv://user:pass@cluster.mongodb.net/mydb"   # Atlas

The syllabus calls it the Mongo shell, and you will meet both names: the old shell was the mongo command, and it was replaced in MongoDB 5.0 by mongosh. They are the same thing for exam purposes — the Mongo shell — and mongosh is the one you actually type.

mongosh is a JavaScript environment, which is genuinely useful:

use collegeDB                       // switch database (creates it lazily)
db                                  // the current database
show dbs                            // list databases
show collections
db.students.find()

for (let i = 1; i <= 5; i++) {      // real JavaScript, in the shell
  db.counters.insertOne({ n: i, square: i * i })
}

⚠️ Databases and collections are created lazily

use brandNewDB          // switches, but creates NOTHING
show dbs                // brandNewDB is ABSENT
db.things.insertOne({ x: 1 })
show dbs                // now it appears

A database or collection does not exist until the first document is written to it. show dbs omitting the database you just "created" is not a bug, and it surprises everyone once.

The default port

27017. Worth knowing for the viva; 27018 and 27019 are the conventional ports for shard members and config servers.

Practice problems

{ _id: 1, name: "MongoDB: The Definitive Guide", category: "book",
  price: 2400, isbn: "978-1491954461", author: "Chodorow", pages: 514 }

{ _id: 2, name: "College T-Shirt", category: "shirt",
  price: 599, size: "L", colour: "navy", material: "cotton" }

Exam questions from this unit

Two marks

1. What does NoSQL stand for?
2. State the CAP theorem.
3. Why is "CA" not a real choice for a distributed system?
4. What does BASE stand for?
5. Name the four types of NoSQL database with an example of each.
6. Distinguish JSON from BSON.
7. What is an ObjectId, and what is it made of?
8. Give the MongoDB term for a table, a row and a column.
9. What is MongoDB's default port?
10. Name two NoSQL misconceptions.

Five marks

1. Explain the CAP theorem with a diagram and classify three systems.
2. Explain ACID and BASE, and compare them.
3. Explain the four types of NoSQL database with examples and use cases.
4. Compare RDBMS and NoSQL.
5. Compare Redis, MongoDB, Cassandra, CouchDB and Neo4j.
6. Explain JSON and BSON and why MongoDB uses BSON.
7. Explain when NoSQL should and should not be used.

Ten marks

1. Explain NoSQL exhaustively — history, features, types, CAP, BASE and use cases — with examples.

2. Compare RDBMS with MongoDB across every dimension, with the vocabulary map.

3. Given a business scenario, choose a database type and justify the choice fully, including what you would still be careful about.

Mistakes that cost marks