MongoDB for Jobseekers: Reach new heights in your career with MongoDB (English Edition)

By Justin Jenkins

MongoDB for Jobseekers serves as the ultimate companion, providing assistance and support throughout your entire MongoDB learning journey. Whether you are an experienced professional exploring new career paths or an aspiring jobseeker looking to enhance your opportunities, this comprehensive guide is specifically designed to cater to your needs.

From the basics to advanced concepts, MongoDB for Jobseekers offers a well-structured approach to understanding the intricacies of this powerful NoSQL database. The book then delves into subjects like schema modeling, querying, indexing, and scalability, and discovers the reasons behind MongoDB's widespread popularity. Through clear and practical examples, the book will swiftly help you grasp the fundamental concepts and techniques required to work with MongoDB in real-life scenarios. This extensive guide will not only help establish a strong foundation in MongoDB but also unlock numerous job opportunities.

Upon completing this book, you will acquire the necessary confidence and expertise to excel in your job search and embark on a rewarding career path.

• Language: English
• Publisher: BPB Online LLP
• Release date: Jun 7, 2023
• ISBN: 9789355518316

Book preview

Chapter 1

Why MongoDB?

Introduction

Many people love to cook. But do not worry; this is not a book about cooking. We are bringing up food to whet your appetite a little and maybe even illustrate how you are probably using a lot of the concepts we will learn about here, in your everyday lives.

If you are picking up this book, you probably have some idea of what MongoDB is or you might have heard that learning it will help you along in your career. Maybe you just really want to know more: Why should I learn MongoDB; you might be asking?

MongoDB is a powerful, fast, and modern database that was designed for modern applications. From its flexible Document Model (for data), JavaScript based query language, blazing speed, advanced replication and scaling, simple redundancy, advanced aggregation framework, and hooks into the wider MongoDB Atlas Cloud ecosystem, it just might be a clear choice for your next project (or even an existing one)!

Through real life examples and analogies (like cooking), we are going to learn all about MongoDB and its concepts, its associated technologies and how those concepts might apply to the next step in your career.

Hopefully, you are hungry to learn some more. Let us get started.

Structure

In this chapter, we will discuss the following topics:

Recipes as data

The history of data

Databases of Data

Computer Databases

Relational Databases

Bringing Separate Data Together

Data that goes together, can live together

Thinking of data differently

This is why MongoDB…

Objectives

By the end of this chapter, you will have a basic idea of the history of data and databases, how different types of databases work and how MongoDB differs with a newer, modern way to store and interact with data.

Recipes as Data

We all need food and good food that is cooked well, is appreciated throughout the world and across cultures. Food (and cooking it) can sometimes be subjective and complex, yet somehow simple (at its best), at the same time.

What your favourite meals do have in common is some form of structure: there are important details about what ingredients you need (their measurements, units, and so on). There are precise steps to follow, specific temperatures as well as cooking techniques needed, to successfully make the dish. Figure 1.1 is an example of an old recipe:

Figure%201.1.png

Figure 1.1: Century Old Chocolate Chip Cookie Recipe (Public Domain)

In essence, these instructions are an orderly set of data which we simply call a recipe. We compile it into a document, which in turn is sometimes gathered into a collection of documents. In simple English, it is called a Cookbook or a Recipe Book.

Switching to a more modern example; what if you wanted a recipe for dinner? You have about half an hour and all you have in your refrigerator, is a chicken. So, you ask the voice assistant on your phone:

Find me recipes for chicken that I can cook in 30 minutes or less.

That might seem like a simple statement but (going with our theme here) there is a lot of information packed into this short sentence. Let us break it out a bit, and see how we might turn this spoken request into a database query:

Find me recipes for chicken

Starting off, this has the makings of a good query. The user wants us to find a particular thing: a recipe. To make this simple, we will query for recipes literally titled Chicken. Now, in reality, we would probably do some sort of wildcard search for recipes with the word chicken in the title, or more likely also as one of the ingredients.

… that I can cook in 30 minutes

This is a little more complicated. Do they mean the actual time to cook the recipe is 30 minutes? Or do they mean cooking time plus the preparation time? Given the context here, we will assume that they mean the combination of both. Also, this would mean 30 minutes or less, as in less than or equal to.

Find me a recipe query

Here is how we might construct this as a query in MongoDB:

db.recipes.find( { title : Chicken, total_time : { $lte: 30 } } );

