ADBMS - Unit3 (Autosaved)

Multi-version Concurrency Control
• To provide ACID consistency without excessive locking, relational database systems

almost universally adopted the multi-version concurrency control (MVCC) model.
• In this model, multiple copies of data are tagged with timestamps or change identifiers
that allow the database to construct a snapshot of the database at a given point in time.
• In this way, MVCC provides for transaction isolation and consistency while
maximizing concurrency.
• For example, in MVCC, if a database table is subjected to modifications
between the time a session starts reading the table and the time the session
finishes, the database will use previous versions of table data to ensure that the
session sees a consistent version.
• MVCC also means that until a transaction commits, other sessions do not see
the transaction’s modifications—other sessions look at older versions of the
data. These older copies of the data are also used to roll back transactions that
do not complete successfully.
Multi-version Concurrency Control -
Example
• Figure 9-1 illustrates the MVCC model.
• A database session initiates a transaction at time t1 (1).
• At time t2, the session updates data in a database table (2);
• this results in a new version of that data being created (3).
• At about the same time, a second database session queries the database table, but because
the transaction from the first session has not yet been committed, they see the previous
version of the data (4).
• After the first session commits the transaction (5), the second database session will read
from the modified version of the data (6).
• The big advantage of MVCC is a reduction in lock overhead.
• In the example shown in Figure 9-1, without MVCC the update would
have created a blocking lock that would have prevented the second session
from reading the data until the transaction was completed.
Global Transaction Sequence Numbers
• MVCC can use transaction timestamps to determine which versions of data
should be made visible to specific queries.
• However, most databases use a global transaction ID rather than an explicit

timestamp.
• This is called the system change number (SCN) in Oracle and the transaction
sequence number in Microsoft SQL Server.
Global Transaction Sequence Numbers
• This sequence number is incremented whenever a transaction is initiated, and it is
recorded in the structure of modified rows (or database blocks).
• When a query commences, it looks for rows that have a sequence number less than
or equal to the value of the sequence number that was current when the query began.
• If the query encounters a row with a higher sequence number, it knows it must
request an older version of that row.
Two-phase Commit
• MVCC works with the ACID transaction model to provide isolation
between transactions running on a single system.
• Transactions that span databases in a distributed RDBMS are achieved

using a Two Phase-commit (2PC) protocol.
The Two Phases of 2PC
• Commit-request phase, in which the coordinator asks other nodes to
prepare the transaction. Typically, the preparation phase involves locking
the table rows concerned and applying changes without a commit.
• Commit phase, in which the coordinator signals all nodes to commit their
transactions if the commit-request phase succeeded across all nodes.
Alternatively, if any node experiences difficulties, a rollback request is
sent to all nodes and the transaction fails
Consistency in MongoDB
• By default—in a single-server deployment—a MongoDB database
provides strict single-document consistency.
• When a MongoDB document is being modified, it is locked against both

reads and writes by other sessions. However, when MongoDB replica sets
are implemented, it is possible to configure something closer to eventual
consistency by allowing reads to complete against secondary servers that
may contain out-of-date data.
MongoDB Locking
• Consistency for individual documents is achieved in MongoDB by the use
of locks.
• Locks are used to ensure that two writes do not attempt to modify a
document simultaneously, and also that a reader will not see an
inconsistent view of the data.
MongoDB Locking
• We saw earlier how a multi-version concurrency control (MVCC) algorithm can be
used to allow readers to continue to read consistent versions of data concurrently
with update activity.
• MVCC is widely used in relational databases because it avoids blocking readers—a

reader will read a previous “version” of a data item, rather than being blocked by a
lock when an update is occurring.
• MongoDB does not implement an MVCC system, and therefore readers are
prevented from reading a document that is being updated.
MongoDB Locking
• The granularity of MongoDB locks has changed during its history.
• In versions prior to MongoDB 2.0, a single global lock serialized all write
activity, blocking all concurrent readers and writers of any document
across the server for the duration of any write.
MongoDB Locking
• Lock scope was increased to the database level in 2.2, and to the
collection level in 2.8.
• In the MongoDB 3.0 release, locking is applied at the document level.
• When document-level locking is in effect, an update to a document will

