THE QUESTION OF DATABASE TRANSACTION

PROCESSING: AN ACID, BASE, NOSQL PRIMER

by Charles Roe

©2013 DATAVERSITY Education, LLC. All rights reserved.

Imagine a world where CAP Theorem is wrong. Database engineers and application designers
now have absolute control over every transaction, at all times, across the entire planet, no
matter how many distributed nodes an enterprise has. Relational systems are now happily
married to the aggregate of any and all non-relational designs. It no longer matters if an
enterprise wants to employ a range of SQL-centric databases within its burgeoning collection
of Key-Value, Document, Column-Oriented, and Graph stores – they all fit together like fine
wine and aged French cheese. Their BI applications work together to collect data in a timely
fashion from every platform, they have achieved 99.999% uptime, nodes are quickly and
easily added with barely the click of a button, every transaction is consistent within itself all
the time with no soft states, eventualities, or latencies, the world is a better place. If you want
strong consistency, with high availability, over a distributed network of 100,000 cheap,
commodity servers, with total ACID compliance, then you are in luck!

The anecdote above is meant to present a utopian vision that were it entirely true – in all
cases – would make the lives of everyone in the database and application design fields much
easier. They could design cheap, perfect systems that just worked and worked, for everyone,
all the time. On the downside, it would also make many of their jobs redundant. Luckily for
the numerous organizations involved in such industries, the utopian fantasy is far from a
reality. But how far is it, really? Are there not some platforms available that provide complete
transactional integrity within non-relational systems? Are there not intercessions between
competing models that meet somewhere in between?

There are actually many elements of such a vision that are working together. ACID and NoSQL
are not the antagonists they were once thought to be; NoSQL works well under a BASE
model, but also some of the innovative NoSQL systems fully conform to ACID requirements.
Database engineers have puzzled out how to get non-relational systems to work within an
environment that demands high availability, scalability, with differing levels of recovery and
partition tolerance. BASE is still a leading innovation that is wedded to the NoSQL model,
and the evolution of both together is harmonious. But that doesn’t mean they always have to
be in partnership; there are several options. So while the opening anecdote is true in many
cases, organizations that need more diverse possibilities can move into the commercial arena
and get the specific option that works best for them.

©2013 DATAVERSITY Education, LLC. All rights reserved. 1

THE TRANSACTION RELIABILITY MODELS
The primary issue discussed within this paper boils down to two disparate database reliability
models: ACID (Atomicity, Consistency, Isolation, and Durability) and BASE (Basically
Available, Soft state, Eventual consistency). The first (ACID) has been around for some 30+
years, is a proven industry standard for SQL-centric and other relational databases, and
works remarkably well in the older, yet still extant, world of vertical scaling. The second
(BASE) has only recently gained popularity over the past 10 years or so, especially with the
rise of social networking, Big Data, NoSQL, and other leviathans in the new world of Data
Management. BASE requirements rose out of a need for ever-expanding horizontally scaled
distributed networks, with non-relational data stores, and the real-time availability constraints
of web-based transaction processing. While there are now more crossovers and negotiations
between the two models, they essentially represent two competing groups, with Brewer’s
CAP Theorem acting as the referee in the middle forcing tough decisions on each team.

Relational database systems are almost always ACID complaint because relational indexing
is centralized and so there is no advantage in BASE. An ACID database functions like a
unit that is fully consistent with transactional updates; while a BASE system functions like
independent units that are eventually consistent, and without transactional updates. There
were no other choices than relational systems in the past; but the advent of NoSQL now gives
organizations that need a different model more choices. They can do ACID or BASE, so the
variety is much greater. It is now possible to provide ACID constraints and other enterprise
features within specific NoSQL systems if that is what the organization requires to meet its
needs.

ACID – A BRIEF OVERVIEW

The primary work with database reliability constraints began in the 1970s with Jim Grey.
He formulated the first three elements of the acronym – Atomicity, Consistency, and
Durability – in his seminal work “The Transaction Concept: Virtues and Limitations” that was
published in 19811. The paper looked at transactions in terms of contract law, whereby each
transaction had to conform to specific “transformations of a system state.” All transactions
had to obey the laws defined within the contract parameters. According to Grey, each
transaction within a database had to obey protocols, either happened or didn’t happen,

