Module 4
4.2 Scaling a real database – Distributed MangoDB
Dr. S. Pitchumani Angayarkanni
• MongoDB is a no SQL document-oriented database which is a fancy way to
say that instead of storing data in tables
• We start objects in the database directly
• The format in which objects are stored in MongoDB is JSON which makes our
life very easy every object has a unique ID which is auto-generated for us if
we don't provide it ourselves
• Internally MongoDB stores those objects in a binary format called BSON on
but that's just an implementation detail for us
• We can think of a row in a relational database table as an object or document
in MongoDB
• Columns can be thought of as different fields inside the document the primary
key in a SQL database table is equivalent to the ID which one could it be
objects contain and a table is equivalent to a collection of documents in
MongoDB
row
object
• [Link]
Download Powershell
• [Link]
Unzip the mongo power shell to c drive
List all databases
Create a Collection/Table
Insert Record and Display all
Display the records in neat format
Update and Delete Command
Scaling MongoDB using Data Replication
To scale MongoDB using data replication we will learn how to
group nodes using replication sets and finally we will focus on
write semantics and read preference
MongoDB – Replica Set
• we launched the single node with the
instance which contained all of our data
• Our application client in our case the
Mongo shell connected Load and read
all the data from that single node
• To provide redundancy for data
availability and resilience to failures of
individual nodes
• We're going to replicate our data by
launching multiple MongoDB instances
• A group of mongo db instances that contain
the same data is called the replication set
• In a replication set there is one node that is
the primary and the rest of the nodes are
considered secondaries which is a variation of
the master/slave architecture
• MongoDB by default all reads and writes from the application client go to the
primary node and the secondary is constantly sync with the primary to stay
up-to-date
• If the primary node fails
• The secondary is detected and
hold an election to elect a new
primary until that election
completes no write operations
can be acknowledged
• Once the old primary recovers it
can join back either as a primary
or a secondary depending on
our configuration
• Write semantics in the replication set by default a write operation is
acknowledged as soon as the data is successfully read and add the
primary
• However that may result in data loss if the primary goes down before the
data is a synchronously replicated to the secondaries
• So when we issue the write operation from our application we can specify a
write concern of two or more nodes
• Similarly we can specify write
concern majority to force the write to
be replicated to the majority of the
nodes regardless of the cluster size
• This is one of the reasons it is
recommended to have an odd
number of nodes at each
replication set now that we
understand the write semantics
• All the read operations are also
directed to the primary to guarantee
straight consistency
• However we can change that behavior
using the read preference
• When we issue the read request we
can set the read preference to primary
preferred to still read from the primary
when it's available
• If the primary has failed and a new primary has
not been elected yet we can still read from the
secondary nodes that are not too much out of
sync
• If the number of reads is too much for the primary
and we're fine with relaxing our consistency
requirements to eventual consistency
• We can even set the preference to secondary and
if we deployed our replication set across multiple
physical locations we can specify the read
preference to nearest
• To read from the node that has the lowest latency
to our application client this again can result in
reading stale data however that is a trade-off we
may be willing to pay for lower latency depending
on the business requirements
Demo
• [Link]