Non-relational Parallel Database Machines

While open research issues remain in the area of parallel database machines
for relational database systems, building a highly parallel database machine for
an object-oriented database system presents a number of new challenges.
One of the first issues to resolve is how declustering should be handled. For
example, should one decluster all sets (such as set-valued attributes of a 
complex object) or just top-level sets? Another question is how should inter
object references be handled. In a relational database machine, such references
are handled by doing a join between the two relations of interest, but in an
object-oriented DBMS references are generally handled via pointers.
In particular, a tension exists between declustering a set in order to parallelize
scan operations on that set and clustering an object and the objects it references
in order to reduce the number of disk accesses necessary to access the
components of a complex object. Since clustering in a standard object-oriented
database system remains an open research issue, mixing in declustering makes
the problem even more challenging.



Another open area is parallel query processing in an OODBMS. Most OODBMS
provide a relational-like query language based on an extension to relational algebra.
While it is possible to parallelize these operators, how should class-specific methods
be handled? If the method operates on a single object it is certainly not worthwhile
parallelizing it However, if the method operates on a set of values or objects that are
declustered, then it almost must be parallelized if one is going to avoid moving all the
data referenced to a single processor for execution. Since it is, at this point in time,
impossible to parallelize arbitrary method code, one possible solution might be to
insist that if a method is to be parallelized that it be constructed using the primitives
from the underlying algebra, perhaps embedded in a normal programming language.

Cloud Storage Systems

Cloud storage systems are a subset, but often also the foundation of cloud computing
systems and therefore share the properties listed above. There are a plethora of
different cloud storage services around and here again it is very hard to give an exact
definition. On one side there are services which enable the end user to store simple
files as a backup solution. On the other hand there are a lot of new database systems
which are commonly called key/value stores. The expression Key/value store is an
umbrella term for services which are often also described as document-oriented,
attribute-oriented, distributed hash table, and key/value database. All of these names
are a variation on the same theme which emphasize different aspects of these systems.
Because of the frequent changes in this field and and due to the fact that every few
weeks a new systems appears on the horizon, we will refer the reader to online lists to
see a comparison of such systems.

One of the key distinction characteristics of cloud storage systems compared to
traditional RDBMS is the different and diametrically opposed emphasis on consistency
and availability. We have already mentioned the CAP-theorem in the introduction. The
older traditional RDBMS are built around the historical basis that consistency is the
main aim to achieve in a database system. As a result they often struggle scaling up
vertically beyond a small number of server nodes. With many servers, the failure rate
increases, and by enforcing consistency the availability decreases.

Cloud storage systems on the other hand are built around the premise to be available
almost constantly and to scale out on a large number of nodes. This is necessary to
serve the needs of highly demanded web services which operate on a worldwide scale.
Yet high availability can only be achieved by cutting back at the consistency guarantee.
Instead of full ACID guarantees as traditional RDBMS most cloud storage systems
support BASE properties. BASE stands for basically available, soft-state and eventual
consistency.