©2013 DATAVERSITY Education, LLC. All rights reserved. 2

and could not be changed once committed. In
1979, Bruce Lindsay et al. expanded on Grey’s REAL-WORLD DATABASE
preliminary findings with their paper “Notes on EXAMPLE 1:
Distributed Databases.”2 The paper focused on
MarkLogic’s Enterprise NoSQL
the essentials for achieving consistency within
database with integrated search
distributed database management systems, data and application server provides a
replication, authorization and access controls, robust NoSQL platform with ACID
recovery management, two-stage commits, and compliance as one of its central tenets,
others. The final foundational element of ACID no need for predefined schemas,
different availability configurations,
came in 1983 with the publication of Andreas
near linear scaling of hardware, Big
Reuter and Theo Härder’s paper “Principles of Data search, MapReduce capabilities,
Transaction-Oriented Database Recovery.”3 They Hadoop integration, multiple language
added the principle of Isolation to the discussion application authoring, and without
and officially coined the acronym ACID; it has any loss of security often associated
persisted for the past 30 years as the indispensable with many NoSQL systems. is a firm
constraint for achieving reliability within database believer that technology can make or
transactions, and in simple terms means: break a successful Data Governance
program. That does not mean that
• Atomicity: All operations are performed technology is the solution to Data
or none of them are. If one part of Governance. You cannot purchase
the transaction fails, then all fail. and install a piece of hardware
or software and therefore have a
• Consistency: The transaction must meet Data Governance program. Data
all rules defined by the system at all Governance is all about formalizing
times; there are never any
people’s behavior associated with
half-completed transactions.
data.
• Isolation: Each transaction is
Technology can assist in managing
independent unto itself.
workflow, Metadata, communications,
• Durability: Once complete, the modeling, analytics, you name it. But
transaction cannot be undone.4 the truth is that the implementation
of the technology itself requires
ACID constraints have provided transaction governance. Formalized behavior is a
processing with a reliable foundation from which necessary result.
to build for decades, and would have continued
were it not for the advent of the Internet, the growth
of distributed data stores, the unprecedented
increase in data volumes and variability, the need

©2013 DATAVERSITY Education, LLC. All rights reserved. 3

to document and store unstructured data, and the subsequent need for more flexibility in
terms of scaling, design, processing, cost, and disaster recovery. This is not a claim that ACID
requirements are no longer essential to transaction processing, because they are. Web-scale
applications, non-relational data stores, and global distribution of data centers required
the creation of new alternatives. Nevertheless, with new evolutions in the database field,
it is now possible to have a fully functional NoSQL database that conforms to strict ACID
compliance – such systems are still rare within the industry at this time, but they do now exist
for organizations that need such an evolution.

NOSQL AND THE SHIFTING SANDS OF DATABASE

ARCHITECTURES
A paradigm shift began occurring during the late 1990s and the early part of the new
millennium. The evolution of the Internet, and its resulting data explosion, forced many of the
burgeoning Internet behemoths to reconsider new ways to deal with their data. The same
could be said for smaller organizations, and startups that saw the growth of web-based
processing as a goldmine with no end. Thus began a necessary shift from relational data
stores to non-relational data stores, collectively now known as NoSQL or “Not Only SQL.”

The development of non-relational architectures has been part of the database discussion
for decades, but didn’t really take root until the late 1990s with the work of Carlo Strozzi
and others. Strozzi coined the term “NoSQL”5 in 1998 with the creation of his new, still
relational, database model that no longer used SQL as its programming language (the term
was reintroduced at a meetup in 2009 by Eric Evans and Johan Oskarsson and has since
stuck). Other major players that helped caused what is today a seismic shift in database
technologies include:6

• 1997 - Microsoft’s publication of the MDX Standard

• 2000- Release of Neo4j

• 2000 – Dr. Eric Brewer’s address on CAP Theorem

• 2003- Development of Memcached

• 2003 – Publication of the paper “The Google File System”

