The Landing: Report: Potential improvement using NoSQL solutions on Apartment Rental system

Wiki: https://landing.athabascau.ca/pg/pages/view/130277/couchdb

There are both benefits and risks associated with NoSQL database overall and specific to my scenario. The number one benefit of NoSQL is scale, the ability to add nodes to an existing pool of networked servers without the need to re-partition the datastore or any high degree of maintenance work is an attractive proposition for businesses. But as with anything there are trade-offs and NoSQL is no exception. There are at least 7 varying types of NoSQL models that more or less uses Key-Value pairs as their foundational data structure: Key-Value Store, Document Store, Wide Column Store, Graph Store, Tabular Store, XML Store and Object Store (For more information about the aforementioned types of NoSQL Store, see “Windows Azure No SQL White Paper” under the references section).

The major trade-offs are the lack of referential integrity and predefined schemas as compare to relational db model in favor of performance and scalability which also contributes to its drawback. The loosely defined data schema means enforcing referential/data integrity is now the responsibility of middleware code rather than naively handled within the RDBMS. I.e. ensure no orphan records dangling in the system. While Wide Column Store type of NoSQL implementation provides some level of consistency in semi-schematized fashion but it is still no match for the relational model. For instance, Apache Cassandra features Super Columns which is a form of Wide Column Store.

Aside from the benefits of fast query performance and the high degree of scalability that NoSQL possesses. Other NoSQL model such as Object Store works well with ORM tools to bring dataset into memory objects accessed by modern programming languages (i.e c# and java). Reducing both the design time and execution time for mapping objects to tables stored within database.

All in all, NoSQL works best in situations where there are high demand in data volume with the needs to scale horizontally and little desires for maintaining a consistent data schema. I.e. Analytics Application Conversely, if the demand for predetermined consistent data schema is high than relational model is a better choice for data integrity including being full ACID compliant. I.e. Transactional Application

With that, I do not see any potential improvement in implementing NoSQL solution on my proposed system. The benefits of RDBMS outweigh the many improvements that NoSQL brings specifically in my case. Given my system is transactional in nature; I would maintain the current design choice and go with RDBMS. I will explain in more details in my week 9 reflection blog.

References:

Windows Azure No SQL White Paper - http://download.microsoft.com/download/9/E/9/9E9F240D-0EB6-472E-B4DE-6D9FCBB505DD/Windows%20Azure%20No%20SQL%20White%20Paper.pdf

http://couchdb.apache.org/

http://wiki.apache.org/couchdb/Technical%20Overview

http://dl.acm.org/citation.cfm?id=1883478.1883486&coll=DL&dl=GUIDE&CFID=120499965&CFTOKEN=68865958

http://mpouttuclarke.wordpress.com/2011/01/04/couchdb-and-hadoop/

http://www.slideshare.net/adessoAG/no-sql-9355109

http://blog.couchbase.com/simple-document-versioning-couchdb

http://wiki.apache.org/couchdb/HTTP_Document_API

http://radar.oreilly.com/2012/02/nosql-non-relational-database.html

http://www.youtube.com/watch?v=sh1YACOK_bo

http://www.youtube.com/watch?v=oL-A4JYwgH4