Review Of The Motivation For Nosql

Published Date: 02 Nov 2017

NoSQL database systems are often highly optimized for retrieval and appending operations and often offer little functionality beyond record storage (e.g. keyâ€“value stores). The reduced run-time flexibility compared to full SQL systems is compensated by marked gains in scalability and performance for certain data models (Wiki 2013).

NoSQL database management systems are mostly use with applications that requires huge quantity of data and this data does not require a relational model, or when the same attribute can be capture on a single machine amidst the cluster that makes up the database. It is useful when the data can be structured, but NoSQL is used when what really matters is the ability to store and retrieve great quantities of data, not the relationships between the elements. Usage examples might be to store millions ofÂ keyâ€“value pairsÂ in one or a fewÂ associative arraysÂ or to store millions of data records. This organization is particularly useful for statistical or real-time analyses of growing lists of elements (such as Twitter posts or the Internet server logs from a large group of users).

HISTORY OF NOSQL

Carlo Strozzi in 1998 used NoSQL in his open source database that was not using the standard SQL interfaces. He suggests that, as the current NoSQL movement "departs from the relational model altogether; it should therefore have been called more appropriately 'NoREL' (Carlo 1998).

The term NoSQL was re-introduced by Eric Evans, aÂ RackspaceÂ employee, in early 2009.Â The name was credited to Eric Evans though it was really meant as a twitter hash tag; Johan Oskarsson then was looking for a unique twitter hash tag to use in the event he was trying to organize to discuss open-source distributed system in 2009 and Eric Evans now suggest the name NoSQL. The name attempted to label the emergence of a growing number of non-relational, distributed data stores that often did not attempt to provideÂ atomicity, consistency, isolation and durabilityÂ guarantees that are key attributes of classic relational database systems.

STATEMENT OF THE PROBLEM

The problem statement is as listed below:

Lack of understanding of the term NoSQL by database users. Some people assume the name means "No more SQL".

Most users assume NoSQL will be the end of SQL.

Difficulty in the choice of whether to use relational database or NoSQL for their product.

1.3 AIMS AND OBJECTIVES

To understand the importance of NoSQL.

To differentiate between NoSQL and SQL.

To know the advantage that NoSQL has over RDBMS and vice-versa.

To be able to study the new trend in database management system.

SCOPE AND LIMITATION OF THE STUDY

This study will only cover the review of some specific NoSQL Categories by manner of their implementation and how these categories are different from each other.

The study will also bring to light the significant difference between RDBMS and NoSQL and the relationship between the two of them. It is of note that this study wonâ€™t cover all the categories of NoSQL but will try as much as possible to make the subject known or clear to a layman.

SIGNIFICANCE OF THE STUDY

The result of this research will help to make clear distinction between SQL and NoSQL, the categories involved as well as the present limitation to NoSQL. It will also help us to identify why NoSQL is the database of the 21st Century and why it is the new trend in database management study, the study will also propose what the future trend looks like in database management.

2.0 LITERATURE REVIEW

2.1 BACKGROUND OF THE STUDY

This review tends to study several grey areas of the movement NoSQL.

Businesses and organizations today operate increasing volumes of data including information about their customers, suppliers, competitors and operations. Being able to analyze and visualize this data find trends and anomaly that subsequently can be acted on to create economic value has become an important factor for economic advantage.

In this review, we would examine the misconceptions about NoSQL by critics, reason or motivation for NoSQL, characteristics of NoSQL database, taxonomy of NoSQL database and we will then examine projects under each of the taxonomy mentioned.

2.2 MISCONCEPTIONS OF CRITICS