©2013 DATAVERSITY Education, LLC. All rights reserved. 4

 • 2004 – Publication of the paper “MapReduce: Simplified Data Processing on
Large Clusters”

• 2005 – CouchDB is released

• 2006 – Publication of the paper “Bigtable: A Distributed Storage System for

Structured Data”

• 2006 – XQuery language specification is standardized by WC3

• 2007 – Publication of the paper “Dynamo: Amazon’s Highly Available

Key-value Store”

The avalanche had begun; now many more distributed, non-relational data stores such as
MongoDB, Cassandra, Project Voldemort, Terrastore, Redis, Riak, HBase, and plethora of
others are available on the market. The events listed above are only an umbrella summary
of so much other work also going on in the industry at the time. They represent a microcosm
of hundreds, if not thousands, of smaller organizations and thought leaders who worked to
move the industry forward to where it stands today. The impetus for such a change occurred
due to many factors, the least not of which include:

• Unstructured data doesn’t fit neatly into relational tabular structures, and the
proliferation of so many different data formats required new storage
capabilities.

• Vertical scaling was proving to be too expensive and could not deal with the
voluminous expansion of data occurring.

• Traditional RBDMS could no longer handle the needs of high throughput that
organizations like Google or Amazon required.

• The complexity of object-relational mapping was not needed for many of the
tasks web-based applications performed.

• Pre-determined forced schemas were too constraining in the new world where
schemas needed to be quickly adaptable.

• The administration overhead of the old paradigm, where servers were

run in-house, had become too costly; off-site “clouds” could provide cheaper
alternatives and faster “out scaling” of distributed systems.

• ACID requirements were too constraining for many of the Internet’s demands;
some constraints had to be relaxed.

©2013 DATAVERSITY Education, LLC. All rights reserved. 5

Application developers needed new innovations
outside of the traditional SQL-based, table-oriented REAL-WORLD DATABASE
database architectures that had governed the EXAMPLE 2:
industry since its inception. The Internet giants
Couchbase Server is a document
such as Google, Amazon, Facebook, LinkedIn,
store built for high availability, in a
and others built their own designs or altered distributed NoSQL environment. It
those freely available on the market, and helped provides easy scalability within the
to revolutionize the industry in the process. The Cloud or on standard commodity
proliferation of smaller startups needed cheaper servers. It provides full consistency,
with zero application downtime, an
alternatives, and the open source community
extensive range of query and index
stepped in to fill a void with the development of support, incremental MapReduce,
many free or low-cost database designs. The auto-sharding, cross-cluster replication,
avalanche has since spread to all corners of the and native support for JSON
industry, and multiple alternatives exist. documents.

That above list is in no way exhaustive, but only

outlines some of the primary incentives that helped to precipitate the rise of non-relational
data stores and the now-popular acronym in the database transaction reliability world: BASE.

CAP AND BASE – THE SHOTS HEARD AROUND THE

WORLD
BASE is a clever acronym, especially when paralleled with ACID – data professionals are
the chemists of the IT universe. While it is not known for sure who originated the term,
most people give credit to Dr. Eric Brewer for at minimum popularizing the term. In 2000,
his keynote address at the ACM Symposium titled “Towards Robust Distributed Systems”7
proved to be the shining moment when many in the industry nodded their heads and knew,
at least in their guts, that momentous changes were on the horizon.
BASE is essentially the diametric opposite to ACID, with the limitations outlined by Brewer
falling across the spectrum. The BASE acronym entails:

• Basically Available – the system guarantees some level of availability to the

data even in regards to node failures. The data may be stale, but will still give
and accept responses.

©2013 DATAVERSITY Education, LLC. All rights reserved. 6

 • Soft State – the data is in a constant state of flux; so, while a response may
be given, the freshness or consistency of the data is not guaranteed to be the
most current.

• Eventual Consistency – the data will eventually be consistent through all nodes
and in all databases, but not every transaction at every moment. It will reach
some guaranteed state eventually.

In Brewer’s address he presented a simple table that outlined the essential traits of each of
the two models:8

ACID BASE
• Strong Consistency • Weak Consistency – stale data OK

