For years, database administrators have relied on scale up — buying bigger servers as database load increases — rather than scale out — distributing the database across multiple hosts as load increases. However, as transaction rates and availability requirements increase, and as databases move into the cloud or onto virtualized environments, the economic advantages of scaling out on commodity hardware become irresistible.
RDBMS might not scale out easily on commodity clusters, but the new breed of NoSQL databases are designed to expand transparently to take advantage of new nodes, and they’re usually designed with low-cost commodity hardware in mind.
Just as transaction rates have grown out of recognition over the last decade, the volumes of data that are being stored also have increased massively. O’Reilly has cleverly called this the “industrial revolution of data.” RDBMS capacity has been growing to match these increases, but as with transaction rates, the constraints of data volumes that can be practically managed by a single RDBMS are becoming intolerable for some enterprises. Today, the volumes of “big data” that can be handled by NoSQL systems, such as Hadoop, outstrip what can be handled by the biggest RDBMS.
Relational database has only one type that is SQL database and it require to define the schema of database before you can add data. Like, if you are storing catalog information then you will have to add the product name, description, price etc. So you must have to add a table products and then fields product_ name, description and price in table. This approach create a problem in Agile methodology, Lets say you received a new request which need an alteration in a table so you would alter the table and then will migrate the database to the new schema. Changing in the database might cause significant downtime if database is large and it become more critical if you frequently make change in database.
NoSql databases allow the insertion of data without a predefined schema. That makes it easy to make changes in real-time, without worrying about service interruptions so less database administration required.
NoSQL databases typically use clusters of cheap commodity servers to manage the exploding data and transaction volumes, while RDBMS tends to rely on expensive proprietary servers and storage systems. The result is that the cost per gigabyte or transaction/second for NoSQL can be many times less than the cost for RDBMS, allowing you to store and process more data at a much lower price point.
Change management is a big headache for large production RDBMS. Even minor changes to the data model of an RDBMS have to be carefully managed and may necessitate downtime or reduced service levels.
Tab contentThere are many third party tools which support the caching for relational database which increase the performance substantially but that add the complexity of deployment. There are many NoSql databases which have excellent caching capabilities. It keeps frequently used data in system memory as much as possible. This approach remove the need to have the third party tool for caching.
Usually Relational database scale vertically – a single server host the complete database. This gets expensive quickly, places limits on scale, and creates a relatively small number of failure points for database infrastructure. The solution is to scale horizontally, by adding servers instead of concentrating more capacity in a single server. Sharding(scale horizontal) can be achieved in relational database but it require a complex arrangement for making hardware act as a single server. Because relational database does not provide this ability natively.
NoSQL databases, on the other hand, usually support auto-sharding, meaning that they natively and automatically spread data across an arbitrary number of servers, without requiring any other application.