At the beginning of the movement, it was first said that NoSQL means an end to RDBMS especially with blogosphere (people that makes use of blog). In 2009, it was suggested by Eric Evans in his blog that what the term NoSQL should mean "Not only SQL" instead of "No to SQL". This means that each individual or organization is left with a choice of which database will be the best i.e. there is an alternative exist from RDBMS. Blogger Nati shalom comments this shift in the following way: "I think that what we are seeing is more of a realization that existing SQL database alternatives are probably not going away any time soon, but at the same time they canâ€™t solve all the problems of the world. Interestingly enough the term NOSQL has now been changed to Not Only SQL, to represent that line of thought" (Eric 2009). Some people also believe that NoSQL is only meant for company like Google and Amazon but the truth is that almost all corporation will need NoSQL because large amount of data will be generated and push to this company and on the long run they will need a database that can handle large amount of data.

2.3 REVIEW OF THE MOTIVATION FOR NoSQL

According to Petter Nasholm (Petter 2012) he believes that the reason for the introduction of NoSQL is because RDMBS cannot actually cope with some modern application because it cannot meet the requirement of these applications. This is because RDBMS have the following problem:

Low throughput: Most RDBMS cannot handle large volume of data store (Eric 2009).

RDBMS are built to scale vertically: vertical scaling means adding more hardware to the existing machine (Petter 2013), whereas horizontal scaling means adding more machine to a cluster.

Object â€“Relational mapping is expensive: it takes a lot of time to map the applications object model and the databases relational model

The thinking "one size fits all" is flawed: RDBMS design is seen as a general tool that can meet the entire requirement that an application can have on data management, this is not possible (Cattel 2010).

ACID (Atomicity, Consistency, Isolation and Durability) is not always needed: with relational database system ACID is a requirement and it is a trade off for performance. But not all application requires ACID which leads to loss of performance for nothing.

2.4 REVIEW OF THE CHARACTERISTICS OF NoSQL

NoSQL has the following characteristics:

It has no schema: the data structure is generally not defined through any explicit schema that the database knows of. Client can store data in any way they like without adhering to any predefine structure. Though these does not mean that there is no implicit schema because to be able to query the database there has to be some defined way of naming the content of the database. If price is named as cost then it wonâ€™t be possible to get the price out, but been schema-less helps to increase the flexibility.

It is built for large storage: it is generally accepted that it is built for large data storage used by large website like Google, Amazon e.t.c.

They allow for horizontal scaling: compare to RDBMS that can only scale vertically NoSQL database can scale horizontally by adding machine to cluster without any downtime. We can add as many machines as we like.

BASE: (Basically Available Soft state Eventually consistent) pattern of database is used (Petter 2012), Dominic Bruhn asserts that ACID is not used [5]. This means that the system is always available. It trades of consistency for availability.

SQL is not supported: unlike relational database systems that support some dialect of SQL, NoSQL does not support SQL.

Distributed: NoSQL databases are often distributed systems where several machines cooperate in clusters to provide clients with data. Each piece of data is commonly replicated over several machines for redundancy and high availability. This means that failure of one node does not really affect the whole database.

Open source: NoSQL is mostly open source unlike RDBMS that huge sum of money for license.

2.5 REVIEW OF NoSQL TAXONOMY

Taxonomy means the act, method or way of naming. As of today, there is no universally accepted taxonomy of NoSQL. Different researchers differ on the systems included and the categories they belong to. However, our database can be named based on the data model (Strauch 2013).

In the presentation "NoSQL is a Horseless Carriage" (Yen 2009) Yen suggests a taxonomy that can be found in table 2.1

Term

Matching database

Data-Structures Server

Redis

Tupple store

Gigaspaces

Coord

Apache River

Object database

ZopeDB

DB4O

Shoal

Document store

CouchDB

Mongo

Jackrabbit

XML Databases

ThruDB

CloudKit

Perservere

Riak Basho

Scalaris

Wide column store

Bigtable

Hbase

Cassandra

Hypertable

KAI

OpenNeptune

Qbase

KDI

Ordered-Key-Value-Store

Tokyo Tyrant

Lightcloud

NMDB

Luxio

MemcacheDB

Actord

Eventually-Consistent Key-Value-Store

Dynamo

Voldemort

Dynomite

SubRecord

Mo8onDb