• Isolation • Availability first

• Focus on “commit” • Best effort

• Nested transactions • Approximate answers OK

• Availability? • Aggressive (optimistic)

• Conservative (pessimistic) • Simpler!

• Difficult evolution (e.g. schema) • Faster

• Easier evolution

He stressed that the entire balance between the two is a spectrum; database engineers had
to choose the specifics of what they needed and wanted versus what they could attain when
developing their particular application. The real focus of the opposition between the two
competing models is demonstrated with Brewer’s CAP Theorem, which outlines the three
major characteristics of database transaction processing, and contends that only two of the
characteristics can be met at any given time. The three central elements of CAP (Consistency,
Availability, and Partition Tolerance) have since been expanded to include much more detail,
along with extensive experimentation by engineers around the world to verify and quantify
the real-world results of such a theorem.

©2013 DATAVERSITY Education, LLC. All rights reserved. 7

CONSISTENCY - HOW IS THE
REAL-WORLD DATABASE
DATA PERCEIVED? EXAMPLE 3:
ACID constraints provide strong consistency, all MongoDB is an open source,
the time, no matter what. Such requirements often document datastore that achieves high
have repercussions, though; especially regarding availability through built-in replication,
availability. If the system must always remain in it includes dynamic schemas that can
evolve as applications evolve, full
a consistent state, so all parties see the same
index and query support, aggregation
view of the data at the beginning and end of a framework and MapReduce, strong
transaction, then across thousands of nodes that consistency, advanced security
data may not always be available. The same protocols, horizontal scalability for
repercussion affects disaster recovery and the loss operations of any size, and auto
sharding.
of nodes – if one part of a distributed database
collapses, then strong consistency would not
allow any further updates until the entire system is
realigned. Thus, we come to Eventual Consistency
and a range of other consistency guarantees:

A. Strong (Strict) Consistency – All read operations return the value from the last
finalized write operation. It doesn’t matter which replica the operation completed
the write to; all replicas must be in the same state for the next operation to occur
on those values.

B. Eventual Consistency – This has the greatest variability of potential values

returned. At any given point readers will see some written value, but there is no
guarantee that any two readers will see the exact same write. All replicas will
eventually have the latest update; it’s just a matter of time when that will happen.

C. Monotonic Read Consistency – This is also known as a session guarantee.

Reads are similar to eventual consistency in that the data could still be stale; but
monotonic read consistency guarantees that over time the client will get a more
up-to-date read (or the same read) if they request a read from the same object.

D. Read Your Own Writes (or Read My Writes) – guarantees that the client always
reads their most recent writes, but other may not see the same updates. It doesn’t
matter what replica the writes are going to, the client always sees their most
updated one.

©2013 DATAVERSITY Education, LLC. All rights reserved. 8

 E. Causal Consistency – if a client reads one value (a) and then writes the next
value (b), and another client then reads the value of (b) they will also see the
value of (a) since they are connected to each other. Therefore, any writes that
are causally related must be seen by all processes in the specific order they were
written.9

There are many other consistency guarantees

with different names, including (but not limited
to) casual+, sequential, consistent prefix, entry REAL-WORLD DATABASE
consistency, release consistency, FIFO consistency, EXAMPLE 4:
and bounded staleness. But the main issue is the Datastax Enterprise offers a complete
fact that application programmers must weigh NoSQL Big Data platform through a
their options when deciding on the consistency production-certified Apache Cassandra
requirements of any given transaction. The other implementation, vigorous security
protocols not often seen in NoSQL
two characteristics of CAP Theorem impose
platforms, simple data migration
restrictions on what level of consistency can be
procedures, high availability and
guaranteed. scalability, mixed workload isolation
and separation, no need for standard
AVAILABILITY – HOW ETL systems, and multiple (tunable)
consistency levels that allow the
ACCESSIBLE IS THE DATA? developer to decide on the consistency
on a per-query basis.
Everyone wants access to their data at all times,
no matter if there are database failures, power
outages, node crashes, or other hardware and
software complications; read and write operations must continue. Executives want constant
access to their critical files; clients need continuous email communication; web-based billing
modules need to work 24/7 or sales suffer; corporate reporting databases are needed
around-the-clock for global operations to carry on. Availability is not a luxury; it’s a necessity
for all modern enterprises. The IEEE 610 definition of availability is “the degree to which a
system or component is operational and accessible when required for use by an authorized
user.”10 Availability is not guaranteed through a specific piece of software or hardware, but
is rather a set of intentions and strategies used to reach the intended percentage value of
downtime for software and hardware systems (though many systems give availability ratings
to their products, to entice potential customers to purchase them).

