‫Hey, welcome back.
‫Now that we're familiar with the first type of databases,
‫which is the relational databases,
‫let's talk about the second type of databases,
‫which is commonly referred to as non-relational databases
‫or NoSQL databases.
‫We're first going to get an introduction and motivation
‫for using those type of databases.
‫And after that, we'll learn a few categories
‫of non-relational databases
‫for different use cases and purposes.
‫So let's start talking about non-relational databases.
‫Non-relational databases are a relatively new concept
‫which became very popular in the mid-2000s.
‫They mainly came to solve the drawbacks
‫of relational databases, which we saw in an earlier lecture.
‫For example, in a relational database, records that belong
‫to the same table have the same schema,
‫which means they all have the same columns.
‫So if we wanted to add additional data only to some records,
‫we would have to change the schema of the entire table,
‫even though that data makes sense only
‫for a subset of records.
‫So non-relational databases solve exactly that problem.
‫They generally allow to logically group a set of records
‫without forcing all of them to have the same structure.
‫So we can easily add additional attributes
‫to one or multiple records without affecting the rest
‫of the existing records.
‫Another problem we had with relational databases is
‫that essentially, relational databases
‫only support one data structure, which is a table.
‫So while tables are very natural for human beings
‫to analyze records, they are less intuitive
‫for programmers and programming languages.
‫In fact, most programming languages don't even have a table
‫as a data structure.
‫Instead, programming languages support other data structures
‫that are more computer-science oriented,
‫like lists, arrays, maps, and so on.
‫So non-relational databases don't store data in tables,
‫instead, depending on the type of database,
‫they support more native data structures
‫to programming languages.
‫This typically eliminates the need for an ORM
‫to translate the business logic
‫as we store it inside our program
‫to what it looks like inside the relational database.
‫Finally, while relational databases were originally designed
‫for efficient storage, back in the days
‫when the storage used to be expensive,
‫non-relational databases are typically more oriented
‫towards faster queries.
‫And different types
‫of non-relational databases are optimized
‫for different types of queries based on the use case.
‫Of course, everything in software engineering is a trade-off
‫and switching from a relational database
‫to a non-relational database is no exception.
‫When we allow flexible schemas
‫and don't enforce any relationship between records,
‫we lose the ability to easily analyze those records.
‫Because essentially, now each record can have
‫a completely different structure
‫and completely different data.
‫Similarly, analyzing multiple groups
‫of records the same way we used to join tables
‫in a relational database also becomes very hard.
‫Most such operations are either limited
‫or aren't supported at all
‫since each database supports a completely different set
‫of operations and a different set of data structures.
‫Finally, ACID transaction guarantees are
‫also rarely supported by non-relational databases,
‫though there are a few exceptions to this rule.
‫So now that we got familiar
‫with what non-relational databases provide to us
‫and what compromises we have to make to take full advantage
‫of them, let's talk about the three main types
‫of non-relational databases that are commonly used
‫in the industry.
‫As a side note, the boundaries
‫between the different categories are somewhat blurry.
‫So don't be surprised if you see the same database listed
‫under a different category in different sources.
‫The first and simplest type
‫of non-relational databases is a key/value store.
‫In a key/value store, we have a key
‫that uniquely identifies a record and a value
‫that represents the data associated with the record.
‫This value is theoretically completely opaque
‫to the database and can be as simple
‫as an integer or a string, or as complex as an array, a set
‫or even a binary blob.
‫It's easy to think of a key/value store
‫as essentially a large-scale hashtable or dictionary
‫with very few constraints on the type
‫of values we have for each key.
‫Key/value stores are a perfect choice
‫for use cases like counters that multiple services
‫or application instances can read or increment,
‫or for cashing pages or pieces of data
‫that can be easily queried and fetched without the need
‫to do any slow or complex SQL querying
‫from a relational database.
‫The next type of non-relational database
‫is a document store.
‫In a document store, we can store collections of documents
‫with a little bit more structure inside each document.
‫Each document can be thought of as an object
‫with different attributes.
‫And those attributes can be of different types.
‫In a similar way, like a class, can have different fields
‫of different types.
‫So documents inside a document store are
‫much more easily mapped to objects
‫inside a programming language.
‫A few examples
‫of documents can be a JSON object representing a movie,
‫a YAML configuration representing some business logic,
‫or an XML representing a form submitted by a user.
‫The final type of the database is a graph database,
‫which is nothing more than an extension of a document store,
‫but with additional capabilities to link, traverse,
‫and analyze multiple records more efficiently.
‫Those type of databases are particularly optimized
‫for navigating and analyzing relationships
‫between different records in our database.
‫Some of the most popular use cases
‫for graph databases include fraud detection,
‫where multiple logical users may be easily identified
‫as the same person trying
‫to initiate multiple transactions using the same email
‫or the same computer.
‫Recommendation engines, such as the ones used in e-commerce,
‫make extensive use of graph databases
‫to recommend new products to users based
‫on past purchase history of users
‫with similar purchasing patterns
‫or friends of a particular user.
‫So the last question we need to answer is
‫when should we use non-relational databases in our system.
‫While following the same strategy,
‫when deciding on using your relational database,
‫we're going to take the same approach when it comes
‫to choosing a non-relational database.
‫We simply need to analyze our use case
‫and figure out what properties
‫of a database are the most important to us,
‫and which one we can compromise on.
‫Since generally speaking,
‫non-relational databases are superior
‫to relational databases when it comes to query speed,
‫non-relational databases are a perfect choice
‫for things like caching.
‫So we can still have all our data stored efficiently
‫without duplication in our relational database
‫where we can perform complex queries when we need to,
‫but additionally, we can store certain
‫very common query results that correspond to user views
‫in a non-relational database to improve the user experience.
‫In-memory key/value stores are particularly optimized
‫for such use cases.
‫In other cases such as real-time big data
‫where relational databases are just too slow
‫or not scalable enough,
‫we can also use non-relational databases
‫such as document stores.
‫Another perfect use case for a non-relational database is
‫when our data is not structured
‫and different records can contain different attributes.
‫For those cases, non-relational databases
‫like document stores are always a better choice
‫than a relational database.
‫A few examples include user profiles where different users
‫may provide different types of information
‫or content management, where we can have different types
‫of user generated content such as images, comments, videos,
‫and so on.
‫Of course, if we're in neither of those use cases,
‫then choosing a relational database is usually a safer bet
‫due to its simplicity and longterm popularity.
‫In this lecture, we learned about the second type
‫of database, the non-relational database
‫also commonly referred to as a NoSQL database.
‫We'll learn some of the main advantages
‫of non-relational databases such as flexible schemas,
‫fast queries, and more natural data structures
‫for programming languages.
‫After that, we talked about the three main categories
‫of non-relational databases, which are key/value stores,
‫document stores, and graph databases.
‫And finally, we talked about a few considerations
‫for choosing a non-relational database
‫and mentioned a few classic use cases
‫that are particularly suitable for non-relational databases.
‫See you guys in the next lecture.