Code Library

A few years ago, web programmers started to use the memcached system to temporarily store data in RAM, so frequently used values could be retrieved very quickly, rather than relying on a slower path accessing the full database from disk. This coding pattern required all of the data accesses to be written using only key/value primitives, initially in addition to the traditional SQL queries on the main database. As developers got more comfortable with the approach, they started to experiment with databases that used a key/value interface for the persistent storage as well as the cache, since they already had to express most of their queries in that form anyway. This is a rare example of the removal of an abstraction layer, since the key/value interface is less expressive and lower-level than a query language like SQL. These systems do require more work from an application developer, but they also offer a lot more flexibility and control over the work the database is performing. The cut-down interface also makes it easier for database developers to create new and experimental systems to try out new solutions to tough requirements like very large-scale, widely distributed data sets or high throughput applications.

This widespread demand for solutions, and the comparative ease of developing new systems, has led to a flowering of new databases. The main thing they have in common is that none of them support the traditional SQL interface, which has led to the movement being dubbed NoSQL. It’s a bit misleading, though, since almost every production environment that they’re used in also has an SQL-based database for anything that requires flexible queries and reliable transactions, and as the products mature, it’s likely that some of them will start supporting the language as an option. If “NoSQL” seems too combative, think of it as “NotOnlySQL.” These are all tools designed to trade the reliability and ease-of-use of traditional databases for the flexibility and performance required by new problems developers are encountering.

With so many different systems appearing, such a variety of design tradeoffs, and such a short track record for most, this list is inevitably incomplete and somewhat subjective. I’ll be providing a summary of my own experiences with and impressions of each database, but I encourage you to check out their official web pages to get the most up-todate and complete view.

Source of Information : Big data Glossary