©2013 DATAVERSITY Education, LLC. All rights reserved. 9

Availability is usually given in a numeric percentage that relates the availability level to the
amount of expected downtime per year for the software or hardware system – the goal of
course is 100%, but that is unrealistic, so the real target is referred to as the five nines, or
99.999% availability.

AVAILABILITY LEVEL11 ESTIMATED DOWNTIME PER YEAR

99.999% 5 minutes
99.99% 52 minutes
99.9% 8.5 hours
99% 3.5 days or about 87 hours

Planned downtimes can often be alleviated through process management planning. If an

upgrade is needed, then certain systems can be taken off line while others remain live, and
then they can be switched. Or the most important systems can be taken down only during
low activity times. Planned downtimes are not the biggest issue here. IT departments are well
versed in dealing with planned events; its unplanned downtimes that the availability model
seeks to ameliorate. The redundancy built into
distributed systems helps to increase the inherent
reliability of the entire system. Yet as availability
increases, some other aspect of Brewer’s Theorem REAL-WORLD DATABASE
may decrease – the question is whether to lose EXAMPLE 5:
consistency or partition tolerance or use a different Neo4j is a reliable, fully ACID
alternative. compliant graph database. It
offers massive scalability, and high
availability when distributed across
PARTITION TOLERANCE many systems. It contains a transversal
– FUNCTION WITHOUT framework for easy and fast graph
queries, and has a convenient REST
COMMUNICATION? interface or object-oriented Java API.
Its easy-to-implement graph structure
The third and final characteristic of CAP relates to
allows the simple storage of data in a
availability in many ways, but looks at the problem highly accessible environment.
of failures and disaster recovery in a different light.
Where availability seeks to lessen the impact of
downtime on a given system, partition tolerance

©2013 DATAVERSITY Education, LLC. All rights reserved. 10

deals with the distribution of data over many
different partitions, in many different database
replicas. One of the biggest issues in distributed REAL-WORLD DATABASE
computing is the fact that data is often stored EXAMPLE 6:
in multiple partitions, throughout many nodes,
The InfiniteGraph graph database offers
across data centers that are not geographically flexible consistency models from ACID
related. A given write can happen in one replica to eventual for various transactions.
in Virginia, while next being written to another It provides scalability across large
replica in India, and these operations must distributed networks, concurrency,
continue. The system must be able to tolerate the straightforward replication and backup,
multiple supported APIs, hybrid
possibility that these two replicas could at any
schema models, predictive language
given time – temporarily or permanently – not qualification queries, and fully atomic
communicate with each other, and that nodes can transactions.
be added or taken off line without a disruption.

Two substantial Cloud-based systems that

require partition tolerance due to extensive,
geographically distributed replica locations are Amazon’s SimpleDB and Google’s BigTable;
they both helped to transform the entire industry, and both had to make concessions during
development. SimpleDB provides robust fault-tolerance, with high availability, scalability,
and eventual consistency (it can provide consistent or eventually consistent reads), but not
strong consistency. Google’s BigTable is a column-oriented database that allows for an
unlimited number of columns; it was designed for massive scalability and high availability.
It has single-row transaction consistency, so can assure eventual consistency with updates,
and strong consistency in certain transactions.12 Each system needed to conform to the
requirements of considerable geographical distribution, so had to relax some constraints in
lieu of others – such are the realities of design.

THE COMPROMISE – CAN YOU HAVE ALL THREE?

The downside to this entire discussion is that in the early years of development, no grand
utopian vision existed; there were tradeoffs no matter what model was used (and in many
systems there still are):

