What does NoSQL mean?
Not your grandfather’s database…
For decades the dominant model for web application databases was the relational model with relational databases. They are queried with SQL (Structured Query Language). This included databases such as Oracle, DB2, SQL Server, MySQL, and PostgreSQL.
In the late 2000’s however different database models began to be adopted and frequently used. The term “NoSQL” (Not Only Structured Query Language) was coined and essentially means any non-relational database.
There are different types of NoSQL databases available for developers to use such as “Key-value”, “Document”, “In-memory” and “Graph” just to name a few. They all differ from relational databases in their own unique ways. Which one to use is a matter of what you plan on doing with your data and how you expect your application to scale.
Standard relational databases are the kind of database that many developers are used to working with. The database contains tables that store data and are organized into columns. It provides a powerful query language (SQL) that allows programmers to do from simple to complicated queries with that data.
This standard consistency also makes relational databases rigid stores of data. Where as NoSQL databases are specifically for applications that require large data volume, and flexible data models, which is achieved by relaxing some of the data consistency restrictions. Let’s look at an example:
Let’s model a schema for a database of books.
In a relational database a book record would be stored in seperate tables and the relationships would be defined by their primary/foreign keys. First you would have to model the objects. A books table would have columns for things like a book_id, title, genre. An Author table would have columns for an author_id and name. And an AuthorBooks table would have columns for author_id and book_id. The relational model reinforces the validity of the data between the tables and the database.
A NoSQL document database like MongoDB does away with any kind of “join table”. We could store our book record, in a “document” database. The document name comes from how the database stores data. A book record similar to above is stored as a JSON document, and rather than stored in separate tables, they are instead stored as attributes in a single JSON document.
Querying the document can then be done programmatically in the language that you’re writing your application in rather than using SQL
So why should you use NoSQL databases? NoSQL databases generally provide flexible schemas that allow faster and more iterative development. The flexible data model makes NoSQL databases ideal for data that requires little to no structure. They’re scalable, designed to scale out by using distributed clusters of hardware instead of adding more expensive and powerful servers. Some cloud service providers even handle this these operations behind-the-scenes for you. NoSQL databases are also super functional by providing APIs and data types that are purpose built for each of their respective data models.
There are downsides to using NoSQL databases as well. Namely, the lack of maturity which also leads to lack of standardization. Relational databases conform to SQL and are able to provide more consistent and reliable performance at the expense of scalability and flexibility. Because of its age, there are more tools available for your typical relational database than a NoSQL database.
It’s important to consider all the pros and cons to SQL vs. NoSQL databases before using one as migrating over later on as your application matures can be an expensive and time consuming process.