NoSql Database

Abstract-The relational database has been exponential growth of data ,since many

the dominant model for database organizations collect vast amounts of

management since it was developed. customer, scientific, sales, and other data for

However, organizations that collect large future analysis. Similar issues are involved

amounts of unstructured data are in modeling the social network like Twitter,

increasingly turning to nonrelational Facebook, etc. Implementing such problems

databases, now frequently called NoSQL in relational databases involves large

databases. NOSQL databases are distributed, number of joins which is expensive to be

non-relational, open source and are calculated. With the intense increase in

horizontally scalable. In this research paper, usage of internet leading to need for storing

we are surveying about NoSQL, its large amounts of interconnected data, there

background, features and various NoSQL was a clear desire for a data store tailored to

data stores. such needs.

I.INTRODUCTION Thus a piece of software is a NoSQL

database if it doesn’t require a stringent
Relational model has been dominating the
schema for every record created, is
computer industry since the 1980s mainly
distributable on commodity hardware &
for storing and retrieving data. With the
doesn’t use relational database mathematical
widespread use of relational database
theory. The primary advantage of NOSQL
systems the flaws of such systems become
Database is that, unlike relational databases
more apparent. Way back people used
they handle unstructured data such as
database just for storing tabular data like
documents, e-mail, multimedia and social
purchase reports and finance records &
media efficiently. NoSQL databases aren’t a
relational databases were perfect for this.
mere layer on top of existing technologies.
But in today’s environment, these relational
Each type of NoSQL database is designed to
representations are not efficient in
manage different types of data. The
performing many operations. For example
popularity of NoSQL databases lies largely
the World Wide Web exhibits far more
in the speed they provide for developers.
complicated networks of relationships than
NoSQL solutions are quicker to build,
were expected when SQL was designed
update, and deploy than their relational
.Also Relation database lacked handling
forerunners.
II.BACKGROUND
The first documented use of the term
NoSQL was by Carlo Strozzi in 1998. Carlo
used the term NoSQL because his database
was accessed via shell scripts, rather than
through use of the standard Structured
Query Language (SQL).Thus the name,
NOSQL. Its origin can also be related in
2006 when Google released its paper that
described its Bigtable distributed structured
database. Amazon also released a paper of
its own in 2007 describing its Dynamo data
storage application. The Dynamo paper
basically described the first globally
distributed key‐value store used at Amazon.
These two papers inspired many different
organizations to create their NoSQL
databases. Thus, many open-source NoSQL
databases had emerged by 2009. Riak,
MongoDB, HBase,Accumulo, Hypertable,
Redis, Cassandra, and Neo4j were all
created between 2007 and 2009. Today the
NoSQL movement includes hundreds of
NoSQL database products. Each problem
resulted in its own solution and its own
NoSQL database.
III.WHY NOSQL
Due to recent trends in IT & the advent of
the World Wide Web and the explosion of
Internet connected devices, information
sharing has dramatically increased. Much of
this data is unstructured text.
There were problems with conventional
databases. Not every problem fits well into
rows and columns. There are also scenarios
in which the relationships themselves can
hold their own metadata. An RDBMS
doesn’t handle those situations at all. Every
scenarios has a type of NoSQL database that
overcome the limitations of RDBMS.
Relational databases can suffer from a
sparse data problem .We may discover facts
and relationships over time. Using an
RDBMS for this would require an
ever‐increasing storm of many‐to-many
relationships and linking tables.
IV.NOSQL FEATURES
Schema agnostic: A database schema is the
description of all possible data and data
structures in a relational database. With a
NoSQL database, a schema isn’t required,
giving you the freedom to store information
without doing up‐front schema design. The
great benefit to a schema agnostic database
is that development time is shortened. In a
traditional RDBMS, many times we go
through a process of schema redesign. We
may have to modify our queries accordingly.
NoSQL databases provide this flexibility for
changing both the schema and the query.
Nonrelational: Relations in a database
establish connections between tables of data.
With a NoSQL database, the information is
stored as an aggregate i.e a single record
with everything about the transaction.
NoSQL databases don’t have this concept of
relationships between their records. They
instead denormalize data. This approach has
the advantage of not requiring complex
query time joins across multiple data
structures (tables). Rather than inserting ten
rows in a variety of tables in a relational
database, we can instead store a single
structure for all, as a JSON or XML
document. In relational database theory, we
normalize data. The advantages to storing
data multiple times are Easy storage and
retrieval & Query speed.
Commodity hardware: With NoSQL
database, cheap off‐the‐shelf servers can be
used. Adding more of these cheap servers
allows NoSQL databases to scale to handle
more data. In many NoSQL databases, a key
design decision is to use multiple computers
to store data for a single database, rather
than have the whole database on a single
server. The main advantage of this approach
is in the case of very large datasets. Another
key advantage is that adding high
availability is easier;
Highly distributable: Distributed databases
can store and process a set of information on
more than one device. With a NoSQL
database, a cluster of servers can be used to
hold a single large database.
Other features Although some features are
fairly common to NoSQL databases
however certain NOSQL databases may lack
one or more of the following features and
still qualify as a modern NoSQL database.
Open‐source: There is not a host of
open‐source NoSQL products to suit every
need.
BASE versus ACID: Prior to 2014, the
majority of NoSQL definitions didn’t
include ACID transaction support. Not many
NoSQL databases have ACID transactions.
Exceptions to that norm are FoundationDB,
Neo4j, and MarkLogic Server, which do
provide fully serializable ACID transactions.
V.MANAGING DIFFERENT
DATA TYPES
NoSQL databases come in four core types.
one for each type of data the database is
expected to manage:
Columnar: It is an extension to traditional
table structure. Supports variable sets of
columns (column families) and is optimized
for column‐wide operations (such as count,
sum, and mean average).
We can define column families before
loading data into the database, meaning that
the structure of data must be known in
advance.
Each one of the column families consists of
several fields. One of these column families
may have multiple “rows”. A key benefit of
a column store over an RDBMS is that
column stores don’t require fields to always
be present and don’t require a blank padding
null value like an RDBMS does. This
feature prevents the sparse data problem.
The great thing about column stores is that
you can retrieve all related information
using a single record ID, rather than using
the complex Structured Query Language
(SQL) join as in an RDBMS.
Column Family databases should be used
when the number of write operations
exceeds reads.
DataStax, Apache Cassandra, HBase,
Apache Accumulo, Hypertable are few
columnar databases.
Key‐value: It has very simple structure
having sets of named keys and their
value(s), typically an uninterpreted chunk of
data. Sometimes that simple value may in
fact be a JSON or binary document. This
structure is also known as “hash table”
where data retrieval is usually performed by
using key to access value.
Key-value Store databases are more
appropriate for the management of stocks,
products and real time data analysis,
providing high data retrieving speed while
the greatest amount of data is mapped into
memory.
Basho Riak, Redis, Voldemort, Aerospike,
Oracle NoSQL are few key-value stores.
Triple or graph store: It is now becoming
prominent; however the concept of triples
has been around since 1998. Every fact (or
assertion) is described as a triple of subject,
predicate, and object. We can quickly build
this simple data structure into a web of facts,
which is called a directed graph in computer
science. Graph math is complex and
specialized and may not be required in all
situations where storing triples are required.
If we need to store facts, dynamically
changing relationships, or provenance
information, then we consider a triple store.
If we need to know statistics about the
graph, then we should consider a graph
store.
Graph databases are more appropriate for
working with connected data, for example,
to analyze social connections among a set of
individuals, road maps and transport
systems.
Neo4j, Ontotext’s GraphDB, MarkLogic,
OrientDB, AllegroGraph are few graph
databases.
Document: XML, JSON, text, or binary
blob. Any treelike structure can be
represented as an XML or JSON document.
Document databases are sometimes called
aggregate databases because they tend to
hold documents that combine information in
a single logical unit, an aggregate. Loosely,
a document is any unstructured or
tree‐structured piece of information. It could
be a recipe, financial services trade,
PowerPoint file, PDF, plain text, or JSON or
XML document.
Document Store databases are a good choice
when working with large amounts of
documents that can be stored into structured
files such as text documents, emails or XML
and CMS and CRM systems.
MongoDB, MarkLogic, CouchDB,
FoundationDB, IBM Cloudant, Couchbase
are few document databases.
Hybrid NoSQL database: These databases
provide a mix of the core features of
multiple NoSQL database types such as
key‐value, document, and triple stores all in
the same product.
VI .CONSISTENCY METHODS
In the NoSQL world, consistency generally
falls into one of two camps:
ACID Consistency: ACID means that once
data is written, we have full consistency in
reads.
Eventual Consistency (BASE): BASE
means that once data is written, it will
eventually appear for reading.
Some NoSQL databases have
ACID‐compliance on their roadmap, even
though they are proponents of BASE. Many
NoSQL databases allow tuning between
levels of consistency and availability, which
relates to the CAP theorem.
The CAP theorem is a computer science
conjecture, shows the list of options as to
how the balance between consistency,
availability, and partitioning can be
maintained in a BASE database system.
Eric Brewer came up with the CAP
conjecture in 2000. The CAP theorem in
computer science is fundamental to how
many NoSQL databases manage data. CAP
stands for Consistency, Availability, and
Partitioning, which are aspects of data
management in databases.
Consistency: Shows whether the database is
fully (ACID) consistent, or eventually
consistent, or without any consistency
guarantees?
Availability: During a partition, is all data
still available?
Partitioning: If some parts of the same
database cluster aren’t communicating with
each other, can the database still function
separately and correct itself when
communication is restored?
The CAP theorem states that we cannot have
all features of all three at the same time. It is
claimed that we can have only two of the
three. The reality is that each is a sliding
scale. We may be able to trade off a little of
one for more of another.
VII.CONCLUSION
It’s tempting to think that once NoSQL
databases evolve to handle more data and
query types, the RDBMS will no longer be
needed. Nothing could be further from the
truth because NoSQL databases can’t
provide all the functionality of a relational
database. We can think of Hybrid database
model, that is, they have the familiar SQL in
the frontend and NOSQL in the backend.
These databases might not be as fast as a
pure NOSQL database but they still provide
features of both relational as well as
NOSQL databases to the user. Thus a lot of
disadvantages of both relational as well as
NOSQL databases may be covered up.
REFERENCES
[1] Hecht, R.; Jablonski, S., “NoSQL evaluation: A
use case oriented survey”, Proc. IEEE International
Conference on Cloud and Service Computing , vol.,
no., pp.336,341, Dec. 2011
doi: 10.1109/CSC.2011.6138544..
[2] Zvarevashe,K.; Gotora,T .,” A Random Walk
through the Dark Side of NoSQL Databases in Big
Data Analytics” , International Journal of Science
and Research , vol.3 no.6, pp. 506-509 ,June 2014.
[3] Okman, L.; Gal-Oz, N.; Gonen, Y.; Gudes,E.;
Abramov, J., “Security Issues in NoSQL Databases”
Proc. of IEEE 10th International Conference on Trust,
Security and Privacy in Computing and
Communications , vol., no., pp.541-547, Nov 2011
doi : 10.1109/TrustCom.2011.70.
[4] Nayak,A; Poriya, A,; Poojary,D., “Type of
NOSQL Databases and its Comparison with
Relational Databases” , International Journal of
Applied Information Systems issn : 2249-0868 vol.5
no.4, pp. 16-19 March 2013.
[5]Cattell,; Rick. , “Scalable SQL and NoSQL data
stores” , SIGMOD Record ACM , vol.39, no.4 ,pp
.12-27, December 2010 .
[6]Jing ,H.; Haihong, E.; Guan, L.; Jian ,D., “Survey
on NoSQL database" , Proc. IEEE 6th International
Conference on Pervasive Computing and
Applications” , vol., no., pp.363-366, Oct 2011 doi:
10.1109/ ICPCA.2011.6106531.
[7] Leavitt, N.; , “Will NoSQL Databases Live Up to
Their Promise? “, IEEE Transactions on Computer,
vol.43, no.2, pp.12-14, Feb. 2010 doi:
10.1109/MC.2010.58.
[8] Tauro, C,; Aravindh, S,;
Shreeharsha,A,B.,"Comparative study of the new
generation, agile, scalable, high performance NOSQL
databases", International Journal of Computer
Applications issn no 0975 – 888 vol 48, no.20, pp 1-4
June 2012.