©2013 DATAVERSITY Education, LLC. All rights reserved. 11

 • Consistency and Partition Tolerance forfeited Availability

• Availability and Consistency forfeited Partition Tolerance

• Availability and Partition Tolerance forfeited Consistency

Brewer listed a number of examples of each possibility, their traits, and some of the tradeoffs
that system designers must contend with in his paper. Some are listed below13:

SELECTION CHARACTERISTICS EXAMPLES

Single-site databases
2-phase commits Cluster databases
C + A (No P) Cache validation protocols LDAP
xFS file system

Pessimistic locking Make Distributed databases

C + P (no A) minority partitions Distributed locking
unavailable Majority protocols

Expirations/leases Coda
A + P (no C) Conflict resolution Web caching
Optimistic DNS

In terms of modern, horizontally-scaled systems prevalent in a web-based environment, the

decision often comes down to Consistency and Availability. Partition Tolerance is a must in
a distributed node environment, since a primary element of the entire system is grounded
on partitioned data. Developers must decide which operations can relax consistency and
which operations can relax availability. While every system is different and dependent on
innumerable factors, most large-scale, web-centric systems have decided to relax consistency
in some form, and push for high availability.

The original development of Cassandra by Facebook14 was due to a need for decentralized
control of data so there would be no single failure point, multi-data-center replication potential
across a massive distributed system, constant scalability requirements with the need for no

©2013 DATAVERSITY Education, LLC. All rights reserved. 12

downtime when new machines were added, high availability of data 24/7/365, MapReduce
capability, and differing levels of consistency due to their highly variable data types. So
they ultimately balanced the entire system with tunable consistency (an essential attribute in
Cassandra), with massive scalability and high availability. They released Cassandra as an
open source platform in 2008; it is now a principal NoSQL platform throughout the industry.

Some of the latest innovations in the industry are allowing organizations to alter some of the
original assumptions along the ACID/BASE/NoSQL continuum though. As mentioned within a
few of the sidebars, there are now platforms that allow varying levels of consistency depending
on the transaction – if one transaction needs ACID constraints, that can be programmed into
the system, while those that can relax consistency are allowed to do so. It is possible to scale a
system to literally “hundreds of terabytes of source data while maintaining sub-second query
response time,”15 and still have the support of full ACID properties as well. There doesn’t
have to be a loss performance either, and high availability along with a schema-agnostic
structure maintains inherent flexibility within the entire system. Such innovations are certainly
not commonplace, but they are now available for organizations that require such innovation,
with more under development all the time.

CONCLUSION - BUSINESS CONTINUITY IS ESSENTIAL

The crucial question of ACID versus BASE, the implementation of relational versus non-relational
data stores, consistency versus availability, all hinges on one primary element: success in the
marketplace. It doesn’t matter if an organization’s developers are fawning over the possible
integration of a new NoSQL-based system if it is an unnecessary or untenable addition to a business
that still only requires a relational platform. Certainly, development planning for the future must
include an IT strategy that focuses on growth, flexibility, security, and cost. The exponential growth
of data, and its subsequent collection and analysis, are mitigating factors that now require many
organizations to adopt a Big Data solution, with some kind of NoSQL platform as its foundation.
Yet, the exact design of that solution, and its countless considerations are entirely dependent
on the needs of the enterprise: server virtualization, the impact of Cloud-based services, data
center utilization and consolidation, more efficient application performance, streamlined data
governance processes, hardware costs, and a host of other issues ultimately govern the decision
to implement a NoSQL solution and what that solution will mean to the organization.
Much of the financial industry still requires strict ACID compliance for absolute transaction

©2013 DATAVERSITY Education, LLC. All rights reserved. 13

integrity in all banking operations, as do many military and other governmental organizations;
the same could be said of the health care industry, especially regarding patient records. An
online travel service may be able to relax consistency during the search process through
various soft state protocols and updating mechanisms so that higher availability can be
ensured. A social networking site that starts small, but plans on exponential growth, would
want to implement a system with availability and scalability in mind from the beginning,
and may decide to use some sort of eventual or tunable consistency with various user “click
traffic” that doesn’t require strict consistency.

