0% completed
Introduction to NoSQL
On This Page
History of NoSQL
What NoSQL Databases Change
What NoSQL Costs
When to Use NoSQL
Key Takeaways
A relational database stores data in tables. Every table has a defined set of columns, every row fills in those columns, and you read and change the rows with a language called SQL. Databases that store data in other forms, such as key-value pairs, documents, or graphs, are grouped under the name NoSQL.
The name is now often read as "Not Only SQL". It describes what these databases are not, and it does not describe one shared design. Some NoSQL databases even offer a query language that resembles SQL, so the real difference is the way they model and store data.
Consider a user named John Doe with the email address john.doe@example.com and two phone numbers, 555-0110 and 555-0111. A relational design normally stores John in a users table and his phone numbers in a separate phones table, because one column holds one value. A NoSQL document database can store John and both numbers together as a single record. The picture at the top of this lesson shows both designs side by side. The rest of this chapter returns to John whenever a difference needs a concrete example.
History of NoSQL
Non-relational databases are much older than the name NoSQL. Hierarchical and network databases, which connected records in trees and linked structures, were in use from the late 1960s, before relational systems became the standard way to store business data.
The word itself appeared much later. In 1998, Carlo Strozzi used "NoSQL" as the name of his own lightweight database, which was still relational but did not offer SQL.
The modern meaning came from large web companies. As their traffic grew, they built systems that spread data across many machines, and three of those systems became widely known: Bigtable at Google, Dynamo at Amazon, and Cassandra at Facebook. In 2009, Johan Oskarsson of Last.fm organized an event about open-source, distributed, non-relational databases and used "NoSQL" as its name. The word then became the common label for this group of systems.
What NoSQL Databases Change
NoSQL databases differ from one another, but most of them make the same four design choices.
The structure of a record is more flexible. In a relational table, every row has the same columns, and adding a column means changing the table's schema, which is its declared structure. In many NoSQL databases, John's record can have a phones list while the next user's record has no such field. People often call this "schema-less", but that word is misleading, because the application still expects a certain structure. Many NoSQL databases can also enforce rules on that structure when you ask them to, and MongoDB does this through schema validation.
Capacity grows by adding machines. There are two ways to give a database more capacity. Vertical scaling moves it to one larger machine, which is simple but has a limit, because the largest available machine has a fixed capacity. Horizontal scaling divides the data across several machines, so you add capacity by adding machines. Many NoSQL databases were designed for horizontal scaling from the start.
Notice what the application has to know in each case. With one large server, every request goes to the same place. With several servers, something must decide which server contains John's record, and that extra work is the source of much of the complexity described below.
Copies of the data keep it available. Most NoSQL databases store copies of the data on several machines, so the data can still be read when one machine fails. This reduces the chance of an outage, but it does not remove it. Depending on the database, requests can fail or wait for a short time while the system recovers from the failure.
The data model can match the workload. The main models are key-value, document, column-family, and graph, and each one makes a different kind of request fast.
What NoSQL Costs
These design choices also have costs, and the costs depend on the product.
Copies can disagree for a short time. Suppose John changes his email address and the change reaches one copy before the others. A read from a copy that has not received the change returns the old address. A system that allows this, on the promise that all copies will eventually match, is called eventually consistent. Some NoSQL databases accept this in exchange for staying available during network failures, others let you choose per request, and others do not behave this way by default. You must check the behavior of the specific product instead of assuming it from the NoSQL label.
Some products have weaker guarantees for grouped changes. Relational databases have long offered ACID transactions. A transaction is a group of changes that the database treats as one unit, and ACID names four guarantees about it:
- Atomicity: either all of the changes happen, or none of them do.
- Consistency: the changes leave the data obeying the rules that the database enforces.
- Isolation: transactions running at the same time do not see one another's unfinished changes.
- Durability: once a transaction is confirmed, its changes survive a server restart or crash.
Some NoSQL databases offer these guarantees only for a single record, or not at all. Others, including MongoDB, support ACID transactions across multiple records. Query features vary in the same way, and some products cannot combine data from two sets of records in one query.
There is no standard query language. SQL works, with some differences, across relational databases. Each NoSQL database generally has its own language or API, so moving to another product can mean rewriting your queries and redesigning your data.
A distributed system is harder to operate. A cluster, which is a group of machines working as one database, has more machines that can fail, and you have to plan how data is divided among them. Vertical scaling is easier to manage for this reason. Horizontal scaling becomes the better option when one machine can no longer handle the work, or when a larger machine costs more than several smaller ones.
Speed depends on the design. A NoSQL database can be very fast for the requests its data model was designed around, such as fetching John's record by its unique identifier. The same database can be slow for a request that it was not designed around, such as a report that combines many kinds of records.
When to Use NoSQL
A NoSQL database is worth considering in these situations:
- Large data sets: the data or traffic is too large for one machine, as in big data applications.
- Fast web applications: most requests read or write one record, or a small group of records, by a known identifier, as in social media and online gaming.
- Changing structure: records vary in shape or change often, as in a content management system.
- Device data: many devices send a constant stream of small records, as in Internet of Things (IoT) applications.
A relational database is often the better first choice when your data has many relationships, when you need flexible reports across those relationships, or when your data is small enough for one server. Online stores show why the choice is not always simple, because a product catalog with varied attributes suits a document database, while orders and payments require strong transaction guarantees. NoSQL databases do not replace relational databases, and many systems use both.
Key Takeaways
- NoSQL names a group of databases with different data models. It does not name one design or one set of guarantees.
- Horizontal scaling adds capacity by adding machines, and the cost is a system that is harder to operate.
- Consistency and transaction support vary by product, so a claim about "NoSQL" in general may be false for a specific database.
Reading Progress
0%
On This Page
History of NoSQL
What NoSQL Databases Change
What NoSQL Costs
When to Use NoSQL
Key Takeaways