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

21–30 of 57 posts

Re: A NoSQL Database with ACID Transactions

#21

Post by krenoten »

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 hopefully the world will catch up a bit with Google's Megastore and Spanner.

Re: A NoSQL Database with ACID Transactions

#22

Post by Dave_Rosenthal »

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 concurrency. But, the real magic is how Flow enables us to use our real code to do deterministic simulations of a cluster in a single thread. We have a white paper upcoming on this.

We've had quite a bit of interest in Flow over the years and I've given several talks on it at meetups/conferences. We've always thought about open-sourcing it... It's not as elegant as some other actor-model languages like Scala or Erlang (see: C++) but it's nice and fast at run-time and really helps productivity vs. writing callbacks, etc.

(Fun fact: We've only ever found two bugs in Flow. After the first, we decided that we never wanted a bug again in our programming language. So, we built a program in Python that generates random Flow code and independently-executes it to validate Flow's behavior. This fuzz tester found one more bug, and we've never found another.)

Re: A NoSQL Database with ACID Transactions

#23

Post by rcb »

Very nice, and congratulations. Reading the "Data Modeling" documentation brings to mind some similarities with the MUMPS storage model (Intersystems Caché / GlobalsDB / GT.M).. is this a correct observation? Thanks.

Re: A NoSQL Database with ACID Transactions

#25

Post by gngeal »

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…

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

I don't think that should come as a surprise to anyone. In the long run, language-oriented approach seems to be the best approach to handling the intricacies of complex software systems. The only thing stopping it seems to be a certain lack of skills and experience on part of most developers, and the inadequacy of current language-building tools. (By any chance, are you familiar with the "let's simplify language construction"-related work of people at vpri.org?)

Re: A NoSQL Database with ACID Transactions

#26

Post by gruseom »

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…

How does the Python program know what the random Flow code is supposed to do?

Re: A NoSQL Database with ACID Transactions

#27

Post by mercurial »

I like the emphasis on transactions. However, the fact that it doesn't support transactions longer than 5s and puts the onus on the client to enforce is kind of a turn-off. How is the client supposed to know how long the server will take for a given operation at a random load?

Re: A NoSQL Database with ACID Transactions

#29

Post by jt2190 »

obviouslygreen wrote: post #19
jt2190 wrote: post #16

Earlier quoted context omitted.

> If you have a highly relational model that would benefit > from things like referential integrity and normalization > then use a relational database. If you need a massive > highly scalable KVP database, use NoSQL. I don't see why > people try to use a single approach as a solution > to every problem. Part of the problem is that people present this as a choice between relational and non-relational models, when the…

You're turning one false dichotomy into... I don't know the word for it, but while how it scales can be part of choosing a database system, it definitely is not the main difference between the relational and noSQL models. How your data storage will scale is an important but tangential topic that should be addressed as complementary to deciding which class of storage will help you most effectively and efficiently mode…

  > ...[database scaling is] definitely is not the main
  > difference between the relational and noSQL models.
The post I was responding to strongly implies that one simply has to decide whether they want to use a relational model or not. I contend that framing the question this way is contributing to the misunderstandings of what the advantages and disadvantages of the popular noSQL databases are, which become very apparent when one thinks of what happens when the data set gets very large. Relational databases don't work nearly as well when you have to split the schema across multiple databases, and you can no longer use the database provided transactions or joins.

Re: A NoSQL Database with ACID Transactions

#30

Post by andrewflnr »

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…

At first I thought you were talking about http://www.flowlang.net/p/introduction.html, a different Flow language designed around data flow to allow automatic parallelization.
Post reply on HN