We will gain more information about how querying works and how to compose queries in future chapters. For now, you can see we are looking for a match on the title field and doing our less than or equal to on a total_time field. It might look a little funny right now, but the $lte means less than or equal to 30 and it is called a Query Operator (they start with a $). We will learn more about them soon.

Put back into English, it translates to: Find me recipes where the title is Chicken, and the total time to make it is less than or equal to 30 minutes.

With MongoDB, we will search our recipes, which are stored in Documents (more on that in Chapter 4, A Better Way to Store Data – Documents) within a Collection here called recipes (more on that in Chapter 9, Planning for Performance – Collections and Indexes) by using the find method. Given this method of storing data, MongoDB is commonly referred to as a Document Database.

Before we go much further, let us step back for a moment and delve a little into the history of data and databases.

The history of data

There are many types of databases, and the concept of a computer database has been around for almost as long as (electronic) computers themselves. However, data is not a new or even modern concept. Humans may have only had computers for a couple decades, but data (and even forms of databases) have been around for millennia.

Databases of clay

The first computer database is generally credited to Charles Bachman in the 1960s while working for IBM. However, the general concept itself goes back thousands of years. Data has always been a powerful asset and being able to store it reliably and easily (for later use) has been a major factor in the success of various successful individuals, companies, cities, and empires.

Across time, empires and countries have used data to help them maintain and manage their control from a high level, down to a personal level. Unfortunately, since these records were often stored on various forms of paper, most of them were lost over time.

It is difficult to know how far back the concept of data goes, but amazingly, we have actual records of data going back for more than a thousand years, thanks to an ancient form of database technology. By writing on tablets of soft clay (which could then be dried in the sun or hardened in a furnace), ancient peoples across the East were able store all sorts of important (or even trivial) information. Figure 1.2 is an example of such a clay tablet:

Figure%201.2.png

Figure 1.2: Clay Tablet with Cuneiform Writing

Archeologists have found thousands and thousands of these tablets buried in the sand all over the Middle East and Asia; apparently, ancient people loved their data! Interestingly, after paleographers were able to decode and translate these ancient tablets (which were mostly written in script called cuneiform that can compose multiple different languages), they found many of these documents contained data we might keep in a database today.

These tablets stored things like the records of a household’s property, and how it was to be distributed in the event of the head of the household dying (what we might refer to as a last will and testament) or tallies of food stores: Ikup-pi-Adad has 5 bushels of grain, three oxen and 8 jars of fat.

There were also tax bills, financial exchanges, letters, contracts, military dispatches, historical documents, poetry, and vast inventories of store cities, containing anything from food to textiles, precious metals, chariots, and horses which the king, queen and their advisors used to maintain their kingdom with. And of course, they also had recipes. All sorts of recipes have been found; 4,000-year-old instructions pressed into tablets for preparing meals not unlike we might eat today, and even recipes for beer!

Computer Databases

With the advent of modern computers, data once again became something we needed a way to manage, electronically this time.

The earliest databases stored their data in a hierarchical fashion, meaning every piece of data had a parent, starting with a root record. This might be thought of like a family tree, or a organizational chart for a company. It starts with a root record that has multiple child nodes, which have one or more nodes themselves and so on, to build out a hierarchy. You can find the data you need by navigating along the tree until you land on the data you need.

For example, if you needed to find the Database Administrator at a company, you would start at the top with the CEO (or perhaps Founder) at the root and then travel from record to record via the tree: CEO | VP of Engineering | Director of Engineering | Technical Manager | Database Administrator

Each time you want to find the Database Administrator, you would need to follow this path of parent/child links (or perhaps another one, depending on how complicated the structure was, this is just a simple example). Figure 1.3 is an example of a hierarchical database:

Figure%201.3.png

Figure 1.3: Example of Hierarchical Database

Pretty soon, database architects found that this method of storing data had a lot of drawbacks. For one, making a single change to your database structure may require you to change many or all your records and how they were associated to each other.

Additionally, given the hierarchical relationships, it is nearly impossible to avoid duplicate data and indexing is also rather difficult, leading to generally bad performance.

Relational databases

To solve many of these issues, the concept of a relational database was proposed by E. F. Codd in the 1970s. In short, this type of database is concerned with how the data records relate to each other, instead of a single parent/child type relationship. Generally, these records are stored in tables which have rows and columns like a spreadsheet. And tables which group together records that have the structure or schema.

Since a Relational Databases’ data is no longer hierarchical, there is no simple way to navigate to the data you might need. To solve this, a structured language to query the data was formed, called (appropriately enough) the Structured Query Language (SQL).

