Types and Examples of NoSQL Databases
NoSQL databases are growing with very rapid speed because of their exciting features like more flexibility and scalability, schema-free architecture, easy replication support, simple API, consistent / BASE (not ACID), support for big data and more.
What is NoSQL database?
NoSQL is a non-relational DBMS, that does not require a fixed schema, avoids joins, and is easy to scale. The purpose of using a NoSQL database is for distributed data stores with humongous data storage needs. NoSQL is used for Big data and real-time web apps. For example, companies like Twitter, Facebook, Google collect terabytes of user data every single day.
What is NoSQL?
When people use the term “NoSQL database”, they typically use it to refer to any non-relational database. Some say the term “NoSQL” stands for “non SQL” while others say it stands for “not only SQL.” Either way, most agree that NoSQL databases are databases that store data in a format other than relational tables.
The popularity of NoSQL has been driven by the following reasons:
- The pace of development with NoSQL databases can be much faster than with a SQL database.
- The structure of many different forms of data is more easily handled and evolved with a NoSQL database.
- The amount of data in many applications cannot be served affordably by a SQL database.
- The scale of traffic and need for zero downtime cannot be handled by SQL.
- New application paradigms can be more easily supported.
NoSQL databases deliver these benefits in different ways.
Here are the four main types of NoSQL databases:
- Key-value stores
- Column-oriented databases
- Document databases
- Graph databases
MongoDB, CouchDB, CouchBase , Amazon SimpleDB, Riak, Lotus Notes are document-oriented NoSQL databases,.
Tokyo Cabinet/Tyrant, Redis, Riak, Voldemort, Oracle BDB, Amazon SimpleDB are key-value stores
Cassandra, HBase and Hypertable are column family stores
Neo4J, InfoGrid, Infinite Graph, OrientDB, FlockDB are graph databases. Lets discuss these types of databases in detail.
1. Key-Values Stores
The main idea here is using a hash table where there is a unique key and a pointer to a particular item of data. The Key/Value model is the simplest and easiest to implement. But it is inefficient when you are only interested in querying or updating part of a value, among other disadvantages.
Key-value pair storage databases store data as a hash table where each key is unique, and the value can be a JSON, BLOB(Binary Large Objects), string, etc.
Key-value stores store everything as a key and a value.
The value in a key-value store can be anything: a string, a number, but also an entirely new set of key-value pairs encapsulated in an object. Figure 6 shows a slightly more complex key-value structure.
Examples: Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB, Amazon SimpleDB, Riak
Key-value nested structure.
2. Column Family Stores
These were created to store and process very large amounts of data distributed over many machines. There are still keys but they point to multiple columns. The columns are arranged by column family.
They deliver high performance on aggregation queries like SUM, COUNT, AVG, MIN, etc. as the data is readily available in a column.
Column-based NoSQL databases are widely used to manage data warehouses, business intelligence, CRM, Library card catalogs.
Examples: Cassandra, HBase, Hypertable
3. Document Databases
These were inspired by Lotus Notes and are similar to key-value stores. The model is basically versioned documents that are collections of other key-value collections. The semi-structured documents are stored in formats like JSON. Document databases are essentially the next level of Key/value, allowing nested values associated with each key. Document databases support querying more efficiently.
Newspapers or magazines, for example, contain articles. To store these in a relational database, you need to chop them up first: the article text goes in one table, the author and all the information about the author in another, and comments on the article when published on a website go in yet another. As shown below, a newspaper article can also be stored as a single entity; this lowers the cognitive burden of working with the data for those used to seeing articles all the time.
Examples: CouchDB, MongoDb, Amazon SimpleDB, Riak, Lotus Notes
4. Graph Databases
Instead of tables of rows and columns and the rigid structure of SQL, a flexible graph model is used which, again, can scale across multiple machines. NoSQL databases do not provide a high-level declarative query language like SQL to avoid overtime in processing. Rather, querying these databases is data-model specific. Many of the NoSQL platforms allow for RESTful interfaces to the data, while other offer query APIs.
Compared to a relational database where tables are loosely connected, a Graph database is a multi-relational in nature. Traversing relationships as fast as they are already captured into the DB, and there is no need to calculate them.
Graph base databases mostly used for social networks, logistics, spatial data.
Examples: Neo4J, InfoGrid, Infinite Graph, OrientDB, FlockDB