Introduction
Despite the traditional relational DB world, there’s also a trend for NoSQL. The NoSQL databases that enable storing unstructured and heterogeneous data. The scalability features have risen it’s popularity to a greater extent in the current market. Horizontal scaling leads the organization to not to worry about the underlying infrastructure. Conceptually, data is stored in JSON files. In fact, SQL 2016 has a feature to support JSON queries, just like a support for XML. The data to scale out naturally took an advantage of NoSQL scale characteristics than relational DB’s.
Many of us only know about SQL to be the oldest DBs we have, and it would be surprising for you to know that NoSQL existed before SQL’s usage exploded in the 1990s. NoSQL is as old as 1960’s; however, they have gained popularity lately with the eruption of several options like MongoDB, Cassandra, and HBase.It’s really hard to define NoSQL. You will get a lot of information, opinions on what NoSQL is all about. This is just my understanding and experience on NoSQL.
NoSQL is a definitely different from relational databases. NoSQL is often used to refer to data management systems that are “Not SQL” or an approach to data management that includes “Not only SQL”. There are a number of technologies in the NoSQL category, including document databases, key-value stores, column family stores, and graph databases, which are popular with gaming, social, and IoT apps. NoSQL, the Non-Relational DB is classified under Key-Value pair, Document Oriented type, Column family, and Graph.
It’s all about
- Non-relational
- Open source
- Cluster-friendly
- Schema-Independent
- No Join
- Heterogeneous
- Humongous Volume of data
- Easy Development
- Easy Administration
and other factors such as license cost, business process, organization decision plays a major role in opting for the brand of NoSQL but relational DB’s are still very good for various scenarios and answers all our long lasting questions.
Many of us only know about SQL to be the oldest DBs we have, and it would be surprising for you to know that NoSQL existed before SQL’s usage exploded in the 1990s. NoSQL is as old as 1960’s; however, they have gained popularity lately with the eruption of several options like MongoDB, Cassandra, and HBase. The choice does not depend on the benefits and disadvantages of these database systems, rather it’s the type of web applications you deal with and the results you expect from a query system.
NoSQL, without ACID it is very difficult to write reliable software though it follows CAP theorem , it is clear that without ACID, the developers have to spend a significant fraction of their time building extremely complex and error-prone systems. Also, this totally depends on the business decision and use cases. There is a lot of new development and research is taking place to come out with stable NoSQL products.
There is always Pros and Cons while choosing the database product but it’s all driven by the business case, the cost and a decision to be made at the management level. There is a new mindset in many organization to try and go for NoSQL products, thinking of lower expense and maintenance overhead. Most of the time only project life cycle phase may give an insight of success or failure of the implementation. If you hear someone saying that NoSQL overpowers SQL and is better, you may end up in making a wrong selection. Remember, none of them supersedes each other and NoSQL is not a replacement to SQL but an alternative to it in some cases.
The problem is that when you had a tremendous amount of data scattered across multiple systems it’s nearly impossible to maintain transaction consistency that satisfies all the ACID properties. But as technology grows and matures the data consistency and integrity can be easily handled. A lot of work is in place to add SQL(Querying) support to query data layer as it gives the flexibility to query and design complex reports. This is the only reason and hard to say it’s a schema-less design as it’s indirectly bound to the schema.
Difference SQL and NoSQL
Database type and product examples
SQL : MSSQL, Oracle, MySQL,Maria, IBM DB2, Sybase, Microsoft Azure and Postgres
NoSQL : MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j, Oracle NoSQL and CouchDb
Types of NoSQL databases
Key-value model
The least complex NoSQL option, which stores data in a schema-less way that consists of indexed keys and values. Examples: Cassandra, Azure, LevelDB, and Riak.
Column store—or, wide-column store
It stores data tables as columns rather than rows. It’s more than just an inverted table—sectioning out columns allows for excellent scalability and high performance. Examples: HBase, BigTable, HyperTable.
Document database
Taking the key-value concept and adding more complexity, each document in this type of database has its own data, and its own unique key, which is used to retrieve it. It’s a great option for storing, retrieving and managing data that’s document-oriented but still somewhat structured. Examples: MongoDB, CouchDB.
Graph database
The data that’s interconnected and best represented as a graph? This method is capable of lots of complexity. Examples: Polyglot, Neo4J.
Summary
The choice of the database between SQL and NoSQL cannot be concluded on the differences between them but the project requirements. If your application has a fixed structure and doesn’t need frequent modifications, SQL is a preferable database. Conversely, if you have applications where data is changing frequently and growing rapidly like in Big Data Analytics, NoSQL is the best option for you. And remember, SQL is not deceased and can never be superseded by NoSQL or any other database technology.
Conclusion
All the technologies are best in what they do. It is up to the Architect/Developer/DBA to make a better use of them depending on the situations and needs.
References
Further Reading
