Introduction
Relational databases emerged in the late 1960s as a crucial milestone in software development and dominated enterprise applications ever since. They survived several turbulent changes. Probably the most challenging one being the object-oriented obsession in the 1990s. These days, we know that object-oriented databases simply did not happen and ORM frameworks are being used instead to transform objects into flat relational structures.
Powerful as they are relational databases cannot overcome limitations originating from their design. Database connectivity has always been a known bottleneck resulting in advanced caching strategies just to avoid unnecessary database roundtrips.
With the advent of cloud computing, a good horizontal scalability has become available to a much wider range of businesses than ever before. Relational databases can be scaled indeed, despite the prevailing bias claiming the opposite, however the cost and effort of scaling them not negligible. This and other concerns, such as the need to deal with poorly structured data, resulted in an alternative view on data management commonly known as NoSQL.
Despite its name, NoSQL should be considered a complement rather than an opponent to relational databases. With the increasing maturity of alternative tools, the NoSQL turned into NOSQL to support the idea of Not Only SQL.
NoSQL Advantages
NoSQL presents a means of handling poorly structured data. Multimedia, feeds, blog entries etc. are difficult to be managed by a relational database because they do not fit in the tabular representations. NoSQL is designed to manage various kinds of complex and unwieldy data whose management would come at performance penalty when done by a traditional RDBMS.
NoSQL is capable of analysing intrinsic relationships. Questions like (citation from 1) “what music do my friends like, that I don’t yet own?†or “if this power supply goes down, what web services are affected?†can be answered by relationship traversals in a graph database. To appreciate this advantage you have to understand that the term relational in the SQL world is restricted to a single data set. Even though it is perfectly fine to inspect and filter directly related records using SQL, it is hard to find out about far-fetched relationships among seemingly unrelated data sets.
NoSQL caters for specific application needs, ranging from primitive key-value stores to document or graph databases. Instead of trying to find a universal solution, there are several single-purpose products which excel at what they do.
NoSQL Risks
Increased complexity for one. Having several types of persistent approaches leads inevitably into a steep learning curve. Unlike relational databases ruled by the well-known SQL standard, there are several data storage mechanisms in NoSQL requiring to understand various interfaces and APIs.
Maturity is another major concern. Relational databases have evolved in the course of some 40 years, many lessons have been learned the hard way during that period. Generally speaking, most RDBMS products can be considered stable and production-worthy. Unfortunately, the same does not hold true for the majority of NoSQL alternatives.
NoSQL Types
All of the usage scenarios mentioned in this section are based on 1.
Key-Value stores belong to the simplest data model where every key maps to a value. Simple as that, the term database would not even be appropriate. This approach is suitable for massive or ever-changing amounts of primitive data, such as simple statistics of the last decade or quoting on stock prices.
Examples:
Column-Family databases are ideal for semi-structured data. It is vital to know that writes are faster than reads and therefore consistency is valued over availability. A typical usage scenario could be logging of real-time events.
Examples:
Document databases adhere to the same principles as Key-Value stores, except for they handle documents instead of primitive data types. A product catalog would be the usual kind of application supported by a document database.
Examples:
Finally, Graph databases are designed to show relationships among data sets. Data is stored as nodes, their relationships, and additional key-value properties. Graph databases perform very well when working with associative data sets.
Examples:
Conclusion
NoSQL has recently gained a significant attention and addressed some of the inefficiencies of the traditional persistence mechanism. Even though it will take a while for NoSQL to prove it is suitable for the majority of commercial software, it enriches the options of data management and most importantly changes the view on the whole topic.
Resources
- NOSQL for the Enterprise
- Polyglot Persistence
- Database Thaw
- NoSQL The Ultimate Guide
- 10 things you should know about NoSQL databases
- The (non-)sense of NoSQL ORM frameworks
Â
For Expert Software Development Solutions
Why not contact Greenfinch Technology on 01 818 2949 or use our Contact form. We have been developing software for many years over a wide range of industries. Check out our .Net Development page.
An experienced staff member will be happy to give you a no-obligation consultation. They will go through what you require and put together the most efficient and cost-effective solution for you.
Greenfinch Technology
