2012 15th International Conference on Network-Based Information Systems
Database Research: Are We At A Crossroad?
Reflection on NoSQL
Maria Indrawan-Santiago
Faculty of Information Technology
Monash University
Melbourne, Australia
maria.indrawan@monash.edu
Abstract — The demand to process large sets of data has
increased in the last few years from both the scientific and
business community. To serve this demand, a number of new
databases have been introduced that are not based on
relational models. This group of databases is popularly known
as NoSQL. The underlying data and transaction models in the
NoSQL are different from relational databases. Much interest
has been placed by organizations in adopting this new
technology and has created a buzz in database research. The
fact that the underlying principles are different to relational
models has placed a dilemma in the database research
community. Would this new technology change the shape of
database research and industry?
Keywords; database, noSQL, key-value pair, business analytics
I. INTRODUCTION
The database industry in the last few years has seen a
number of non-relational DBMS introduced, such as
MongoDB[21], Riak[32], Neo4J[22]. These families of
database are popularly known as NoSQL databases. There
are many debates over the roles of these databases in serving
our information needs. The pro-NoSQL camp claims that
this technology is a future of database [20]. On the other
hand, the pro relational database camp claims that the
NoSQL database has a major drawback of not providing
strict treatment of data integrity [7]
This paper attempts to navigate the roads of current
database research by exploring the technology and impact of
NoSQL databases as the new kid on the block of database
research. This exploration starts by looking at the trends in
database research in the last 40 years since introduction of
the relational database. Analysis of the different groups of
NoSQL is given in section 3. Each of the groups will be
compared on the data model, database transaction model and
data analytics.
II. POST RELATIONAL DATABASE ERA
Relational model was introduced in 1970 by E.F. Codd
[8]. It was introduced to overcome some problems with
database systems associated with network and hierarchical
models. A major drawback perceived by practitioners of
hierarchical and network models was their minimum support
of data independence [9]. Hence, complex programs were
often written to answer a simple query. From academia
perspective, the network and hierarchical model were
inadequate since they did not have accepted theoretical
foundation. When E.F. Codd introduced relational model in
978-0-7695-4779-4/12 $26.00 © 2012 IEEE 45
DOI 10.1109/NBiS.2012.95
1970, there was acceptance from the academic community,
however, practitioners were skeptical of the performance of a
relational database compared to the existing network and
hierarchical database systems [28]. The adoption of this type
of database was very low until the introduction of System R
in the 80s [4]. In the early 80s, relational DBMS grew very
competitive and became the dominant player in database
markets to date.
Since the introduction of the relational model, there were
a few database models introduced such as the object oriented
database, object relational database and XML database. The
object oriented and object relational databases were
introduced as the object orientation approach for software
engineering gained momentum in the 90s. However, these
databases never really become competitive in the
marketplace. The reasons could be summarized in its lack of
theoretical foundation and its limited performance gained
over the relational database [6]. The XML database suffers
challenges similar to OODB. It aims to support the
proliferation of XML documents, however, adoption of a
native XML database is very limited. Major relational
database vendors such as Oracle, Microsoft and MySQL
have included XML support for their products, but native
XML database such as Tamino [29] has not captured much
share of the database market. Initial excitement for the XML
database may be attributed to the ever increasing web
applications and service orientation architecture that uses
XML as a means to standardize its data exchange format. On
the surface, there seems to be many data being used in XML
format, however, when it comes to storing the data, the
format is reverted back to a relational model. XML does not
have a strong theoretical foundation that can guarantee data
integrity to the same level that relational models can offer.
In the last few years, a new group popularly known as
NoSQL databases has emerged. Their origin can be traced
back to the introduction of BigTable [26] and MapReduced
[27] by Google in 2006 and 2004 respectively. The buzz is
still high on this new technology. While a number of these
database systems have been introduced to the market, there
are still not enough reports on the adoption rate of this new
technology in the database market. The technology could
still be on climbing slope from the first phase of hype cycle
[13]. It is interesting to note that the hype of this technology
comes mainly from the industry since so much of the
information on the technology is available on blogs and
opinion pieces. There are limited academia based papers on
this topic. The discussion on this technology is presented
next.
III. NOSQL DATABASES
A. Background
The relational database was popular in the 70s and 80s
because the majority of data processing needed was
commercial data processing, also known as Online
Transaction Processing (OLTP). Stonebraker and Cattell [30]
suggest that this type of data processing is characterized by
simple operation with focus on writing to the database. Other
applications such as data warehousing require complex
operation and read-focus processing. The social networking
applications, such as Facebook and Twitter, sit somewhere in
between OLTP and data warehousing. For these types of
applications (non-traditional OLTP), NoSQL movement has
gained strong support because these applications have
pushed the limit of relational databases on its flexibility and
scalability. Other factors influencing the developments of
this family of database include [2]:
• Big Data
There is an increasing need to manage ‘big data’
both in the commercial domain with the
proliferation of Web 2.0 applications and in the
academia with e-science applications. When dealing
with large amounts of data in relational database,
operations such as join would become
unmanageable. For some applications that query
mainly single rows across many attributes/columns,
it will be more practical to group together columns
that would otherwise spread over different tables in
a relational database.
• Data as Profit Maker
Business organizations have developed confidence
in data as a profit generator. Data capture,
integration and analysis have become keys to
business success and profit rather than a mere
business operation cost that needs to be minimized.
It gives the rise to the importance of business
analytics and to some extent the ad-hoc business
analytics. Supporting ad-hoc business analytics
requires flexibility in the schema support underlying
the enterprise’s view of data.
• Mixed-Structured Data
Many organizations face the challenge to manage
both structured and unstructured data in their daily
operations. In many cases, the unstructured data
was ‘massages” into the structured schema and
implemented in relational databases that support
unstructured data type such as blob. During the
retrieval, the blob then needs to be post-processed to
extract the content. It imposes two steps processing.
• Architectural Shift in Computing
Access to parallel computing has been made
available to the wider community with the advent of
cloud computing. Many organizations that did not
have access to such computing facilities are now
capable of parallel computation. From individual
46
machine design, there has been a shift in focus from
increasing a clock speed per chip to providing more
processor core and threads per chip. These
developments encourage the development of
database models that can exploit parallel
computation.
Based on the aforementioned factors, NoSQL databases
were designed and developed. In general, NoSQL databases
are defined by the following characteristics:
• Non relational model
The limitations of relational model in supporting big
data and mixed-structured data are one of the main
reasons in the introduction of NoSQL.
• Designed for distributed processing and horizontal
scalability
The shift in the computer architecture development
supports the need to have a database that is scalable
horizontally and be processed in distributed manner.
• Allow less strict adherence to schema
Weak or schema-less data warehousing is perceived
as an advantage in supporting ad-hoc business
analytics query.
• Less strict adherence to consistency
ACID (atomicity, consistency, isolation and
durability) properties for database transaction put
consistency of data as its first citizen. However,
implementing this principle in distributed processing
and at the same time delivering quick response to the
query is very difficult to achieve. To enable
processing of large amount of data in distributed
environment, relaxing the requirement of
consistency or ACID properties become a design
choice in NoSQL database.
Two fundamental differences between relational and NoSQL
databases based on the characteristics described above are
the data model and the treatment of consistency. In the next
sections, the different data models for NoSQL and the
different transaction models are presented.
B. Transaction Models.
Relational database uses the ACID properties to ensure
integrity of data in the database. The concept is implemented
by means of a lock mechanism. NoSQL databases consider
the requirement of ACID properties to be too restrictive and
impossible to achieve in distributed environments, as
suggested initially by Brewer’s theorem on CAP
(consistency, availability and partition tolerance) [14] and as
later expanded into PACELC (partition, availability,
consistency, else, latency, consistency) [1]. Brewer’s CAP
theorem states that a designer of distributed database systems
has to choose two of the three CAP properties. Fig 1 depicts
relations between consistency, availability and partition
tolerance. For example a CP-based distributed database
system will trade availability to make sure the database
based is consistent when partition is introduced to the
database. A PA-based would favour availability over
consistency when the database is partitioned. A CA-based
would mean that consistency and availability are paramount
and it is achieved by not introducing partition.

