Hacker News Reader

Comment by shin_lao | Hacker News Reader

From what I understand of this specific project, they "solved" the consistency problem (which is quite a feat, granted).

They don't say they have an ACID NoSQL database, which is, to me, an oxymoron: ACIDity is useful if you have a powerful query language.

In the end don't you fear that you might simply reinvent SQL? Or, am I missing something?

View on HN

ACID and NoSQL are not mutually exclusive, although that is a common misconception due to the fact that almost all NoSQL databases gave up ACID in exchange for BASE (eventual consistency), making the development of their distributed databases much easier. However, ACID is simply a set of properties that allows you to group a set of reads & writes to a database into a transaction that is Atomic, Consistent, Isolated, and Durable. That set of reads & writes does not need to be SQL - in our case, it is a set of reads from and writes to a database of ordered keys and values.

For example, you could read the values associated with keys "a" and "b" and "c" and based on that information, make a change to the values associated with keys "c" and "d" and then commit the transaction. The transaction then either fails completely (if one of the keys you read had been written to since your read, in which case you re-try the transaction) or succeeds completely. That is an ACID transaction in a (NoSQL) key-value store.

That sounds useful, but not as useful as transactions on joins.

It's great to have transactions when you have to cross reference data, on a key/value store, although you can have range queries I submit that kind of operations is less frequent.

But still, it sure is great to be able to run a batch of operations with the confidence it will be transactional, I'm sure there are many use cases that can benefit from it.

Oddly enough, it's strange that there aren't more NoSQL engines offering this feature as once you have MVCC you've done the hard part and AFAIK several NoSQL db have MVCC.

Yep, those types of operations are less frequent in k/v stores, but we believe it is because of the lack of ACID in most of them. When you have ACID and ordering you can use transactions to keep data and multiple indexes on that data in synch, and use range operations to query the indexes.

You can build all manner of higher level data structures with a transactional ordered k/v store, which is why our concept of "layers" is possible: www.foundationdb.com/#layers

It seems to me more like they have "solved" (or broken) the CAP theorem ... http://en.wikipedia.org/wiki/CAP_theorem

* Consistency (all nodes see the same data at the same time)

* Availability (a guarantee that every request receives a response about whether it was successful or failed)

* Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

According to the theorem, a distributed system can satisfy any two of these guarantees at the same time, but not all three.

No, they haven't broken the CAP theorem. If the network were to partition badly enough, Spanner would lose its quorum and would become unavailable, at least for guaranteed-consistent operations.

In practice, a network partition bad enough to bring down something like Spanner is pretty rare. (I worked at Google for four years, and I can't recall such a partition occurring.) But in theory it's certainly possible.

The CAP theorem states that at one point in time you can only have two in three.

It doesn't say much more than the obvious. Obviously, if one node parts, you're either inconsistent or available.

Just to clarify what the CAP theorem says: If one node parts, then that node is either inconsistent or not available. A fault-tolerant database could potentially stay up with a single unavailable node.

Which part of acid is relevant specifically to SQL (joins, I assume you mean)?

Reply on news.ycombinator.com