18. Document databases and MongoDB

18.01 Introduction

Key-value databases can be seen as being on the opposite end of the spectrum from relational databases.

They have a specific application. While the model doesn’t work for all types of applications, they enable easier distribution of data and processing.

Is there any kind of middle ground between Relational Databases and Key/Value Databases? Yes, and that middle-ground is covered by Document Databases.

18.02 Document Databases

These database structures:

• are less strict
• can be nested
• can be repeated
• can be order-sensitive

There is an expectation that documents have less interlinking among them, or at least that interlinking is less important for that data retrieval.

Some of the document formats in existence:

• Markup languages for text
• Markup languages for other data
• Bespoke formats
• JSON

The JavaScript Objection Notation (JSON) language is useful for data persistence and data exchange. It’s very similar to JavaScript itself with a few caveats.

MongoDB is one implementation of a Document Database. It’s also capable of distributing the by means of sharding – taking horizontal partitions of the data – and it’s also open source(-ish).

18.03 JSON

JSON is JavaScript Object Notation. It’s useful for data persistance (serialistaion) and data exchange.

There are no variables in JSON but otherwise it’s very similar to JavaScript. eg if we have an object in JS like this:

const movieObject = {
    title: "Ant-Man",
    year: 2015,
    Actors: [ "Michael Douglas",
              "Paul Rudd",
              "Evangeline Lily" ]
};

This would translate into JSON like this:

{
    title: "Ant-Man",
    year: 2015,
    Actors: [ "Michael Douglas",
              "Paul Rudd",
              "Evangeline Lily" ]
}

18.04 MongoDB

MongoDB is fairly SQL-like, reduces the use of joins and has a tree-like data structure.

It also integrates well into code.

Disadvantages include that is has suffered security and reliability issues.

A quick example of using MongoDB.

Say we have an array of movies like this:

movieData = [{
    title: "Ant-Man",
    year: 2015,
    actors: [ "Michael Douglas",
              "Paul Rudd",
              "Evangeline Lily" ]},
    {title: ...}, 
    {title: ...}, ...];

If we want to populate a MongoDB database we would do this:

db.movies.insert(movieData);

To SELECT a movie we use the keyword find:

db.movies.find({year: 2015});

We can use regular expressions, so if we want to find all movies ending in “Man” we can do this:

db.movies.find({
  title: /*Man/
});

And if we want to also find movies before 2010 we can use dollar expressions such as $lt:

db.movies.find({
  title: /*Man/,
  year: {$lt: 2010}
});

To UPDATE in MySQL, we use a WHERE clause to find the data and then a SET clause to change it.

MongoDB divides these very explicitly. So the first argument is the WHERE and the second is the SET. Syntax is like this to change the year of Ant-Man to 2015:

db.movies.update (
    {title: "Ant-Man"},
    {$set: {year: 2015}}
);

To update many records we can use updateMany, like this:

db.movies.updateMany(
    {actors: "Ellen Page"},
    {"actors.$": "Elliot Page"}
);

In a relationship database we wouldn’t need to update many records, because we would have normalised it and would only need to change one record.

In a document database we’re much more likely to have to update many records if we need to make a change like this.

If we want to add an actor to a film we can use $push like this:

db.movies.update (
    {title: "Ant-Man"},
    {$push: {actors: "Michael Pena"}}
);

Wednesday 12 January 2022, 546 views

Next post: 19. Semantic databases
Previous post: 17. Key/Value databases and MapReduce