Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A NoSQL Database with ACID Transactions

foundationdb.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: A NoSQL Database with ACID Transactions

#51

Post by rzidane »

Dave_Rosenthal wrote: post #22
krenoten wrote: post #21

The Flow language they implemented for this is interesting. http://www.foundationdb.com/white-papers/flow/ I think we are going to see eventual consistency deflate as people relearn to love transactions. SQL also makes users of a database a lot more productive. The bottom line is you don't want your devs spending time and effort reasoning about database behavior, you want them focusing on business logic. In 5 years h…

FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made. We knew this was going to be a long project so we invested heavily in tools at the beginning. The first two weeks of FoundationDB were building this new programming language to give us the speed of C++ with high level tools for actor-model concurr…

I read the performance analysis comparing it to Go, Erlang etc. Has any comparison been made with Akka (http://akka.io)? How much would this extra efficiency matter when the communicating processes are on different machines? Since speed in communicating between local processes is important to you guys, I am assuming that the actor model is then used for all local and remote communication?

Re: A NoSQL Database with ACID Transactions

#52

Post by toolslive »

I searched the site a bit and saw no information whatsoever on what is behind it, so I'm going to guess:

For the local store, probably something like an append-only (aka copy on write aka persistent) B-tree-ish data structure. This guarantees good behaviour on SSDs, and cheap/easy transactions. It can also be scaled linearly over multiple spindles.

For the distributed aspect, I guess they use some paxos variation (I guess this from the separation between logging the transaction and durably applying this)

But again: I am merely guessing.

With regard to flow: Is it just me, or does it look like a poor man's concurrency monad.

Re: A NoSQL Database with ACID Transactions

#53

Post by lucian1900 »

giulianob wrote: post #14
awjr wrote: post #2

It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.

The issue I see the most is that NoSQL has become synonymous with distributed databases which is really where making ACID promises becomes a challenge. If you had a single node document DB, it probably wouldn't be very challenging to make it ACID. SQL or not, as soon as you want to make it automatically shard and distributed, then you will suffer large performance impacts with transactions. Are there any single node…

True. For example, CouchDB is ACID, as long as you consider versioned data equivalent to transactions.

Re: A NoSQL Database with ACID Transactions

#55

Post by melchebo »

krenoten wrote: post #21

The Flow language they implemented for this is interesting. http://www.foundationdb.com/white-papers/flow/ I think we are going to see eventual consistency deflate as people relearn to love transactions. SQL also makes users of a database a lot more productive. The bottom line is you don't want your devs spending time and effort reasoning about database behavior, you want them focusing on business logic. In 5 years h…

Reminds me a bit of OkCupid's Tamer : https://github.com/maxtaco/tamer

Though I believe they go less all out on the actor model, but just focus on concurrent processing, essentially using futures.

Re: A NoSQL Database with ACID Transactions

#56

Post by wbl »

Dave_Rosenthal wrote: post #11
wbl wrote: post #6

MVCC does not provide serializability of transactions without a bit more work. Since when can you get away without giving guaranties about what you support?

I agree that MVCC does not itself guarantee transaction isolation, but FoundationDB does indeed do the "bit more work" to guarantee all of the ACID properties.

Ah, I found the page where it claims serializability. http://www.foundationdb.com/documentation/beta1/developer-gu...

Re: A NoSQL Database with ACID Transactions

#57

Post by xb95 »

Dave_Rosenthal wrote: post #50
xb95 wrote: post #47

I really want to be excited by this. For better or worse, after being in this industry for a long time now all I can say about a new database launch is: cool, I'd love to talk to you in 3-5 years when you've had time to work out the hinks and people have figured out what your strengths and weaknesses are and where the real gotchas will getcha. Until then: good luck. A distributed, linearly scalable, easy-to-admin NoS…

I totally understand this perspective. FWIW, we're trying to be as open as we can about those "gotchas". You might be interested in our: - Known limitations ( http://foundationdb.com/documentation/beta1/known-limitation... ) - Anti-features ( http://foundationdb.com/white-papers/anti-features/ ) - Performance considerations ( http://foundationdb.com/documentation/beta1/developer-guide.... ) Talk to you in a few years…

FWIW, those documents are a fantastic start and contain the sort of things that I wish I had known about MongoDB and Riak before embarking on quests to use them.

I hope you do well -- the world really needs a good amalgamation of strong data integrity (ACID, transactions) and the ease-of-life that distributed databases generally give you. Since I don't work in an industry where I need microsecond reads, I'm perfectly happy to pay the cost of "it might take 10s of milliseconds to commit this" if I can avoid having to go down the "okay, now I have to shard my project" path for an eighth time. :-)

Post reply on HN