somehow different than “NoSQL” databases. While “NoSQL” is much
more common to hear, “NewSQL” is the latest buzzword in the database
world. Here is one description why:
“‘NewSQL’ is our shorthand for the various new scalable/high performance
SQL database vendors. We have previously referred to these products as
‘ScalableSQL’ to differentiate them from the incumbent relational database
products. Since this implies horizontal scalability, which is not necessarily
a feature of all the products, we adopted the term ‘NewSQL’ in the new
report.
“And to clarify, like NoSQL, NewSQL is not to be taken too literally: the
new thing about the NewSQL vendors is the vendor, not the SQL.”
—The 451 Group’s Matt Aslett, as recorded at
http://blogs.the451group.com/information_management/2011/04/06/what-
we-talk-about-when-we-talk-about-newsql/An interesting development in the NoSQL world is that specifications are
being created for a new database query language called UnQL (pronounced
“uncle”), which stands for Unstructured Query Language. This is being
developed as a joint project by two developers: Richard Hipp, the creator of
SQLite; and Damien Katz, the creator of CouchDB. They expect more to join
them soon. In a nutshell, the language contains some familiar commands,
such as SELECT, INSERT, UPDATE, and DELETE. However, it is different
from SQL because these commands do not work on tables but rather on
collections of unordered sets of objects that are described using JavaScript
Object Notation (JSON). You can learn more about UnQL from the first
product we have seen that uses it at www.unqlite.org.
The sections that follow group databases by similarities in terms of a variety
of standout features. Because NoSQL databases are still fairly new, it is
unclear which, if any, will become a long-term standard. For that reason, this
chapter gives high-level coverage of a larger number of options rather than
deep coverage of a couple of primary options.
Key/Value Stores
Key/value stores are the simplest of the NoSQL databases, at least in the
sense of interactions. You have a piece of data of any type; this is your value.
You give it a name of some sort; this is your key. Any time you need that
specific piece of data, you ask for it using the key. Values might be bits of
text, binaries, pretty much anything, and the data type does not need to be
defined in advance—or perhaps even at all. The database never needs to know