NOSQL - Just another buzzword?
These days, SQL (structured query language) has been the core mechanism for storing and accessing data within any application. It has many advantages, such as: reliability, scalability, fast lookup, and the ability to generate any type of report you can think of. Conventional database systems have their disadvantages as well, which is where NOSQL-based systems have surfaced to fill in the gaps. RDBMS's can have a bit of a learning curve if you don't know SQL, require some time to setup, and can even require hiring an employee dedicated to maintaining them.
Even the simplest line-of-business (LOB) application, can sometimes be over-architected, and is normally broken down into several tiers:
- UI or User interface- what the user sees and interacts with
- Business Layer- handles basic workflow and logic of the application
- Data access layer - usually some framework for working with a database
- SQL or database layer - tables, triggers, foreign keys, everything a DB admin does
This is ideal for large scale applications, but would have large overhead for a small to medium sized application. This is where concepts like NOSQL aim to make life easier. Using a NOSQL-based solution can merge the bottom two layers, which removes a substantial amount of work.
Well, what exactly is NOSQL?
NOSQL is a blanket term, as many tech buzzwords are. In general, think of a NOSQL database as a lightweight system for storing data that does not expose a SQL interface. In general, they are very fast at doing concurrent reads and writes while discouraging joint operations. They are also not built for set-based operations, such as COUNT, SUM, AVERAGE, etc. and thus are not ideal for reporting. Most implementations store data in a simple file format of some kind, generally with a single index for retrieving records.
A few (some unexpected) examples:
- MongoDB - stores data in JSON documents, written in C++
- CouchDB - exposes a REST-based JSON API instead of SQL, ideal for the web
- RavenDB - also stores data in JSON and modeled after MongoDB, built with C#
- Memcachedb - a persistent storage version of memcached
- Built-in .Net Settings - simple system that has existed since .Net 2.0 for storing settings per application as well as per user. Uses xml files as storage.
- the Windows Registry - written while some of us were still in grade school, great historical example of a NOSQL database.
Let's think of a simple application: a Twitter client that can store tweets on your file system, so you can browse and post new tweets while offline. The application would sync everything up once you establish an internet connection. Do we really need to bootstrap MS SQL Express 2008 to get this going? Using a NOSQL database, you could write this in a considerably shorter time than setting up a larger SQL-based solution.
In summary, it is always a good idea to consider multiple frameworks/solutions for every aspect of a project. The traditional, or most robust option, is not always the best option for each new application. Next time, I'll explore a NOSQL-based system in a demo application in C# as an avenue for exploring other topics.