This querying language was later standardized in the 1980s and is still used in many databases to this day, such as Oracle, Microsoft SQL Server, MySQL, and its variants. In fact, Relational Databases and SQL have gone on to have a major impact on the modern history of computing, and the internet in general.

Relational Databases vs Document Databases

To illustrate the basic differences between a Relational Database and a Document Database, let us use the example of a sports league, as in football (or soccer, if you will), baseball, basketball, or cricket. A typical sports league will have players as well as teams, stadiums, games (or matches), and a schedule.

In a Relational Database, we could store each of these in their own tables, for example, take the players and teams, as shown in Table 1.1 and Table 1.2:

Table 1.1: Example of Players Table

Refer to Table 1.2:

Table 1.2: Example of Teams Table

The relations come in when we associate or link two distinct types of data. Here, each team will have many players, but a player will only have a single team. Figure 1.4 shows an example of the relationships between players and teams:

Figure%201.4.png

Figure 1.4: Example of Relationships Between Players and Teams

There are other relationships too. The teams have games which link two teams together; those games are stored in a schedule and played in different stadiums.

To query this relational data, we will use a SQL query. For example, to get the names of all the players we might write a query like:

SELECT first_name, last_name FROM players;

If we wanted to get all the pieces of data for a player record (or all the columns), we can use the asterisk or * character:

SELECT * FROM players WHERE last_name = 'Dempsy';

This might return the set of data shown in Table 1.3:

Table 1.3: Example of Query for a Player

You can do similar queries for each table to get the information you need. All these pieces of data need to be able to have their own relationships which are separate, but also related to each other. An example of table relationships can be seen in Figure 1.5:

Figure%201.5.png

Figure 1.5: Example of Table Relationships

Bringing separate data together

What about when you need some of the related data returned together? What if we wanted a list of all the players, from both teams that are playing a certain game? In a relational database, we can accomplish these links via what is called join, and so we will add those into our SQL query:

SELECT p.number, p.last_name, t.team_name, g.date, s.stadium

FROM players p

JOIN teams t

ON t.id = p.team_id

JOIN stadiums s

ON s.id = t. stadium_id

JOIN games g

ON g.id = t.team_id

WHERE g.game_id = 12

A query like this will return a result made up of columns and rows for the players playing in game with the id 12, as shown in Table 1.4:

Table 1.4: Example of Game Players Query Result

You will notice that there is a lot of repetition of data here, and it is not ordered (there are ways to ORDER BY in SQL, although not shown here), but it is generally the information we wanted.

There are various ways to join tables. Here, we joined the players table to the teams table based on shared ids. We then joined teams and games tables, and finally filtered by where the game has an id of 12.

If you do not understand fully what is going on here, do not worry! This book is not about SQL or relational databases! The point here is to give a general example for means of comparison. If you are already familiar with Relational Databases and SQL, hopefully you are following along… so how is MongoDB different?

Data that goes together, can live together

With a Document Database, we can take these relations and use them to help us organize our data. We will be covering this in greater detail in the rest of the book, but suffice it to say that we can use the principal of data that goes together, lives together.

Using our sports league example, we could have a couple of Collections in which we can store our teams, players, games, and so on. However, we can also take advantage of the flexibilities that using Documents gives us.

So, we could create a document in our teams Collection that looks like this:

{

_id: {

$oid: 6323a3975c80e800b1c46d07

},

team: England,

rank: 5,

stadium: {

name: Wembley Stadium,

capacity: 90000

},

players: [

{

number: 7,

last_name: Saka,

first_name: Bukayo,

goals: 12

},

{

number: 10,

last_name: Kane,

first_name: Harry,

goals: 41

}

],

schedule: [

{

type: game,

date: {

$date: 2023-05-18T16:00:00Z

},

opponent: Faroe Islands,

location: Tórsvøllur,

score: {

for: 8,

against: 1

}

},

{

type: scrimmage,

date: {

$date: 2023-05-24T16:00:00Z

},

opponent: Team B,

location: Old Trafford

}

]

}

If you are feeling overwhelmed, do not worry. We are going to explain each part of this Document below, as well as in the coming chapters. However, the main take away is that we have stored a lot of the data about the team together in a single team Document.

We can do this because Documents are a lot more flexible when it comes to their data (and types of data) than tables are. In fact, we can get a lot more complex than this if we want. In this example, we have demonstrated that we can store strings, numbers, arrays, and objects. If you are familiar with JSON, you might be thinking that this looks a lot like JSON. In fact, you are right. Documents are stored in a binary form of JSON called BSON (binary JSON).

Team document breakdown