Availability
PA
CA
Partition Consistency
CP
Figure 1. Brewer’s theorem
The PACELC model suggests that the tradeoff between
consistency and availability is not solely based on partition-
tolerance, but also on the existence of a network partition
itself.
“If there is a partition (P), how does the system trade off
availability and consistency (A and C); else (E), when the
system is running normally in the absence of partitions, how
does the system trade off latency (L) and consistency (C)?”
In addition to the tradeoff among three CAP properties, the
PACELC model, as depicted in Fig. 2, suggests that latency
is an important factor to consider as most distributed
database systems use replication to ensure availability.
Consistency
Latency
Parittion
Availability Consistecy
Figure 2. PACELC model
An alternative protocol based on the principle of CAD
called BASE, Basically Available Soft-State services with
Eventual Consistency, was introduced by eBay to replace
Two-phase-commit protocol [24]. It aims to support partial
failure so that total system failure can be avoided. In other
words, BASE focuses on the availability rather than
consistency of the database. BASE can be considered to take
an optimistic approach to consistency compared to the
pessimistic view of ACID-based protocol. By taking an
optimistic approach, BASE allows best effort and
approximate answers to exist in a database transaction state.
This creates a soft state that needs to be managed carefully
47
by applications before state of full consistency is eventually
reached. If the soft states in the database transaction are
recognized and pattern of these transactions are detected,
applications can be designed to be aware of these patterns
and manage the soft states accordingly. In the eBay’s
implementation of BASE, a message queue concept is used
to eventually resolve possible conflicts that may rise during
the soft state of transaction.
C. Data Models
1) Key Value Pair
The idea of key-value pair has existed in computing for
many decades, it is a common data structure or concept used
in the development of file systems. In this type of database,
data is stored as a pair of key and value. Each of the keys is
unique in a collection. Access to the values is achieved by
means of key-value association. The keys needs to be kept in
a data store that can be quickly accessed, for example a hash
table. The binding from key to the values varies depending
on the programming language used. The values do not
necessarily contain raw data, it can contain another set of
keys which makes cardinality of the value become one of the
major decisions in designing a key-value database. What
would the values represent in the database? Is it going to be
attribute, entity or another key?
One interesting concept that may be too radical for
someone who follows relational databases religiously is the
key-value treatment of consistency. In a key-value database,
it is acceptable to have two different values of data at read
time, which implies non-consistency in relational database
theory. The inconsistency in the data is left to the application
program or client to solve. Eventually the inconsistency will
be removed from the database following a procedure adopted
by DBMS. The inconsistency is the cost that application
needs to pay as a tradeoff to availability and/or latency as
described in the transaction models. In general, key-value
pair databases are suitable for applications that process a
single-key transaction and perform a lot of reading. An
example of such applications would be generating product
catalogues on-the-fly. For this type of application the key-
value pair database can produce high throughput and low
latency performance.
2) Column-Family
Column-family database could be considered as a
specific type of key-value pair model. A column family
database defines the structure of the values as predefined set
of columns, hence the name column-family. The definition
of the column family could be considered as the schema of
the database. The main driver of this approach is the
Google’s HBase [15]. This data model could be one that
confuses many who are familiar with relational model due to
the same naming of its components. Column-family
databases are made up of column, column family and super
column.
• Column
A column is an atomic unit of information supported by
the database. It is expressed as a pair of name and value.
• Super-column
 Super columns group together associated columns that
