For decades Relational database (RDBMS), like SQL, has been dominating the industry as the primary model for database management. However with the rise of social networks and million entry databases, non-relational “NoSQL” databases are gaining prominence as an alternative model for database management.
However the debate is on whether NoSQL database management style is better or not. The rivalry between SQL and NoSQL is already legendary comparable to C,C++, PHP or Python.
Whether ’tis Nobler in thou mind to suffer,
the complexities and confusions of outrageous database Relations,
Or to taketh Arms against a Sea of ID troubles,
And by opposingeth, NoSQLeth them.
NoSQL technology was pioneered by leading internet companies — including Google, Facebook, Amazon, and LinkedIn — to overcome the limitations of a 40-year-old relational database technology for use with modern web applications. Today, small to large scale enterprises alike are implementing NoSQL databases for a growing number of use cases, a choice that is driven by four latest interrelated megatrends: Big Users, Big Data, the Internet of Things, and Cloud Computing.
There are many benefits of NoSQL which I had written in my previous blog. It also talks about using NoSQL for app development and how you should go about implementing it in your organization.
In defense of SQL technology there is only one statement: Tried, tested and fully known. Relational databases, as said earlier, went through trial by fire for a period of 40 years, and survived. It has its own uses but it has its own short comings. Lets look at the few.
NoSQL Vs SQL: The major differences
SQL: Developed in 1970s to deal with first wave of data storage applications
NoSQL: Developed in 2000s to deal with limitations of SQL databases, particularly concerning scale, replication and unstructured data storage
Data Storage Model
SQL: Individual records (e.g., “employees”) are stored as rows in tables, with each column storing a specific piece of data about that record (e.g., “manager,” “date hired,” etc.), much like a spreadsheet. Separate data types are stored in separate tables, and then joined together when more complex queries are executed. For example, “offices” might be stored in one table, and “employees” in another. When a user wants to find the work address of an employee, the database engine joins the “employee” and “office” tables together to get all the information necessary.
NoSQL: Varies based on database type. For example, key-value stores function similarly to SQL databases, but have only two columns (“key” and “value”), with more complex information sometimes stored within the “value” columns. Document databases do away with the table-and-row model altogether, storing all relevant data together in single “document” in JSON, XML, or another format, which can nest values hierarchically.
SQL: Structure and data types are fixed in advance. To store information about a new data item, the entire database must be altered, during which time the database must be taken offline.
NoSQL: Typically dynamic. Records can add new information on the fly, and unlike SQL table rows, dissimilar data can be stored together as necessary. For some databases (e.g., wide-column stores), it is somewhat more challenging to add new fields dynamically.
SQL: Has to be scaled vertically, meaning a single server must be made increasingly powerful in order to deal with increased demand. It is possible to spread SQL databases over many servers, but significant additional engineering is generally required.
NoSQL: Has to be scaled horizontally, meaning that to add capacity, a database administrator can simply add more commodity servers or cloud instances. The database automatically spreads data across servers as necessary.
SQL: Mix of open-source (e.g., Postgres, MySQL) and closed source (e.g., Oracle Database)
NoSQL: It is completely Open-source but enterprise-ready NoSQL solutions are only provided by startups and relatively new companies, and that of course, at a price.
Does it Supports Transactions?
SQL: Yes, updates can be configured to complete entirely or not at all
NoSQL: In certain circumstances and at certain levels (e.g., document level vs. database level)
SQL: Specific language using Select, Insert, and Update statements, e.g. SELECT fields FROM table WHERE… .
Regardless of their licenses, relational databases all implement the SQL standard to a certain degree and thus, they can be queried using the Structured Query Language (SQL).
NoSQL: NoSQL databases, on the other hand, each implement a unique way to work with the data they manage. Therefore data can be manipulated only through your Database solution’s API. These APIs are generally object oriented.
Support and Development difficulty
SQL: Relational database management systems have decade’s long history. They are extremely popular and it is very easy to find both free and paid support. If an issue arises, it is therefore much easier to solve than recently-popular NoSQL databases — especially if said solution is complex in nature.
NoSQL: Open-source versions of NoSQL databases are complex to implement but they give great benefits in long term. At the same time the enterprise ready Database solutions such as MongoDB, are easy to implement and have a large company driven and community driven support behind them.
Limitations of NoSQL
Though NoSQL database has generated a lot of enthusiasm, but there are several obstacles it has to overcome before it becomes appealing to mainstream companies.
NoSQL alternatives and solutions are still in nascent and pre-production stages and many key features are yet to be implemented.
Customer support is also better in RDBMS systems like SQL and vendors provide a higher level of enterprise support. In contrast, NoSQL system support is provided by small start-up companies without the global reach, resources, or credibility of Oracle, Microsoft, or IBM- the big names associated with SQL.
Also NoSQL offer few facilities for ad-hoc query and analysis. It is much easier to code an SQL query, but in NoSQL even a simple query requires significant programming expertise and commonly used BI tools do not provide connectivity to NoSQL.
The Rising Star
NoSQL databases were conceptualized and developed specifically to meet the rising demands of latest Web 2.0 applications and are designed to meet the database handling demands of these applications. Gone are the days when handling the database of million entries was the domain of pricey large scale enterprise level database solutions. A mere startup can now do that, and more efficiently too. However enterprise level implementations are still custom made and latest solutions have to be extended to meet specific requirements, a process which requires considerable technical expertise. But this a trend that plague every new technology. As the field matures we will see better solutions. One is already making waves, MongoDB.