To understand things a little bit better, let us break this example Document out field by field:

Team

team: England,

rank: 5,

Here we have two fields: one is a simple string containing the team’s name, and the other a rank field with a number; pretty much like any other database can do.

Stadium

stadium: {

name: Wembley Stadium,

capacity: 90000

},

The stadium field is a little more complex. Here, we have an object which is denoted by the open and closing brackets { … }. Inside this object, we can store pretty much anything we can in our parent Document (more on that later). In fact, this is sometimes referred to as a Subdocument or more simply, a Document inside a Document.

For this example, we have a string field with the stadium’s name, and a number field with the stadium’s capacity.

Players

players: [

{

number: 7,

last_name: Saka,

first_name: Bukayo,

goals: 12

},

{

number: 10,

last_name: Kane,

first_name: Harry,

goals: 41

}

],

Now we are really starting to see the concept of data that goes together, lives together. Instead of storing the players for our team in a separate table (or Document), we are storing the players and their individual information directly within the team Document.

We can do this in an orderly way by using an array, denoted by the [ and ]. Inside this array, we can store numbers, strings, objects, or even more arrays. Here, we are storing each player as an object that lives within the players array.

Schedule

schedule: [

{

type: game,

date: {

$date: 2023-05-18T16:00:00Z

},

opponent: Faroe Islands,

location: Tórsvøllur,

score: {

for: 8,

against: 1

}

},

{

type: scrimmage,

date: {

$date: 2023-05-24T16:00:00Z

},

opponent: Team B,

location: Old Trafford

}

]

Again, we are using an array, but also showing that we can store objects with objects inside them. This is getting a little more complex, so do not worry if you are not quite following yet. We will cover all this in greater detail, in the following chapters.

Thinking of data differently

The Team Document we constructed is just an example; it may or may not make sense for your data (you might want to store each Player in their own Document, with an id for the Team for example; it depends on how you plan to use your data). In fact, one of the even more flexible features of this model is that each Document does not need to have the same fields or schema; you can mix and match and have more, less, or different fields for each Document in a Collection.

Having this flexibility can have a really big impact on how you store and retrieve your data. For example, with this Document, you may be able to code a Team Information page on your web site (that shows team details, stadium information, player rosters, upcoming schedules, and past results) by returning a single Document. That same page may need to make many different database queries (and multiple joins) to return the same data.

This opens a lot of possibilities for storing data differently, more flexibly and more importantly in line with what your application needs. At the same time, it does mean we might need to think a lot differently about how we store our data. We will dig into this more when we cover how to best structure your data in Documents (Chapter 4, A Better Way to Store Data: Documents); for now, it might help to try and visualize some data you already know about and how you might store that in a Document (see Challenge at the end of this chapter).

This is why MongoDB

With the Document model, you can store your data in ways you might have never imagined, or in ways that you would have had to have totally reorganized (or cobbled together) in code, every time it is queried. With MongoDB, we can often store the data exactly how the application needs it.

Beyond this fundamental difference in data architecture, MongoDB is also fast. Depending on your usage, it may be able to handle vastly more queries than a SQL based database. Additionally, it has many unique and powerful ways to query data and perform complex aggregations. When you do need to scale, you can do so easily with built-in replication and data sharding (sharding is the concept of automatically breaking up your data across databases, more on that in Chapter 12, Seamless Scaling: Replication and Sharding).

Conclusion

In this chapter, we learned about the history of data, general types of databases over time and how MongoDB differs from some of these legacy databases. For most of the rest of this book we will be discussing MongoDB specific topics. However, it is important to understand that MongoDB may not be the solution to every situation or database need. In fact, you might even find you will get the best results by mixing types of databases!

All that said, since this is a book aimed at helping jobseekers in the next chapter, we will discuss some of the jobs and roles that learning MongoDB might help you land, or excel in your current role. After that, we will move on to getting started by setting up MongoDB on your local machine, or on MongoDB Atlas Cloud.

This book will also cover topics such as how to create, read, update, and delete Documents, querying, Document structures and schemas, importing/exporting data, programming with MongoDB, Mongo Shell and Compass UI, MongoDB Atlas, serverless programming with Stitch, career paths, interview prep and more!

Challenge – Storing data in a document

How might you store some data you already know about in a Document? Would you use strings, numbers, arrays, objects? Could you have Documents inside your Document? Take a moment to sketch out how you might take advantage of the ability to use Documents! It is okay if it is not perfect, we will cover Documents in a lot more detail in the coming chapters.

Here are some ideas to get you started: