A general question regarding NoSQL and SQL systems.

[krbabu]

After reading http://cacm.acm.org/blogs/blog-cacm/99512-why-enterprises-are-uninterested-in-nosql/fulltext,
I start to wonder whether any statements can be made regarding the
ACID property of hybrid systems.
Can any member of this throw some light on this matter? Thanks.

[Jak Sprats]

Hi,

I can comment.

Alchemy DB is made up of a RDBMS and redis.

ACID = [atomicity, consistency, isolation, durability]

Redis is atomic, consistent, has isolation, and is lax on durability
(periodic snapshots or an append-log that needs to periodically
fsync). AlchemyDB inherits redis' ACID attributes.

More Info:
Alchemy DB has ZERO constraints that can fail, so it does not need
rollbacks, which are arguably a kludge. AlchemyDB also does not have
traditional transactions. VoltDB does not really have transactions
either, they claim a transaction is a stored procedure, which is
technically a redefinition of a transaction. AlchemyDB can support
stored procedures by the far superior lua function route, but
AlchemyDB does not have rollbacks and I personally don't think they
are worth it. VoltDB can roll back a stored procedure half-way, so it
has stored procedure rollback, but not full blown MVCC.

Durability is one of the tougher options in RDBMSes, VoltDB does it
through Ksafety (which means data is copied to 2+ machine's RAM),
AlchemyDB can do this also w/ minimal configuration. Alchemy is
planning on having a flavor that integrates w/ levelDB to support real
disk persistence, but that will take several months. VoltDB does not
EVER persist data to disk, so they also redefined durability, and a
user must write their own archive-data-to-disk routines in VoltDB to
stop the system from running out of RAM due to "cold" data piling up.

Isolation is possible in VoltDB, redis, & AlchemyDB by constricting
the operations to run in single threads. This has the downside of not
supporting concurrent long and short running transactions, which means
long running transactions BLOCK during their entire execution. Alchemy
has built in CURSORs to deal w/ this problem, but the cursors provide
no isolation. The single thread choice is done for performance
reasons, but it does have drawbacks.

So the ACID properties of a hybrid system (like AlchemyDB) are:
1.) however the RDBMS defines its adherence to ACID (and AlchemyDB
does its own thing here, but it is pretty much standard, breaks w/
standard procedures are done intentionally [mostly for performance
gain] and I am happy to argue at length on why they make sense.)
2.) however the NOSQL piece of the system adheres to ACID, which is
always not 100%.

So Alchemy is somewhat ACID compliant, but not 100%. In reality, very
few systems are 100% ACID compliant. There are about 10 things that
make VoltDB semi-ACID compliant, but they sell themselves as ACID
compliant, and they have the intellectual street cred to argue that
they are, so they are ACID. I can argue that AlchemyDB is ACID
compliant: all operations are atomic/consistent, running in a single-
thread means isolation is implicit, and a ksafety config can make
tables durable ... but real ACID means MVCC, fsync every write, 2
phase commit and a bunch of really restrictive/complex/SLOW
constraints, so take my argument w/ a grain of salt.

My answer is a confusing one, but this topic is in and of itself
confusing, there are a lot of variables and a lot of different
implementations and trade-offs come w/ any implementation, so my
advice is to educate one's self on what all of these terms really mean
and how each system's implementation works in practice, and then make
decisions. In reality, attaining all the information needed to do so
and then analysing it and sifting thru the marketing and all of that
takes man-years, so try to find reliable sources of information, my
top 2 are Todd Hoff (www.highscalability.com) and Curt Monash
(www.dbms2.com), both of those guys have decades of experience, get
the big picture, and are more-or-less unsponsored and unbiased.

- jak