Dovetaildb

Key-Value-Store

Keyspace

Flare

Schema Free

RAMCloud

Key-Value-Cache

Memcached

Repcached

Coherence

Infinispan

EXtreme Scale

Jboss Cache

Velocity

Terracoqa

Table 2.1 Classifications â€“ NoSQL Taxonomy by Stephen Yen [7]

Another taxonomy that is not as comprehensive as above is "Databases in the cloud" by Ken North (North 2009). Table 2.2 summarizes his classification of datastores. This also includes some datastores available in cloud-computing environments only.

Characteristics of Key-Value store

We store the data in the database in alphabetical order.

We can perform copy, read, update and delete activities on the data.

We store the relationship to the data in application code.

It can handle huge amount of data.

Replication of data is done using database in form of ring.

Document Stores: This system is use to store document. The documents are indexed and a simple query mechanism is provided. The document consists of a set of keys and value which is almost the same like in key-value store. They are usually schema free,

Characteristics of Document Store

Key-value lookup is used to retrieve a document.

A unique key that represent the document is use to address the document in the database.

Column Family Store: this is the method of storing data by column instead of storing data by row. This is because in analytic and business intelligence, we have column stores operating in a share-nothing parallel processing architecture which can be used to build high performance applications. They can also be defines as a distributed, multi-dimensional sorted map.

Characteristics of Column Family Store

We only read the required column in the database making the read to be faster.

Storage unit is attached to each and every column.

When querying, column database are faster than row database.

Graph oriented database: they make use of nodes instead of row; they are not aggregate data model. They are basically node graph structure. It is good at moving across relationship between things unlike RDBMSs that are not good at jumping at relationship between data structure. It can easily handle jumping around relationship. It makes use of graph query.

Characteristics of Graph oriented database

Graph database is scalable though with increase in complexity.

We make use of graph database for shortest path calculation.

They have high performance compare to others.

2.5.1 DATABASE USING KEY-VALUE-STORE

Some of the examples of database that makes use of Key-value-store are given below:

2.5.1.1 PROJECT VOLDEMORT

Project Voldemort is an advanced key-value store, written in Java. It is open source, with substantial contributions from LinkedIn. Voldemort provides multi-version concurrency control (MVCC) for updates. It updates replicas asynchronously, so it does not guarantee consistent data. However, it can guarantee an up-to-date view if you read a majority of replicas (Cattell 2010). The keys and values can be complex; it can also consist of compound objects as well consisting of lists and maps. Nevertheless, a simple concept like the key-/value store offers a number of advantages (Kreps et al. 2010).

Only efficient queries are allowed.

The performance of queries can be predicted quite well.

Data can be easily distributed to a cluster or a collection of nodes.

In service oriented architectures it is not uncommon to have no foreign key constraints and to do join in the application code as data is retrieved and stored in more than one service or datasource.

Gaining performance in a relational database often leads to denormalized datastructures or storing more complex objects as BLOBs or XML-documents.

Application logic and storage can be separated nicely (in contrast to relational databases where application developers might get encouraged to mix business logic with storage operation or to implement business logic in the database as stored procedures to optimize performance).

There is no such impedance mismatch between the object-oriented paradigm in applications and paradigm of the datastore as it is present with relational databases.

2.5.1.2 RIAK

It is also an advance key-value-store; it is almost like a document store but it lacks some of the important feature of a document store (Cattel 2010). Like document store, its object can be stored in JSON format and thus can have multiple fields like document. It allows object to be group into bucket like those supported by document. Indices are not allowed on other of the field except the primary field; the non-primary fields can only be fetch and store as part of JSON object.

It supports replication of object and sharding by hashing on the primary key. It allows replica value to be temporarily inconsistent. Consistency can be achieved by specifying how many nodes must respond for a single read and for a single write operation. It has a simple and symmetric architecture and it also makes use of consistent harshing.

2.5.1.2 REDIS

