One of the most fundamental choices to make when developing an application is whether to use a SQL or NoSQL database to store the data. Conventional relational databases are the product of decades of technology evolution, good practice, and real-world stress testing. They are designed for reliable transactions and ad hoc queries, the staples of line of business applications. But they also come burdened with restrictions—such as rigid schema—that make them less suitable for other kinds of apps.
NoSQL databases arose in response to those limitations. NoSQL systems store and manage data in ways that allow for high operational speed and great flexibility on the part of the developers. Unlike SQL databases, many NoSQL databases can be scaled horizontally across hundreds or thousands of servers.
So what is NoSQL?
In essence, NoSQL database is a database that doesn’t use SQL. SQL was designed to be a query language for relational databases and relational databases are usually table-based, much like what you see in a spreadsheet.
In a relational database, records are stored in rows and then the columns represent fields in each row. Then SQL allows you to query within and between tables in that relational database.
-
Many NoSQL databases allow you to define fields as you create a record.
-
Nested values are common in NoSQL databases. (you can have hashes and arrays and objects and then nest more objects, arrays and hashes within those In that way you can have nested values in your NoSQL databases records)
-
Also fields are not standardized between records. You can have a different structure for every record in your NoSQL database.
-
won’t solve website scalability issues out of the box
-
benefits and drawbacks must be weighed
-
offer flexibility unavailable to relational databases
Different types of NoSQL databases
Document store
-
Documents are usually stored in a structured format (XML, JSON etc)
-
Usually organized into “collections” or “databases”
-
Individual documents can have unique structures
-
Each document usually has a specific key. This allows to retrieve the document quickly and normally its possible to query a document by specific fields contained inside
-
It is possible to query a document by fields
- eg: CouchDB, MongoDB, DocumentDB
Key-value store
-
One can query by the key to get the value
- Some-key value stores let you define more than one key
- Sometimes used alongside relational databases for caching and session management in web applications
- Drawback: usually can’t query by anything other than the key
- eg: MemcacheDB, Riak, Redis, BerkeleyDB, Aerospike, Amazon DynamoDB, Azure Table storage
BigTable/tabular/wide-coulmn stores
-
Named after Google’s propietary “BigTable” implementation
-
Each row can have a different set of columns
-
Designed for large number of columns
-
Rows are versioned
- eg: Google BigTable, Cassandra, HBase, Amazon SimpleDB
Graph database
-
designed for data represented as interconnected nodes
-
example: a series of road intersections
- eg: IBM Graph, Neo4J, Titan
Object database
-
Tightly integrated with OOP language
-
Act as a persistence layer: store objects directly
-
Link objects together through pointers
- eg: VersantDB, Objectivity, Gemstone
The basic NoSQL database classifications are only guides. Over time, vendors have mixed and matched elements from different NoSQL database family trees to achieve more generally useful systems. Cassandra has combined key-value elements with a wide-column store and a graph database. Sometimes NoSQL elements are mixed with SQL elements, creating a variety of databases that are referred to as multimodel databases