would be retrieved together from disk or have semantic
association. It is useful for modeling complex data types
such as address.
• Column Family
A column family groups columns and super columns
together into a highly structured data. It is the closest
resemblance of table in relational model.
Consider a sample data containing personal details as
depicted in Table I. The data can be represented in a
column-family database to have:
• Super-columns of personal data and demographic.
• Columns of name, address, birthdate, gender.
• Column family of person and identify by key of
PersonID.
TABLE I. COLUM-FAMILY EXAMPLE
Row key Personal Data Demographic … high-level query language.
PersonID Name Address Education Gender
1 Smith, H Rome Master F IV.
2 Jones, S NY PhD M
3 Chin, P Sydney Bachelor F In this section, a sample of these DBMS is presented.
4 Santos, J Lima PhD F The list is not meant to be exhaustive, its purpose is to
The structure of super-columns and column family
determines the schema for the database. However, it is not
strictly fixed. A new column or super column can be added
to the design with ease when the database is already in
production. As another important different between column
family and relational database, each row in the column
family database does not need to be of the same degree, i.e.,
it can have variable number of columns/super-columns.
Hence, column family will be very effective in supporting
highly sparse data collection.
3) Document
A document database uses the concept of key-value pair
to store data. However, it imposes some structure on how the
value is stored. Unlike the column-family that stores the
values in a family of columns, the document database stores
the values in a document-like structure such as XML or
JSON. Hence, it provides more information about the
structure of the data compared to key-value oriented
databases and the structure can be exploited to serve more
query types. In the key-value databases, only query by key or
key range is possible.
4) Graph Database
A graph database is a database that uses graphs as the
means to represent its schema.
The graph database differs from relational database on its
treatment of relationship. In relational database, what matters
are tuples and its collection called relation. The relationship
between individual tuple is implicitly defined by means of
foreign key and primary key. In a graph database, both
48
relationships and relations matter. For some applications
such as social network, depicting the relationship between
each entity is important. The popularity of social networks
has contributed to the resurrection of graph database research
that was active in the 80s and early 90s [3].
D. Business Analytics.
NoSQL databases were designed to support availability
of data to end-users rather than to help gathering of business
data for decision making. Hence, at this stage of NoSQL
development, there is very limited number of querying
support for business analytics applications. HIVE [16] and
PIG [23] are examples of available querying applications run
on top of map-reduced framework. Unlike relational model
based business analytics that support non technical savvy
personnel to interrogate the database for some intelligence,
ad-hoc query in NoSQL database demands skilled
programmers to code the query as many of the available
database only provide API as interface and they do not have
COMPARISON OF NOSQL DATABASES
highlight the different characteristics described in the
previous section. The DBMS were chosen because they are
either one of the first of its category or the leader in its
category. These DBMS are compared based on data model,
transaction model, license, indexes, and sharding.
• Data Model
The supported model in the database that could be
one of key-value pair, column-family, document or
graph.
• Transaction Model
The database priority in selecting the trade-off based
on the CAP and PACELC models.
• License
The type of license for the software.
• Ad-hoc Query
Indication of whether the DBMS support ad-hoc
query. If it is supported, what technique or
programming language is used to write queries.
• Indexes
Indication of whether the DBMS supports automatic
maintenance of secondary indexing, in contrast to,
applications-managed secondary indexes.
• Sharding
Indication of whether the DBMS support automatic
sharding. That is, the ability of DBSM to
automatically re-distribute data and replications
across servers when there is a change in resources
such as addition or removal of servers.
 TABLE II. NOSQL DATABASES COMPARISON

