NoSQL

NoSQL databases
• Databases, which store data in a format different from relational databases, are known
as NoSQL databases.
• NoSQL stands for “not only SQL,” i.e. either the database can store and manage data
using “no SQL” or it can work in a combination that combines the flexibility of the
newer approach (NoSQL) with the power of the traditional relational system (SQL).
• Unlike relational databases, related data doesn’t have to be split up between multiple
tables; instead, it can be nested within the same data structure.
• NoSQL is an umbrella term to describe any alternative system to traditional SQL
databases.
• NoSQL databases are all quite different from SQL databases.
• NoSQL use a data model that has a different structure than the traditional row-and-
column table model used with relational database management systems (RDBMS).
NoSQL database features

Each NoSQL database has its own unique features. At a high level, many NoSQL
databases have the following features:
• Flexible schemas
• Horizontal scaling
• Fast queries due to the data model
• Ease of use for developers
1. Flexible Schema

• Unlike SQL databases, where you must determine and declare a table's schema before
inserting data, NoSQL dB, by default, do not require their documents to have the same
schema. That is:
• The documents in a single collection do not need to have the same set of fields and the data type for a
field can differ across documents within a collection.
• To change the structure of the documents in a collection, such as add new fields, remove existing fields,
or change the field values to a new type, update the documents to the new structure.

• This flexibility facilitates the mapping of documents to an entity or an object.

• Each document can match the data fields of the represented entity, even if the document
has substantial variation from other documents in the collection.
2. Horizontal scaling
• Vertical V/s Horizontal Scaling

Vertical scaling refers to increasing Horizontal scaling, also known as scale-out, refers to bringing
the processing power of a single on additional nodes to share the load.
server or cluster.

• Both relational and non-relational databases can scale up, but eventually, there will be a limit in terms of
maximum processing power and throughput.
• Additionally, there are increased costs with scaling up to high-performing hardware, as costs do not scale linearly.
• Horizontal Scaling is difficult with relational databases due to the difficulty in spreading out related data across
nodes.
• With non-relational databases, this is made simpler since collections are self-contained and not coupled
relationally
• Scaling MongoDB horizontally is achieved through Sharding and Replica sets.

• Sharding is horizontal scaling by spreading data across multiple nodes.

• Each node contains a subset of the overall data.

• Replication allows for high availability, redundancy/failover handling, and decreased bottlenecks on
read operations.
• However, they can also introduce issues for applications with large amounts of write transactions, as
each update must be propagated over to every replica set member.
Relational Database
NoSQL
Types of NoSQL databases

There are the four main types of NoSQL databases:

• Key-value stores
• Document databases
• Graph databases
• Column-oriented databases
Key-value stores
• It is the simplest type of NoSQL database.
• Key Value (KV) Stores maintain data as pair consisting of an index key and a value.
• For each Key, there is a value assigned to it.
• Each Key is unique and accepts only strings, whereas the value corresponding to the
particular Key can accept String, JSON, XML, etc.
• Owing to this behavior, it is capable of dealing with massive loads of data.
• KV stores query Values using the index Key. Every item in the database is stored in the pairs
of Keys (Indexes) and Values. KV stores resemble a relational database but with each table
having only two columns.
• Some KV stores may even allow basic joins to help you scan through if there are composite
joins, they may not be a suitable options.
• There are multiple KV Stores available, each differing mainly in their adaption of the CAP
theorem and their configurations of memory v/s storage usage.
• KV stores have fast query performance and are best suited for applications that require
content caching, e.g. a gaming website that constantly updates the top 10 scores & players.
Key-value stores
Key-Value Pairs Database: Features
1.Consistency
2.Transactions
3.Query Features
4.Data Structure
5.Scaling
Key-Value Pairs Database: Pros & Cons
• Pros:
– Simple Data model
– Scalable
– Value can include JSON, XML, flexible schemas
– Extremely Fast Owing to it’s simplicity
– Best fit for cases where data is not highly related
• Cons:
– No relationships, create your own foreign keys
– Not suitable for complex data
– Lacks Scanning Capabilities
– Not ideal for operations rather than CRUD (create, read, update, delete )
Key-Value Pairs Database: Use Case

• Key-Value Pairs databases are best suited for the following cases:
1. Storing session information: offers to save and restore sessions.
2. User preferences: Specific Data for a particular user
3.Shopping carts: easily handle the loss of storage nodes and quickly scale Big data
during a holiday/sale on an e-commerce application.
4.Product recommendations: offering recommendations based on the person’s data.

