MongoDB

Why NoSQL?

• The relational model asks you to know the schema up front, and to normalise data across tables
• That is a good fit for many problems, and a poor one when
  • documents differ from each other in shape
  • the data does not fit on a single machine
  • reads dominate, and joins get expensive
• NoSQL is not one database, it is a family of trade-offs

Taxonomy

• Key-Value: a hash table, e.g. Redis
• Document: self-describing records, e.g. MongoDB
• Column Family: wide sparse rows, e.g. Cassandra
• Graph: nodes and edges as first-class things, e.g. Neo4j

Questions to Ask

• Data model: are your records rows, documents, or a graph?
• Scalability: does the data fit on one server, now and later?
• Transactions: do a set of operations need to succeed or fail together?
• Query: do you know the access patterns in advance?

The CAP Theorem

• In the presence of a network partition, a distributed system must choose between
• Consistency: every read sees the latest write
• Availability: every request gets an answer
• Partitions are not optional, so the real choice is what to do when one happens

Replica Sets

The same data on several servers. If the primary disappears, the members elect a new one, so failover needs no operator.

Sharding

Horizontal scale: one logical database split by a shard key. A poor key sends every query to every shard, or every write to one shard.

What is MongoDB?

• A document-oriented database, first released in 2009
• Documents are stored as BSON, a binary form of JSON with more types
• Dates, 32/64-bit numbers, and binary data, which JSON lacks
• Secondary indexes, an aggregation pipeline, and a query language

Hierarchy

• A server holds zero or more databases
• A database holds zero or more collections
• A collection holds zero or more documents

Coming From SQL

Processes

• mongod: the database server
• mongos: the router in front of a sharded cluster
• mongosh: the shell, a full JavaScript environment

Schema Free?

• MongoDB does not require a schema, and two documents in one collection may differ
• But the data still has a schema. The question is only whether the database or your application enforces it
• Schema validation exists when you want the database to check

{ "_id": 1, "name": "R2-D2", "race": "Droid", "affiliation": "rebels" }
{ "_id": 2, "name": "Han Solo", "ship": "Millennium Falcon" }
    

Embed or Reference?

Model for the queries you will run, not for the tidiest normal form.

CRUD

// create
db.students.insertOne({ name: "Parham", id: "9231058" });
db.students.insertMany([{ name: "Ali" }, { name: "Sara" }]);

// read
db.students.find({ name: "Parham" });
db.students.findOne({ id: "9231058" });

// update
db.students.updateOne({ id: "9231058" }, { $set: { name: "Parham Alvani" } });

// delete
db.students.deleteOne({ id: "9231058" });
    

Aggregation Pipeline

Documents flow through stages, each one transforming the stream.

// keep the big courses, count them per teacher, busiest first
db.courses.aggregate([
  { $match: { capacity: { $gt: 20 } } },
  { $group: { _id: "$teacher", total: { $sum: 1 } } },
  { $sort: { total: -1 } },
]);
    

Aggregation Pipeline (Cont.)

Transactions

• A single document write is atomic, which covers most cases if you embed well
• Multi-document ACID transactions exist since MongoDB 4.0
• They cost more than in a relational database, so they are a tool rather than a default

Mongoose

• An ODM for Node.js: schemas, validation, and models over the driver
• Puts the schema back, in the application layer

const studentSchema = new mongoose.Schema({
  name: { type: String, required: true },
  id: { type: String, unique: true },
});

const Student = mongoose.model("Student", studentSchema);