Database Data model Transaction Ad-Hoc query License Indexes? Sharding?

CAP PACELC
Cassandra[19] column- PA EL HIVE, PIG Open-source(Apache) N Y
family
CouchDB[10] document PA EL Lucene, Cloudant Open-source(Apache) Y N
DynamoDB[11] key-value PA EL Built-in API Commercial
Hbase column- PC EC HIVE, PIG Open-source(Apache) N
family
MongoDB[21] document PA EC BSON based GNU Affero General Y Y
format Public License
(database), Apache
(language drivers)
Neo4j[22] graph CA EC Chyper Open-source (GNU N N
Affero General Public
License) and
commercial
RavenDB[25] document ACID Limited, built-in Open-source and Y Y
commercial
Riak[32] key-value PA EL CorrugatedIron Open-source(Apache) Y Y
Tokyo Key-value PC EC No GNU Lesser General N N
Cabinet[17] Public License
Voldermort[31] key-value PA EL No open-source Y Y

Many of the products listed in Table II were developed

by companies that have large data storage requirements, such
Cassandra for Facebook, Voldermort for LinkedIN,
DynamoDB for Amazon, HBase for Google and Tokyo
Cabinet for the Japanese version of Facebook from Mixi Inc.
The development was a necessity for the operation of their
business. Other database systems such as MongoDB, Riak
and Neo4j, were developed as service to other organizations
as the providers see the potential in investing in the new
technology. This group of DBMS was released after the in-
house built group.
It is interesting also to see that many of the available
databases have open-source license, except DynamoDB,
Neo4j and RavenDB. DynamoDB is available for Amazon
Webservice users with some tier pricing. The Neo4j and
RavenDB provide different licensing for different levels of
service/product.
In terms of the transaction model, most of the databases
give priority to availability over consistency (PA) according
to CAP model, except HBase and Tokyo Cabinet that prefer
a PC model. Tokyo Cabinet’s performance is comparable to
the PA system in terms of availability for small to medium
data sets [17]. Most of the PA system under the CAP model
tends to select EL model in the case of non-existing network
partition with the exception of MongoDB and Tokyo
Cabinet. These two databases can be considered to support
more of consistency compared to the PA/EL systems. Unlike
the rest of the database that does not support ACID,
RavenDB supports ACID for transactions based on the key-
value. It falls back to BASE protocol when transactions
involve secondary indexes.
NoSQL database was designed to handle large volumes
of data processing by removing some supports that existed in
RDBMS. One of these supports is ad-hoc query. Although
many of the databases listed in Table II has support for ad-
hoc query, the level of programming expertise in writing this
ad-hoc query is much higher than that of RDBMS. In
addition, ad-hoc query in NoSQL database is usually
performed in non-key data. Ad-hoc query on non-key item
would cause the system to perform poorly or would not be
available to DBMS that does not support secondary
indexing. Ad-hoc query is well supported in relational
DBMS due to data independence concept and query
optimization, two concepts that are hardly supported in
NoSQL. The structure of the database is designed by
considering the most efficient access path used by critical
queries. Selection of access path is very dominant in the key-
value and column-family. The limitation of ad-hoc query
support will limit the use of data from NoSQL database for
OLAP and data warehousing applications. This limitation
will provide a challenge to researchers in finding a new
model and/or techniques to support business analytics from
NoSQL data.
The ability of optimizing the resource allocation in a
distributed environment through the management of
expansion and contraction of available resources is an
important feature in NoSQL DBMS. With the changes in
available resources, it is possible to automatically re-
distribute the data or to have different shards of data. This
ability is important to the performance of the database
because it influences the latency of the system. There are