The multitude of options available in the marketplace makes deciding on a specific NoSQL
solution challenging. Do you need a graph database or document store? Key-value store
or columnar database? What sort of executive support is there for the project? Is it an
enterprise-wide implementation, or only for a small program to begin with? Will outside
consultants be necessary? What about application programmers? Should the solution be
developed in-house, or should an off-the-shelf solution be purchased? These questions and
innumerable others will decide the fate of a particular solution. But in the end, the need
for such a solution distills down to one essential factor: the need to remain innovative and
flexible in an ever-changing business environment. ACID and BASE are just clever acronyms
for complex problems. Luckily for modern organizations. there are myriad solutions for those
problems. Which one works best for you?

©2013 DATAVERSITY Education, LLC. All rights reserved. 14

NOTES

1 Grey, J. (June 1981). The Transaction Concept:

Virtues and Limitations. Tandem Computers Incorporated. Retrieved from
[Link]

2 Lindsay, B.G., Selinger P.G., Galtieri, C., Gray, J. N., Lorie, R. A., Price, T. G., Putzolu, F., Traiger, I. L.,
Wade, B. W. (July 1979) Notes on Distributed Databases. Cambridge University Press. Retrieved from
[Link]
/$File/[Link]

3 Reuter, A., Härder, T. (December 1983) Principles of Transaction-Oriented Database Recovery.

Computing Surveys. Retrieved from
[Link]

4 Pritchett, D. (2008). BASE: An Acid Alternative. Retrieved from

[Link]

5 Strozzi, C. (1998). NoSQL: A Relational Database Management System. Retrieved from

[Link]

6 McCreary, D. and McKnight, W. (June 2012). The CIO’s Guide to NoSQL. Retrieved from http://
[Link]/the-cios-guide-to-nosql-3. And, Haugen, K. (2010). A Brief History of NoSQL.
Retrieved from [Link] [Link].

7 Dr. Brewer, E. A. (July 2000). Towards Robust Distributed Systems. ACM Symposium on the
Principles of Distributed Computing. Retrieved from
[Link]

8 Ibid.

9 Terry, D. (October 2011) Replicated Data Consistency Explained Through Baseball. Microsoft
Research. Retrieved from [Link] And,

©2013 DATAVERSITY Education, LLC. All rights reserved. 15

Strauch, C. (2012). NoSQL Databases. Stuttgart Media University. Retrieved from
[Link] And, Burckhardt, S., Leijen, D., Fähndrich, M., Sagiv, M.
(2012). Eventually Consistent Transactions. Springer-Verlag. Retrieved from
[Link] And, Wada, H., Fekete, A., Zhao, L.,
Lee, K., Liu, A., (January 2011). Data Consistency Properties and the Trade-offs in Commercial Cloud
Storages: the Consumers’ Perspective. Retrieved from
[Link]

10 [Link] (Institute of Electrical and Electronics Engineers). Retrieved from

[Link]

11 FAQ on High Availability (July 2012). Fujitsu Technology Solutions. Retrieved from
[Link] And, Microsoft
High Availability Overview (January 2008). Retrieved from
[Link]
Microsoft%20High%20Availability%20Strategy%20White%[Link].

12 Ramanathan, S., Goel, S., Alagumalai, S. (November 2011). Comparison of Cloud Database:
Amazon’s SimpleDB and Google’s Bigtable. International Journal of Computer Science. Retrieved from
[Link]

13 Dr. Brewer, E. A. (July 2000). Towards Robust Distributed Systems. ACM Symposium on the
Principles of Distributed Computing. Retrieved from
[Link]

14 Lakshman, A., Prashant, M. (2009). Cassandra - A Decentralized Structured Storage System.

Retrieved from [Link]

15 Hunter, J. (2013). Inside MarkLogic Server: Its data model, indexing system, update model, and
operational behaviors. Retrieved from [Link]

©2013 DATAVERSITY Education, LLC. All rights reserved. 16

SPONSOR PAGE

[Link] | sales@[Link] | +1 877 992 8885