A refresher – what’s NoSQL?
Although their marketing has moved away from the NoSQL moniker in recent years, the key to understanding MongoDB – and why they had such a major impact on the ecosystem – is to understand NoSQL.
If you haven’t yet, check out the Technically posts on relational databases and then NoSQL. This section will jog your memory, but to go in depth you’ll want to read these bad boys.
For most of technical history, apps were powered by relational databases. A relational database is all about structure – before you put any data into it, you plan out what your data is going to look like. What are my column names going to be? How will my tables relate to each other? What type of data will each column store? All of that information together is called a schema, and it’s the sine a qua non of relational data. You’ll usually hear relational databases referred to as SQL databases.
(By the way, SQL stands for Structured Query Language, and it’s a category of mini-programming languages that people use to get data in and out of these databases. Rigid structure means that querying data is easy and straightforward.)
NoSQL, on the other hand, is exactly what you think it is – unstructured. Instead of rigidly defining what your data looks like before storing it, you just kind of throw it in there and worry about it later. Querying it is more difficult, but it’s a lot easier to scale horizontally to multiple servers. Here’s a quick snapshot of how these storage patterns differ:
The thing about NoSQL is that those two people (Justin and Selin) don’t even need to have the same attributes. Justin can have a “favorite food” value, while Selin has a “hair color” one. In SQL, if one record has a column, all records in the table need to have that same column. You can imagine how that flexibility that NoSQL offers is convenient – but it also means that down the road, you have less predictability around .
There are all different kinds of NoSQL databases – key value stores, wide column stores, etc. The most popular type, though, is called a document store, and it’s the core of how MongoDB works. The canonical “unit” – the main thing at play – is a document, which is just a collection of different keys and values. Here’s a document that represents my band:
{
guitar_players: {
justin_gage: {
height: 5"3,
weight: "wouldn't you like to know"
},
jake_mendel: {
height: 5"11,
weight: 170,
axe: “mary kaye”
}
},
drum_players: {
chris_behrens: {
height: 6"0,
weight: 185,
cymbal: “zildjian”
}
}
}
Each entry has a key (what does this data mean?) and a value (the actual data). For Jake, height is a key, and 5”11 is a value. At a higher level, guitar_players is a key, and the entire entries for both Justin and Jake are the values. Notice how there’s really no structure at all to this – values and keys can be anything, data types don’t need to match, etc. This is the double edged sword of NoSQL.