49
several DBMS listed in Table II that support automatic
sharding such as Cassandra, MongDB, RavenDB and Riak.
From the four data models, the graph data model is the one
with the most challenges in supporting sharding. There is no
support for sharding in graph databases at this stage,
although some initial development has taken place. [18].
V. CONCLUSION
We have explored and compared different types of
NoSQL databases. Two main drivers for these databases are
the needs of many organizations to process large amounts of
data which in some cases has no obvious tabular structure.
The solutions proposed for these drivers are new data models
that are non-relational for distributed data processing.
Although it is considered a new model in the database
domain, these new models are being developed based on
existing and known theory. For example, the idea of key-
value stored is a known data structure and has been used in
many file systems. What makes the development of these
databases novel is its design of the DBMS to support
horizontal scale-up. This is done by relaxing ACID protocol
and building a protocol that allow eventually consistent state
in the database. Availability is the main concern, not
consistency. This departs far from relational database that
put consistency as its main focus. So, are we at a crossroad?
Not exactly.
The two camps of relational and non-relational (NoSQL)
are like two different roads to go to the same destination. It is
like having Route 66 and interstate highways. The route 66 is
a well known route, may be more scenic, offer multiple stops
and may be a bit slower. On the other hand, interstate
highways can make the trip faster, but only when all
interstate highways are developed, coordinated and the roads
are designed to handle the volume and rate of traffic.
There are still many open challenges in making NoSQL
databases become a mainstream solution. The challenges
come from three different domains, research,
adoption/development and end-user. From research
perspective there are still problems to solve such as:
• Understanding latency and its influence in the
overall design and performance of a database. The
PACELC is a step in the right direction. But a model
with strong theoretical foundation on understanding
latency is still needed so that a new architecture of
DBMS can be designed accordingly.
• Sharding for graph database. Unlike most of the
other models, graph database has mutable structure
during run time hence it is difficult to design a
sharding algorithm than provide high elasticity.
• Support for ad-hoc query is still limited in many
systems, hence support for OLAP or data
warehousing queries is still very limited. There is a
need to find a new model of business analytics or a
way to provide simple interface for decision makers
to perform ad-hoc query.
• Unlike relational models, NoSQL does not have a
strong theoretical background to the model, hence
developing a set of methodology for database design
50
is challenging. Currently, to the author’s knowledge,
no data modeling technique has been prescribed as a
method to perform database design for the different
data models.
• A new model with the support of a strong theoretical
foundation that works well on a large distributed
data set.
NoSQL database was designed to overcome limitations
of relational database in supporting distributed processing of
data. Hence, some important aspects that are important in a
relational database may not be relevant in NoSQL, for
example, query optimization. A query optimization engine is
included in RDBMS because relational models impose data
independence and provide high level support of ad-hoc
query. In NoSQL databases, the query is implicitly
optimized during the design of the database by considering
the type of distributed architecture available and pattern of
queries to be supported. It does not aim to be very flexible in
serving ad-hoc queries as in a relational database.
Nevertheless, there is a need to serve ad-hoc query more
efficiently, but the approach should be different from query
optimization in relational database.
From the point of view of adoption and development, it is
important to educate the CTOs on the strength and
weaknesses of NoSQL database. These databases should be
seen as a complimentary solution to data management
problem in the organization to relational database, not as a
replacement. It is important to understand operational
patterns in the organization to allow the development of best
practices and methodologies that appropriate for NoSQL
database design and implementation. Without design tools, it
will be difficult for this new technology to get mass adoption
in the marketplace.
Many relational database end-users will find NoSQL to
be difficult to use as building queries in NoSQL requires
more sophisticated programming skills. Providing a high-
level query language will be important for the acceptance of
this technology by the end-users. It is important to also
educate them that ad-hoc query may take longer in NoSQL
compared to relational database, hence their way of defining
their information needs may need to be altered. It should be
defined earlier during the development of the database rather
than later during the operational stage of the database.
NoSQL will not replace the relational database
completely. Instead, it is complementary to relational
databases in providing enhanced data management capability
within an organization.
[1] D.J. Abadi, "Consistency Tradeoffs in Modern Distributed Database
System Design: CAP is Only Part of the Story," Computer, vol. 45,
no. 2, pp. 37-42, Jan. 2012
[2] R. Agrawal, A. Ailamaki, P. A. Bernstein, E. A. Brewer, M. J. Carey,
S. Chaudhuri, et.al.. The Claremont report on database research.
SIGMOD Rec. 37, 3 (September 2008), 9-19
[3] R. Angles and C. Gutierrez. 2008. Survey of graph database models.
ACM Comput. Surv. 40, 1, Article 1 (February 2008), 39 pages.
[4] M. M. Astrahan, M.W. Blasgen, D. D. Chamberlin, K. P. Eswaran, J.
N. Gray, P.P. Griffiths, W.F. King, R.A. Lorie, P.R. McJones, J. W.
Mehl, G.R. Putzolu, I.L. Traiger, B.W. Wade, and V. Watson. 1976.
 System R: relational approach to database management. ACM Trans. [18] http://jim.webber.name/2011/02/16/3b8f4b3d-c884-4fba-ae6b-