• Popular KV Stores would include Dynamo DB, Redis, BerkleyDB.

Document Stores
• Document Stores are an extension of the simplicity of Key Value stores, where the values are
stored in structured documents like XML or JSON.
• Document stores make it easy to map Objects in the object- oriented software.
• A document database is schema free, you don’t have to define a schema beforehand and adhere
to it. It allows us to store complex data in document formats (JSON, XML etc.).
• Document databases do not support relations. Each document in the document store is
independent and there is no relational integrity.
• Document stores can be used for all use cases of a KV store database, but it also has additional
advantages like there is no limitation of querying just by the key but even querying attributes
within a document, also data in each document can be in a different format. E.g. A product
review website where zero or many users can review each product and each review can be
commented on by other users and can be liked or disliked by zero to many users.
• E.g, A product review website where zero or many users can review each product, and each
review can be commented on by other users and can be liked or disliked by zero to many users.
Document Stores
Document Stores: Features, Pros & Cons
• Features of document store databases
1. Faster Querying
2. A large amount of data can be easily handled owing to its structure
3. Flexible Indexing

• Pros:
– Simple & Powerful Data model
– Scalable
– Open Formats
– No foreign Keys

• Cons:
– Not suitable for relational data
– Querying limited to keys & indexes
– Map Reduce for more significant queries
Document Stores: Use Case

1.User Profiles: Since they have a flexible Schema, the document can store different
attributes and values. This enables the users to store different types of information.
2.Management of Content: Since it has a flexible schema, collection and storing any
data has been made possible. This allows the creation of new types of content,
including images, videos, comments, etc. Everyday use is seen in blogging
platforms.
• Some popular Document stores are MongoDB, CouchDB, Lotus Notes.
Graph Databases

• Graph Databases specific purpose is the storage of graph-oriented data structures.

• A graph database is any storage system that provides index-free adjacency i.e.
every node contains a direct pointer to its adjacent element and no index lookups
are necessary. As the number of nodes increases, the cost of a hop remains the
same.
• Graph databases are optimized for traversing through connected data, e.g.
traversing through a list of contacts on your social network to find out the degree
of connections.
• Graph databases usually come with a flexible data model, which means there is no
need to define the types of edges and vertices.
Graph Databases
Graph Databases: Features, Pros & Cons
• Features:
1.Flexibility
2.Agility
3.Improved performance, even with huge volumes of data.
• Typical use cases for graph databases would include social networking site,
recommendation engine.
• Pros:
– Extremely powerful
– Connected data is locally indexed
– Can provide ACID
– Results in real-time
– Agile Structure
• Cons:
– Difficult to scale out, though can scale up
Graph Databases: Use Case

• Typical use cases for graph databases would include

1.Social networking site
2.Recommendation engine
3.Logistics
4.Risk assessment
5.Fraud detection

• Some of the popular graph databases are Neo4j, OrientDB, Allegrograph.

Column Family Data stores
• Column data stores take a hybrid approach mixing the declarative characteristics
game of relational databases with the key-value pair based and totally variables
schema of key-value stores.
• Wide Column databases stores data tables as sections of columns of data rather
than as rows of data.
• A column family data store is a multi-dimensional key value store (map or
associative array) which is persistent (values persist after creation or access),
distributed (data is distributed across multiple computing & storage nodes),
sorted (sorted keys) and sparse (values for certain dimensions may not be
populated, similar to sparsely populated rows in RDBMS).
Column Family Data stores
ACID Model
ACID stands for:
• Atomicity – Each transaction is either properly carried out or the process halts and the database
reverts back to the state before the transaction started. This ensures that all data in the database is
valid.
• Consistency – A processed transaction will never endanger the structural integrity of the database.
• Isolated – Transactions cannot compromise the integrity of other transactions by interacting with
them while they are still in progress.
• Durability – The data related to the completed transaction will persist even in the cases of network or
power outages. If a transaction fails, it will not impact the manipulated data.

• ACID Use Case Example

• Financial institutions will almost exclusively use ACID databases. Money transfers depend on the
atomic nature of ACID.
• An interrupted transaction which is not immediately removed from the database can cause a lot of
issues. Money could be debited from one account and, due to an error, never credited to another.