It was originally a one person project but now have multiple contributors, it is written in C. The main reason we grouped it under key-value-store is because of its map/dictionary API. Atomic update is done in REDIS by locking and it also does asynchronous replication. A major disadvantage about Redis is that the amount of main memory limits the amount of data that is possible to store. The servers stores it data in RAM, this means that the bigger the RAM, the more amount of data that can be stored, but the data can be copied to disk for backup or system shutdown. For more nodes to be added, it is better to shut down the system. It implement delete, lookup and insert operations.

2.5.1.2 SCALARIS

It is written in Erlang because of the approach of its language e. g. in implementing a non-blocking commit protocol for atomic transactions. In distribution of data over nodes, key ranges are assigned over the nodes rather than hashing to nodes. It means a query of range donâ€™t have to go over every node which leads to better load balancing. Replication is synchronously done thereby guaranteeing data consistency. Power failure to more than one node will lead to disastrous loss of data.

It guarantees ACID properties also for concurrent transactions by implementing an adapted version of the Paxos consensus protocol (Lamport 1998).

2.5.2 DATABASE USING DOCUMENT STORE

It is slightly more complex than key-value-store. They allow encapsulation of key-value in document. The following are database that makes use of the document store.

2.5.2.1 CouchDB

It is part of Apache project. It is written in Erlang. Compare to SimpleDB, it has richer data model. CouchDB can be briefly characterized as a document database which is accessible via a RESTful HTTPinterface, containing schema-free documents in a flat address space. For these documents JavaScript functions select and aggregate documents and representations of them in a MapReduce manner to build views of the database which also get indexed. CouchDB is distributed and able to replicate between server nodes as well as clients and servers incrementally. Multiple concurrent versions of the same document (MVCC) are allowed in CouchDB, client application is saddled with the responsibility of managing conflict resolution (Apache 2008-2010). It makes use of â€˜viewâ€™ as query and it is use to define field constraint in JavaScript. It provides durability on system crash. It performs it updates by flushing documents and indexing to disk and by writing to end of file. It achieves scalability through asynchronous replication of data rather than through harding. It also does not guarantee consistency of data.

2.5.2.2 MongoDB

It is a schema-free document database written in C++ and it is an open source project which is mainly handled by the 10gen Inc. it is lockless and provides indexes on collection and it has a document query mechanism. It is similar to CouchDB but has the following difference (Cattel 2010).

"

â€¢ MongoDB supports automatic sharding, distributing documents over servers.

â€¢ Replication in MongoDB is mostly used for failover, not for (dirty read) scalability as in CouchDB. MongoDB does not provide the global consistency of a traditional DBMS, but you can get local consistency on the up-to-date primary copy of a document.

â€¢ MongoDB supports dynamic queries with automatic use of indices, like RDBMSs. In CouchDB, data is indexed and searched by writing map-reduce views.

CouchDB provides MVCC on documents, while MongoDB provides atomic operations on fields."

MongoDB stores data in a binary JSON like format that is called BSON. Replication is done by sharding. It gives support to master-slave replication with automatic failover and recovery.

2.5.3 DATABASE USING COLUMN FAMILY STORE

In column database system, data is stored in column rather than row. They are distributed and multidimensional sorted maps. Example of database that makes use of column-family store includes but not limited to the following:

2.5.3.1 Googleâ€™s Bigtable

"A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.

(row:string, column:string, time:int64) ! string" (Fay et al. 2006). It is used by over sixty applications at Google as at 2006. These include but not limited to Google earth, Google analytic web indexing and so on. It has achieved some of its goal (Fay et al. 2006), this includes: availability, reliability, wide applicability, performance and scalability. The data structure used by Bigtable is "sparse, distributed multidimensional sorted map".

Row key: Bigtable has a row key of 64KB, read or write data in a single row is atomic, this makes it easier for the client to reason about the systems behavior in the case of multiple update to the same row.

