NOSQL DATABASE
Department of Computer
Science & Engineering
www.cambridge.edu.in
CO2
CO3
CO4
Difference between SQL and NOSQL
What is NoSQL
Database?
NoSQL databases (AKA "not only SQL “ or NON-SQL) store data
differently than relational tables. NoSQL databases come in a variety
of types based on their data model. The main types are document,
key-value, wide-column, and graph. They provide flexible schemas and
scale easily with large amounts of big data and high user loads.
Types of databases — NoSQL
1. Document-oriented
databases
A document-oriented database stores data in documents
similar to JSON (JavaScript Object Notation) objects.
Each document contains pairs of fields and values.
The values can typically be a variety of types, including
things like strings, numbers, booleans, arrays, or even
other objects.
A document database offers a flexible data model, much
suited for semi-structured and typically unstructured data
sets.
They also support nested structures, making it easy to
represent complex relationships or hierarchical data.
Examples of document databases are MongoDB and Couchbase. A typical
document will look like the following:
2. Key-value databases
A key-value store is a simpler type of database where each item contains k
and values.
Each key is unique and associated with a value. A value can be integer, str
binary object etc..
They are used for caching and session management and provide h
performance in reads and writes because they tend to store things in memo
Examples are Amazon DynamoDB and Redis. A simple view of data stored
key-value database is given below:
3. Wide-column stores
Wide-column stores store data in tables, rows, and dynamic
columns. The data is stored in tables. However, unlike traditional
SQL databases, wide-column stores are flexible, where
different rows can have different sets of columns. These
databases can employ column compression techniques to reduce
the storage space and enhance performance. The wide rows and
columns enable efficient retrieval of sparse and wide data. Some
examples of wide-column stores are Apache Cassandra and
HBase. A typical example of how data is stored in a wide-column
is as follows:
4. Graph databases
A graph database stores data in the form of nodes
and edges.
Nodes typically store information about people,
places, and things (like nouns),
while edges store information about the
relationships between the nodes.
They work well for highly connected data, where
the relationships or patterns may not be very
obvious initially.
Examples of graph databases are Neo4J and
Amazon Neptune. MongoDB also
provides graph traversal capabilities using the
$graphLookup stage of the aggregation pipeline.
1.1. The Value of Relational Databases
1.Getting at Persistent Data
2.Concurrency
3.Integration
4.A (Mostly) Standard Model
1. Getting at Persistent Data
Probably the most obvious value of a database is keeping large amounts of
persistent data.
Most computer architectures have the notion of two areas of
memory:
MAIN MEMORY SECONDARY MEMORY (DISK)
a fast volatile “main Therefore, to keep data around, we write it to a
memory” backing store, commonly seen a disk
limited in space and File system
loses all data when you Database system
lose power or something
bad happens to the
operating system
2. Concurrency
Enterprise applications tend to have many people looking at the same body of data
at once, possibly modifying that data. Most of the time they are working on
different areas of that data, but occasionally they operate on the same bit of data.
As a result, we have to worry about coordinating these interactions to avoid such
things as double booking of hotel rooms.
Transactions Control: Concurrency is notoriously difficult to get right, with all sorts of errors that can trap even
the most careful programmers. Since enterprise applications can have lots of users and other systems all
working concurrently, there’s a lot of room for bad things to happen. Relational databases help handle this by
controlling all access to their data through transactions.
Enterprise
Apply
3. Integration:
Enterprise applications live in a rich ecosystem that requires multiple applications,
written by different teams, to collaborate in order to get things done. This kind of
inter-application collaboration is awkward because it means pushing the human
organizational boundaries. Applications often need to use the same data and updates
made through one application have to be visible to others.
shared database integration: A common way to do this is shared database integration
where multiple applications store their data in a single database. Using a single
database allows all the applications to use each others’ data easily, while the
database’s concurrency control handles multiple applications in the same way as it
handles multiple users in a single application
What is an enterprise application example?
Organizations that adopt enterprise apps have seen a significant
improvement in their processes and productivity. To better
explain what an enterprise application is, let’s look at some
examples you may be familiar with:
• Accounting and Billing Systems
• Customer Relationship Management (CRM)
• Point-of-Sale Software (POS)
• Supply Chain Management (SCM)
• Enterprise Resource Planning (ERP)
• Business Intelligence Systems
• Human Resource (HR) Systems
4. A (Mostly) Standard Model:
Relational databases have succeeded because they provide the core
benefits we outlined earlier in a (mostly) standard way. As a result,
developers and database professionals can learn the basic relational model
and apply it in many projects.
Core Mechanism:
SQL
1.2. Impedance Mismatch
For application developers, the biggest frustration has been what’s commonly
called the impedance mismatch:
The difference between the relational model and the in-memory data
structures.
The relational data model organizes data into a structure of tables and
rows, or more properly, relations and tuples.
for in-memory data structures, which can take on much richer structures
than relations. As a result, if you want to use a richer in-memory data
structure, you have to translate it to a relational representation to store
it on disk. Hence the impedance mismatch—two different
representations that require translation
That decade was marked with the growth of object-oriented programming languages, and with them came object-
oriented databases—both looking to be the dominant environment for software development in the new
millennium.
1.3. Application and Integration Databases
The database acts as an integration database—with multiple applications, usually
developed by separate teams, storing their data in a common database. This improves
communication because all the applications are operating on a consistent set of
persistent data.
Integration
APPLICATION1 Mechanism is SQL Common DATABASE
APPLICATION2 structure
APPLICATION3 (Integration Database)
APPLICATION4
APPLICATION5
1. Furthermore, should an application want to make changes to its data storage, it needs to coordinate with all the
other applications using the database.
2. Different applications have different structural and performance needs, so an index required by one application
may cause a prob
Integration
APPLICATION1 Mechanism is SQL (Application Database)
APPLICATION2
APPLICATION3
APPLICATION4
APPLICATION5
With an application database, only the team using the application needs to know about the database
structure, which makes it much easier to maintain and evolve the schema. Since the application
team controls both the database and the application code, the responsibility for database integrity
can be put in the application code.
APPLICATION DATABASE
web services
XML
Communicati
SQL
JSON on http
1.4. Attack of the Clusters
At the beginning of the new millennium the technology world was hit by
the busting of the 1990s dot-com bubble.
In 2000s did see several large web properties dramatically increase in scale of many
dimension.
Large sets of data appeared: links, social networks, activity in logs, mapping data.
Coping with the increase in data and traffic required more computing resources.
Scaling up implies bigger machines, more processors, disk storage, and memory. But
bigger machines get more and more expensive, not to mention that there are real
limits as your size increases.
Alternate way to use
advantage all resources by
creating Small machine
—while individual machine failures are
common, the overall cluster can be Small machine
built to keep going despite such
failures, providing high reliability. cluster Small machine
Problem with relational database in cluster
As large properties moved towards clusters, that revealed a new problem—
relational databases are not designed to be run on clusters.
. Commercial relational databases are usually priced on a single-server
assumption, so running on a cluster raised prices and led to frustrating
negotiations with purchasing departments.
This mismatch between relational databases and clusters led some
organization to consider an alternative route to data storage.
Alternate way to
approach to serve
the data
—Google Amazon
BigTable Dynamo
The Emergence of NoSQL
Open-source, distributed, non-relational databases.
NoSQL databases operate without a schema, allowing you to freely add fields
to database .
Not Only SQL: open-source databases developed in the early 21st century,
and mostly not using SQL.
NoSQL development concentrated on big data running on clusters.
The Emergence of NoSQL(Cont….)
Big Data Growth
With the explosion of data from various sources—social media, IoT devices, and web
applications—traditional relational databases struggled to handle the volume, variety, and
velocity of this data. Organizations needed solutions that could scale horizontally and
manage unstructured or semi-structured data effectively.
Limitations of Relational Databases
While relational databases (RDBMS) have constraints like rigid schema requirements, ACID
(Atomicity, Consistency, Isolation, Durability) compliance, and difficulties in scaling.
The Emergence of NoSQL(Cont….)
Web and Mobile Applications
The rise of web and mobile applications required databases that could support high-speed
transactions and real-time data access. Developers needed systems that could quickly
adapt to changing requirements and support rapid development cycles.
Distributed Systems
As cloud computing became more prevalent, the need for distributed database systems
that could operate across multiple servers and geographical locations grew. NoSQL
databases are designed to operate in distributed environments, providing better fault
tolerance and availability.
The Emergence of NoSQL(Cont….)
Variety of Data Types
Businesses started to work with diverse data types, such as JSON, XML, and key-
value pairs. NoSQL databases can handle these different formats without requiring a
strict schema, allowing for more agile data modeling.
Community and Ecosystem
The open-source movement played a significant role in the adoption of NoSQL
databases. Projects like MongoDB, Cassandra, and Couchbase gained popularity,
supported by integration with various programming languages and frameworks.
The Emergence of NoSQL(Cont….)
Use Cases
Specific use cases, such as content management systems, real-time analytics, and
large-scale web applications, highlighted the advantages of NoSQL databases.
Businesses began adopting these technologies to meet their specific needs more
effectively than with traditional databases.
Key Points
Relational databases have been a successful technology for twenty years, providing
persistence, concurrency control, and an integration mechanism.
Application developers have been frustrated with the impedance mismatch between
the relational model and the in-memory data structures.
The vital factor for a change in data storage was the need to support large volumes
of data by running on clusters. Relational databases are not designed to run
efficiently on clusters.
Key Points
The common characteristics of NoSQL databases are
Not using the relational model
Running well on clusters
Open-source
Built for the 21st century web estates
Schema less
Data Model
Data Model
Data Model
Data Model
NoSQL Data Model
Relational Model
Relational Model
Aggregate Model
Aggregate Model
Aggregate Model
Aggregate Model
Aggregate Model
Aggregate Model
Aggregate Model
Aggregate Model