• Examples of dB: MySQL, PostgreSQL, Oracle, SQLite, and Microsoft SQL Server.
The BASE Model
BASE stands for:
• Basically Available – Rather than enforcing immediate consistency, BASE-modelled NoSQL databases
will ensure availability of data by spreading and replicating it across the nodes of the database cluster.
• Soft State – Due to the lack of immediate consistency, data values may change over time. The BASE
model breaks off with the concept of a database which enforces its own consistency, delegating that
responsibility to developers.
• Eventually Consistent – The fact that BASE does not enforce immediate consistency does not mean
that it never achieves it. However, until it does, data reads are still possible (even though they might not
reflect the reality).

• BASE Use Case Example

• Marketing and customer service companies who deal with sentiment analysis will prefer the
elasticity of BASE when conducting their social network research.
 ACID v/s BASE
S.
Criteria ACID BASE
No

1. Simplicity Simple Complex

2. Focus Commits Best attempt

3. Maintenance High Low

4. Consistency Of Data Strong Weak/Loose

5. Concurrency scheme Nested Transactions Close to answer

6. Scaling Vertical Horizontal

7. Implementation Easy to implement Difficult to implement

8. Upgrade Harder to upgrade Easy to upgrade

9. Type of database Robust Simple

10. Type of code Simple Harder

Time required for

11. Less time More time.
completion

12. Examples Oracle, MySQL, SQL Server, etc. DynamoDB, Cassandra, CouchDB, SimpleDB etc.
MongoDB
• MongoDB is an open-source database that uses a document-oriented data model and a non-
structured query language.
• In the MongoDB data model, it is easy to split data among several servers.
• MongoDB is a distributed database at its core, so high availability, horizontal scaling, and
geographic distribution are built in and easy to use
• It automatically redistributes documents, balances data, and loads a cluster, and routes the user
requests to the right machine.
• MongoDB stores data in flexible, JSON-like documents, meaning fields can vary from document
to document and data structure can be changed over time
• The document model maps to the objects in your application code, making data easy to work with.
• Ad hoc queries, indexing, and real time aggregation provide powerful ways to access and analyze
your data.
Need MongoDB technology.
• MongoDB technology overcame one of the biggest pitfalls of the traditional database
systems, that is, scalability. MongoDB has exceptional scalability.
• No downtime while the application is being scaled
• It makes it easy to fetch the data and provides continuous and automatic integration.
• Performs in-memory processing
• Text search
• Graph processing
• Global replication
• Economical
• MongoDB provides the right mix of technology and data for competitive advantage.
• It is most suited for mission-critical applications since it considerably reduces risks.
• It increasingly accelerated the time to value (TTV) and lowered the total cost of ownership.
• It builds applications that are just not possible with traditional relational databases.
 Architecture of MongoDB NoSQL Database
The following are the components of MongoDB architecture:
• Database
• Collection
• Document

Database
It is also called the physical container for data. Every database
has its own set of files existing on the file system. In a single
MongoDB server, there are multiple databases present.

Collection
The collection consists of various documents from different fields. All the collections reside within one database.
In collections no schemas are present.

Document
The set of key values are assigned to the document which is in turn associated with dynamic schemas. The benefit
of using these schemas is that a document may not have to possess the same fields whereas they can have different
data types.
Features of MongoDB
• Queries support: MongoDB supports ad-hoc and document-based queries.
• Index Support: All fields in the document are indexed.
• Replication: MongoDB possesses Master-Slave replication. It uses a native application to preventing
database downtime by maintaining multiple copies of data.
• Multiple Servers: Duplicate data that is stored in the database is run over multiple servers to avoid the
damage caused due to hardware failure.
• Auto-sharding: The data is being distributed among several physical partitions known as shards.
MongoDB has an in-built feature called automatic load balancing.
• MapReduce: It is a flexible aggregation tool that supports the MapReduce function.
• Failure Handling: In MongoDB, works effectively in case of failures such as multiple machine failures,
data center failures by protecting data and making it available.
• GridFS: This feature will allow the files to divide into smaller parts and store them in different documents
without complicating the stack.
• Schema-less Database: MongoDB is a schema-less database programmed in C++ language.
• Document-oriented Storage: It uses BSON format which is similar to JSON
• Procedures: MongoDB JavaScript works better than procedures as databases use the language more than
procedures.
Drawbacks of MongoDB
• It uses high memory for data storage
• Document size has a limit
• Less flexibility with querying
• There is no transaction support