Database Syst. 1, 2 (June 1976), 97-137. 7b75a191fa22.aspx
[5] http://ayende.com/blog/tags/nosql [19] A. Lakshman and P. Malik. 2010. Cassandra: a decentralized
[6] S. Bagui: “Achievements and Weaknesses of Object-Oriented structured storage system. SIGOPS Oper. Syst. Rev. 44, 2 (April
Databases”, in Journal of Object Technology, vol. 2, no. 4, July- 2010), 35-40
August 2003, pp. 29-41 [20] N. Leavitt; , "Will NoSQL Databases Live Up to Their Promise?,"
[7] http://cacm.acm.org/blogs/blog-cacm/99512-why-enterprises-are- Computer , vol.43, no.2, pp.12-14, Feb. 2010.
uninterested-in-nosql/fulltext [21] http://www.mongodb.org/
[8] E.F. Codd. 1970. A relational model of data for large shared data [22] http://neo4j.org/
banks. Commun. ACM 13, 6 (June 1970), 377-387. [23] http://pig.apache.org/
[9] T.M. Connoll and C.E. Begg, Database Systems: A Practical [24] D. Pritchett. 2008. BASE: An Acid Alternative. Queue 6, 3 (May
Approach to Design, Implementation and Management, 4th ed., 2008), 48-55.
Addison Wesley, 2005.
[25] http://ravendb.net/
[10] http://couchdb.apache.org/
[26] http://research.google.com/archive/bigtable.html
[11] G. DeCandia, D. Hastorun, M. Jampani, G.Kakulapati, A. Lakshman,
[27] http://research.google.com/archive/mapreduce.html
A. Pilchin, S.Sivasubramanian, P. Vosshall, and W. Vogels. 2007.
Dynamo: amazon's highly available key-value store. In Proceedings [28] A. Silberschatz, H.F. Korth., and S. Sudarshan, Database System
of twenty-first ACM SIGOPS symposium on Operating systems Concepts, 5th ed., McGraw Hill. 2006.
principles (SOSP '07). ACM, New York, NY, USA, 205-220. [29] http://www.softwareag.com/Corporate/products/wm/tamino/default.a
[12] http://fallabs.com/tokyocabinet/ sp
[13] J. Fenn. and M. Raskino, Mastering the Hype Cycle: How to Choose [30] M. Stonebraker and R. Cattell. 2011. 10 rules for scalable
the Right Innovation at the Right Time, Harvard Business Press, performance in 'simple operation' datastores. Commun. ACM 54, 6
2008. (June 2011), 72-80.
[14] S. Gilbert and N. Lynch. 2002. Brewer's conjecture and the feasibility [31] R. Sumbaly, J. Kreps, L. Gao, A. Feinberg, C. Soman, and S. Shah.
of consistent, available, partition-tolerant web services. SIGACT 2012. Serving large-scale batch computed data with project
News 33, 2 (June 2002), 51-59. Voldemort. In Proceedings of the 10th USENIX conference on File
[15] http://hbase.apache.org/ and Storage Technologies (FAST'12). USENIX Association,
Berkeley, CA, USA, 18-18.
[16] http://hive.apache.org/
[32] http://wiki.basho.com/
[17] http://www.igvita.com/2009/02/13/tokyo-cabinet-beyond-key-value-
store/

51