Column Key: Bigtable has unlimited number of column, a column family must be created before storing data in any column key in the family. The column key must be name using the following syntax: family:qualifier. The family name must be printable while the qualifier can be arbitrary with any string. Accessing of disk and memory accounting is done at the column family level.

Time stamp: To be able to identify the versions that is contain in each table a 64-bit integer time stamp is use. If the time is assigned by bigtable, it will be in microseconds or it can be assign explicitly by the client application. An application that needs to avoid collision needs to generate a unique time stamp for itself.

Architecture

It is built on top of the Google file system, chubby and it is stored in an immutable data structure SSTable. This facilitates the storage of log and data table. It defines data entries based on timestamp. It can decide on the number of entries that is kept in the server.

Advantages of BigTable

It does not require the querying technology used in RDBMS.

It has better data compression because it makes use of sparse row.

Limitations of BigTable

Consistency is not paramount.

It does not support ACID transaction.

The database is not an open source.

It does not give adequate access control.

It is difficult to use with applications that are complex and have evolving schemas.

2.5.3.2 Google Spanner

This is the latest in terms distribution database built by Google, it is a scalable and globally-distributed database (Corbett et al. 2012 pg 1.). As the amount of data changes, it reshards data across machine and also in case of failure it automatically do load balancing by migrating data across machine or data center as the case may be. It is designed to scale up to millions of machines across hundreds of datacenter and trillions of rows. It can be use by application that needs high availability at all time by replicating its data within or even across continent. Googleâ€™s initial customer for spanner F1 (Shute et al. 2012) uses five replicas across the united state. It evolves from BigTableâ€™s like key-value store to a kind of multi-version database. It makes use of schematized semi-relational table to store its data; the data is versioned and time stamped automatically. It support general purpose transaction and unlike most NoSQL database it makes use of an SQL like query language. While using spanner, application can specify how the replica are placed in the datacenter, how far data are from the user and how far the datacenter are to each other. The system can also automatically move across datacenter to balance the usage of the resource.

Spanner has two important features,

It provide externally consistent read and write at a time stamp.

It provide globally consistent read.

This enables spanner to support consistent backups, consistent MapReduce executions and atomic schema updates, all at global scale, and even in the presence of ongoing transactions (Corbett et al. 2012).

Each spanner deployment is called a universe and since spanner manages data globally, it only has a handful of running universe (Corbett et al. 2012). It is organize as a set of zone where zones are unit of administrative deployment. Zones are also unit of isolation because there can be one or more zones in a datacenter. This is because different application might have their data partitioned in across different sets of server in the same datacenter. A zone has one zonemaster and between one hundred and several thousand spanservers. The former assigns data to spanservers; the latter serve data to clients. The per-zone location proxies are used by clients to locate the spanservers assigned to serve their data (Corbett et al. 2012). In Figure1 below shows the picture of how a spanner server is organized (Corbett et al. 2012).

Fig. 1. Spanner server organization

2.5.4 DATABASE USING GRAPH FAMILY

They are not aggregate data model but makes use of a separate data model. They make use of node graph structure. It is good at moving across relationship between data structure. It can easily handle jumping around relationship. It makes use of graph query to query the database. Example of graph family includes:

2.5.4.1 Neoj4

It is an open source database, it is written in java. The developers describe Neo4j as "embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables". Neo4j is the most popular graph database (Wikipedia 2013).

2.6 NoSQL and Consistency

NoSQL system is basically a distributed system. This literally means it has to be partitioned. You will basically have to choose between consistency and availability in the partition. Whereas in a Relational Database Management System the system is in a single machine therefore there is no need for partition and this will ensure consistency.

Cap theorem (Shalom 2009) states that "in a distributed system, out of the three essential things Consistency, Availability and Partitions, only two can be achieved at any given time". This implies that NoSQL database neglect consistency for availability. This implies that in the face of partitions, there is a trade-off between availability and consistency and only one is achievable - lot of systems trade-off consistency for improved availability, such as Amazon Dynamo (Gilbert et al. 2002) and Cassandra (DiCandia et al. 2007), while others sacrifice availability for consistency, as in the Google Chubby lock system, which makes best-effort at availability in the presence of partitions, but is a strongly consistent system (Lakshaman et al. 2010).