only block readers or writers who wish to access the same document.
Replica Sets and Eventual Consistency
• In a single-server MongoDB configuration—and in the default multi-server scenario—
MongoDB provides strict consistency.
• All reads are directed to the primary server, which will always have the latest version of a
document. However, we saw in the previous chapter that we can configure the MongoDB
read preference to allow reads from secondary servers, which might return stale data.
• Eventually all secondary servers should receive all updates, so this behavior can loosely
be described as “eventually consistent.”
HBase Consistency
• HBase provides strong consistency for individual rows: HBase clients
cannot simultaneously modify a row in a way that would cause it to
become inconsistent.
• This behavior is similar to what we see in relational systems that generally

use row-level locking to prevent any simultaneous updates to a single row.
HBase Consistency
• However, the implementation is more complex in HBase because rows
may contain thousands of columns in multiple column families.
• During an update to any column or column family within a row, the entire
row will be locked by the RegionServer to prevent a conflicting update to
any other column.
HBase Consistency
• Read operations do not acquire locks and reads are not blocked by write
operations.
• Instead, read operations use a form of multi-version concurrency control

(MVCC), which we discussed earlier in this chapter.
• When read and write operations occur concurrently, the read will read a
previous version of the row rather than the version being updated.
Eventually Consistent Region Replicas
• In earlier versions of HBase, strong consistency for all reads was
guaranteed—you were always certain to read the most recently written
version of a row.
• However, with the introduction of region replicas, the possibility of a form

of eventual consistency is presented.
• Region replicas were introduced in order to improve HBase availability.
• A failure of a RegionServer would never result in data loss, but it could

create a minor interruption in performance while a new RegionServer was
instantiated.
• Region replicas allow immediate failover to a backup RegionServer, which

maintains a copy of the region data.
• By default, in HBase all reads are directed to the primary RegionServer, which results in
strictly consistent behavior.
• However, if consistency for a read is configured for timeline consistency, then a read
request will first be sent to the primary RegionServer, followed shortly by duplicate
requests to the secondary RegionServer.
• The first server to return a result completes the request. Remember that the primary gets a
head start in this contest, so if the primary is available it will usually be the first to return.
Timeline Consistency
• The scheme is called timeline consistency because the secondary RegionServer
always receives region updates in the same sequence as the primary.
• However, this architecture does not guarantee that a secondary RegionServer

will have up-to-date information; and if there are multiple secondary
RegionServers, then it’s possible that reads will return writes out of order, since
there may be race conditions occurring among the multiple secondary servers
and the primary
Example
• Figure 9-2 illustrates RegionServer replica processing.
• An HBase client is issuing writes in sequential order to the master RegionServer (1).
• These are being replicated asynchronously to the secondary RegionServers (2);
• At any given moment in time some of these replications may not yet have completed
(3).
• If a client is using timeline consistency, then it may read data from the master, but if the
master is unresponsive, it may read data from one of the secondary RegionServers (4).
• Successive reads may return data from either of the secondaries or from the primary.

ADBMS - Unit3 (Autosaved)

Uploaded by

Copyright:

Available Formats

ADBMS - Unit3 (Autosaved)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADBMS - Unit3 (Autosaved)

Uploaded by

Copyright:

Available Formats

Multi-version Concurrency Control

• To provide ACID consistency without excessive locking, relational database systems

• However, most databases use a global transaction ID rather than an explicit

• Transactions that span databases in a distributed RDBMS are achieved

• When a MongoDB document is being modified, it is locked against both

• MVCC is widely used in relational databases because it avoids blocking readers—a

• In the MongoDB 3.0 release, locking is applied at the document level.

• When document-level locking is in effect, an update to a document will

• This behavior is similar to what we see in relational systems that generally

• Instead, read operations use a form of multi-version concurrency control

• However, with the introduction of region replicas, the possibility of a form

• A failure of a RegionServer would never result in data loss, but it could

• Region replicas allow immediate failover to a backup RegionServer, which

• However, this architecture does not guarantee that a secondary RegionServer

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.