Hacker News new | past | comments | ask | show | jobs | submit login
FoundationDB and the New NoSQL (techcrunch.com)
29 points by rentamir on Dec 13, 2014 | hide | past | favorite | 19 comments



Previous discussion from a few days ago:

https://news.ycombinator.com/item?id=8729420

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


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.


> 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.


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.


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).


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.


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.


Spam


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?


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.


fwiw UnQLite is an ACID NoSQL serverless/embeded database

http://unqlite.org/intro.html


Couchdb is a NoSQL store that is ACID.


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



MarkLogic is too: http://www.marklogic.com/


IIRC you can't update multiple documents atomically.


I’m only aware of one NoSQL database that could do multi-document /multi-collection transactions.

ArangoDB (document database)


Oracle Berkeley DB, wiredtiger, lmdb, titandb, neo4j and orientdb.


postgresql xc / postgresql xl




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: