

FoundationDB and the New NoSQL - rentamir
http://techcrunch.com/2014/12/13/foundationdb-and-the-new-nosql/

======
jcr
Previous discussion from a few days ago:

[https://news.ycombinator.com/item?id=8729420](https://news.ycombinator.com/item?id=8729420)

    
    
      Databases at 14.4Mhz ()
      292 points by chton 3 days ago 85 comments

------
lclarkmichalek
What a shitty article.

> As interesting as these new developments–called “NoSQL databases”–were,
> though, only bleeding-edge startups and a tiny handful of other dreamers
> were really taking them seriously.

What is this shit? Seriously, wtf. I mean, sure, Mongo saw a lot of use among
the mentally challenged, but a _lot_ of big companies have _big_ NoSQL
clusters in production. Hell, according to datastax, a quarter of the Fortune
100 use Cassandra..

> <couple of tweets about how non-AD databases are a bit shit>

> MongoDB is not ACID compliant. Neither is Cassandra. Neither is Riak.
> Neither is Redis. Etc etc etc.

The fact that C*, riak, etc aren't ACID isn't a point against them; it's a
calculated tradeoff. It's only a problem when they are advertised as being
ACID, and I'll happily join you in condemning them if they do call themselves
ACID when they are not

We are seeing the rise of "NewSQL" (that is, datastores with transactions),
but that does _not_ mean the death of NoSQL, and it does _not_ automatically
imply superiority to NoSQL. It's about choice, and that is fucking awesome.
Stop trying to induce some twisted total ordering on each consistency model.
It doesn't exist. As long as a consistency model is clearly documented,
accurately implemented (yeah, I know, I can dream), then there is no innate
superiority. Stop trying to create one.

~~~
Dave_Rosenthal
> The fact that [Cassandra], riak, etc aren't ACID isn't a point against them;
> it's a calculated tradeoff.

Actually, not being ACID is absolutely a point against them.

Riak at least has an good reason: it's eventually consistent. They are getting
the advantages of better latency and disconneced-operation.

But, if you look at MongoDB, Cassandra (as it is usually config'ed), and HBase
they are actually all strongly consistent. They've _already accepted_ the
strong-consistency side of the CAP theorem tradeoff. There is no remaining
reason not to have transactions at that point, but they don't. This isn't
because of some fundamental tradeoff, it's because making transactions run
correctly and fast is really hard and they haven't yet cracked that problem. I
bet it's on all of their roadmaps. If and when they add multi-key serializable
ACID transactions their products will be purely better for it.

~~~
lclarkmichalek
We're talking about a few DBs here, but I'm just going to focus on Cassandra,
as Mongo is a lost cause, and I don't know much about HBase. However, my
arguments apply to all AP systems with tuneable consistency.

I think you're saying that people use Cassandra with consistency=ALL
everywhere to get strong consistency? In that case, sure, then they should
look at something else. Potentially even the database your company produces.
However, that is a strawman; Cassandra was designed to be an AP system. Later
additions like tuneable consistency and lightweight transactions are a
compromise, and implementing something as crazy as ACID transactions on C*
would be insane. Like, totally stupid. It is so far from the core goal of an
AP system, that I would be very worried about the leadership of the project.

I like my databases to do one thing, and do it well. That's why I like basic
C*: it's an awesome AP KV database. Features that have been added later have
generally been syntactic sugar (CQL, indexes, multi column indexes, user
types), or compromises (tuneable consistency, lightweight transactions). But
it still remains an AP system at heart. And because of that, ACID transactions
would _not_ improve the product. It would all but destroy it.

You should probably mention that you were a founder of FoundationDB if you're
going to comment on articles about it.

------
djtriptych
Fun fact; the FoundationDB founding team and Yext founding team are part of
the same high school CLASS of about 400 people. TJHSST '98\. I was a classmate
(now a lowly ex-Googler working on a group communication platform).

------
virmundi
Please take a look at ArangoDB. It has joins, documents and graph
capabilities. It also has transactions against multiple documents within a
collection.

See arangodb.com.

~~~
virmundi
Wow, a Reddit level of down voting. So anonymous down voter, care to explain
what you have issues with? ArangoDB does all of those things.

~~~
woah
Spam

~~~
virmundi
How is it spam? There are other comments here about how Coach is acid. Is that
spam too? Should those who use a product that attempts to be at least somewhat
ACID keep our fingers still when topics like this come up?

~~~
woah
My guess is that the perception that it is spam is why he was getting the
downvotes. The post doesn't really share much info about the db in question,
other than endorsing it.

------
jszymborski
fwiw UnQLite is an ACID NoSQL serverless/embeded database

[http://unqlite.org/intro.html](http://unqlite.org/intro.html)

------
IndianAstronaut
Couchdb is a NoSQL store that is ACID.

~~~
lmorris84
Is it? The front page of CouchDB says "CouchDB is highly available and
partition tolerant, but is also eventually consistent"

~~~
IndianAstronaut
[http://wiki.apache.org/couchdb/Technical%20Overview#ACID_Pro...](http://wiki.apache.org/couchdb/Technical%20Overview#ACID_Properties)