Another issue to note is that if consistency is desired across the node it leads to slow response time since the system is distributed and so a lot of nodes have to get involved in the communication or transaction.

3.0 APPLICATION OF NoSQL

NoSQL movement has been used in the creation of different database. These new database that are created are non-relational. Some of the databases created are open-source while some of them are not open-source. Some of the example of database created with NoSQL include: Google bigtable which is solely used by Google, Amazon SimpleDB and lot of them.

NoSQL database is used by company such as Google and Amazon because they always want their system to be available which is not possible with the RDBMS because CAP theory make us to realize that only two is possible at any single time among these three features of a database, consistency, availability and partitioning.

NoSQL can be applied in several database among which includes the following:

3.0.1 Google Bigtable

Google as a company was faced with the problem expanding growth in the amount of data their application is using and this was a source of concern because there is a limit to how the number of machines that can be added to their system that is vertical scaling and they also realize that it is highly important that there database should always be available which was not possible with RDBMS. This was the reason they made use of NoSQL database to ensure that they can increase their database by adding more machines to a cluster rather than scaling up and also they realize they can benefit from the availability feature of NoSQl.

3.0.2 Amazon Dynamo

Amazon was also faced with the same problem Google were facing which is the problem of huge growth in data. The engineer realize that scalability will entails increase in the number of machines and this lead to the fact that will lot of machine working together there might be a machine that might not work and this leads to problem that they will be losing money because their database will not be available for this period. This was the reason why their engineers were looking for a database that is scalable, reliable and always available. This leads to the creation of the software called Dynamo.

3.0.3 Googleâ€™s Spanner

It is important to note that Spanner as a database was created by Google Engineers as a result of the problem and challenges that cropped up after Bigtable. It tends to address some of the problem in Googleâ€™s Bigtable. The paper on it was published in 2012. It has better consistency than bigtable and can be used by application that have complex evolving schema. It is also a globally distributed database.

4.0 FUTURE TRENDS OF NoSQL

It is important to note that at the beginning of this review, it was clearly stated that NoSQL is not a replacement for RDBMS, it only serves as a choice for those that doesnâ€™t need the limitations that RDBMS has. But it is also important to note that NoSQL has wide range of database and each one works well for a specific application and not all application. This means that if in a single enterprise have lot of application and these applications cannot be supported by a single database or cannot work well with a single database then they will run into a wall. This is why it will be a good thing if a single enterprise can make use of different database for different application under a single platform. This term is referred to by martin fowler has â€˜Polyglot persistentâ€™ [24].

5.0 CONCLUSION

The main aim of this study is to make it clear what the term NoSQL means and how it has affect the RDBMS, from this review and study we have been able to realize that NoSQL has created an alternative to RDBMS and this ensures that individual or group making use of database are now left with options or alternative depending on the type of application they are using. The study has makes it clear that NoSQL does not mean â€˜NO TO SQLâ€™ but rather "NOT ONLY SQL". It can be seen that the way forward to database manage is to be able to use more than one database in a single application, that is, different part of the application will be handled by different database that meets the requirement of that particular part.

Our Service Portfolio

Want To Place An Order Quickly?

Then shoot us a message on Whatsapp, WeChat or Gmail. We are available 24/7 to assist you.

Do not panic, you are at the right place

Visit Our essay writting help page to get all the details and guidence on availing our assiatance service.

Get 20% Discount, Now
£19 £14/ Per Page
14 days delivery time

Our writting assistance service is undoubtedly one of the most affordable writting assistance services and we have highly qualified professionls to help you with your work. So what are you waiting for, click below to order now.

Get An Instant Quote

ORDER TODAY!

Our experts are ready to assist you, call us to get a free quote or order now to get succeed in your academics writing.

Get a Free Quote Order Now