5 ms·

FoundationDB — Not Your Standard NoSQL Database

18 points by firefox 14y ago

nirvana 14y ago
I've got a car that runs on water. No, really. The thing is, these other cars, they just decide to run on gas. Totally ignoring the potential of water power. Of course this design is really fundamental to the way cars will be built in the future, you could call it a foundation of a new paradigm for cars-- all the performance of a gas car, without all the hassle and expense- not to mention pollution-- of gasoline. Just simple pure water. Don't believe me? You shouldn't. The question is, how can we take TechCrunch seriously when they do not even ask the basic questions? Edit: Seriously, they say its distributed but ACID compiant. Ok, how do you do that? This violates the CAP theorem. How do they handle partitions? Without answering this, the article is as meaningless as an announcement of a water powered car.
- bluestix 14y ago
  This analogy is bad and you should feel bad. R.I.P Stan Meyer.
- asharp 14y ago
  I think you should take a quick look at oracle's exadata machines. Mostly because they are both distributed and ACID compliant.
siculars 14y ago
"The service can scale across a distributed infrastructure without the worry of a single point of failure, making it simpler to scale." :)
karterk 14y ago
The result, they say, is an infinitely scalable database that goes beyond what most NoSQL databases offer. No wonder NoSQL gets so much flake.
pyrotechnick 14y ago
There are standard NoSQL databases?
- riffraff 14y ago
  quite possibly, dbm: no sql at all, and has been around for 40 years.
fdr 14y ago
I see a lot of snarky comments (maybe that has to do with the journalism of the article), but my recollection of FoundationDB is that it is interesting. It's trying to tackle the problem of enabling ACID, while also not being SQL-dialect oriented, putting it in a somewhat unique part of the overall landscape. So, if you are put off by TechCrunch's journalism, I don't know of a great reason to let that spill over into one's gut assessment FoundationDB. Here is a link to previous discussion, where many people try to poke holes into the tradeoffs being made for FoundationDB: http://news.ycombinator.com/item?id=4294719 http://news.ycombinator.com/item?id=4294719 Perhaps the company needs to work to reign in some of the language, it seems like the last discussion revolved around some aspects of the system that tripped a lot of skepticism-detectors (or at least "glaring caveat-omission" detectors) last time also.
- Dave_Rosenthal 14y ago
  FoundationDB founder here. Thanks for this comment. It's pretty hard to talk about this detailed technical stuff in the chaos of a conference. The discussion you link to and our web page both have a bunch of information that I think is high signal/noise for people interested in the tech details. If anyone is at Disrupt, please come by and see our live demo of a portable cluster of the database dealing with power and network failures. Of course, we'll try our best to answer questions here too.
  - fdr 14y ago
    If I had any feedback, it might be to produce a frank document of trade-offs in your system: workloads that work very well, pathological workloads that perform poorly or lead to some awkward code, given the mechanisms at play. I'm sure you have chosen your trade-offs carefully, or else you wouldn't have bothered doing the hard work to commercialize them. Here you may want to assess the advantages of other general approaches (I think specific implementations would be too much detail and invite a quagmire of nit-picking) versus your own, but the problems they also create that you do not have. It's something I'm going to try to do anyway, but it would make me feel as though I have a more constructive relationship with the company rather than trying to guess what mix of design decisions you fall in, probably all of which have at least been implemented at least once independently before in some system or another -- however, your mix is likely novel. However, I don't see this done very often in proprietary offerings (that's still the case for FoundationDB, right?), and I'm not sure if that's because such frankness is a stupid idea or if because everyone is just doing what everyone around them does. It is something that more collaborative open source projects do more freely.
ricardobeat 14y ago
FoundationDB can scale once across a distributed infrastructure. That’s opposed to SQL database technology has to be installed on individual servers. Can anyone explain?
- nlavezzo 14y ago
  A FoundationDB database can scale "horizontally" by adding multiple machines to a cluster, and you can scale the cluster up by adding more machines. This is opposed to standard SQL databases which provide one or more databases per server, but never one database from multiple servers.
  - kraskat 14y ago
    That statement has really no foundation and maybe the founders of FoundationDB should read a introduction to distributed database book, for example "Principles of Distributed Database Systems" by Özsu and Valduriez.

18 points by firefox 14y ago

I've got a car that runs on water. No, really. The thing is, these other cars, they just decide to run on gas. Totally ignoring the potential of water power. Of course this design is really fundamental to the way cars will be built in the future, you could call it a foundation of a new paradigm for cars-- all the performance of a gas car, without all the hassle and expense- not to mention pollution-- of gasoline. Just simple pure water. Don't believe me? You shouldn't. The question is, how can we take TechCrunch seriously when they do not even ask the basic questions? Edit: Seriously, they say its distributed but ACID compiant. Ok, how do you do that? This violates the CAP theorem. How do they handle partitions? Without answering this, the article is as meaningless as an announcement of a water powered car.

bluestix 14y ago
This analogy is bad and you should feel bad. R.I.P Stan Meyer.
asharp 14y ago
I think you should take a quick look at oracle's exadata machines. Mostly because they are both distributed and ACID compliant.

siculars 14y ago

"The service can scale across a distributed infrastructure without the worry of a single point of failure, making it simpler to scale." :)

karterk 14y ago

The result, they say, is an infinitely scalable database that goes beyond what most NoSQL databases offer. No wonder NoSQL gets so much flake.

pyrotechnick 14y ago

There are standard NoSQL databases?

riffraff 14y ago
quite possibly, dbm: no sql at all, and has been around for 40 years.

fdr 14y ago

I see a lot of snarky comments (maybe that has to do with the journalism of the article), but my recollection of FoundationDB is that it is interesting. It's trying to tackle the problem of enabling ACID, while also not being SQL-dialect oriented, putting it in a somewhat unique part of the overall landscape. So, if you are put off by TechCrunch's journalism, I don't know of a great reason to let that spill over into one's gut assessment FoundationDB. Here is a link to previous discussion, where many people try to poke holes into the tradeoffs being made for FoundationDB: http://news.ycombinator.com/item?id=4294719 http://news.ycombinator.com/item?id=4294719 Perhaps the company needs to work to reign in some of the language, it seems like the last discussion revolved around some aspects of the system that tripped a lot of skepticism-detectors (or at least "glaring caveat-omission" detectors) last time also.

Dave_Rosenthal 14y ago
FoundationDB founder here. Thanks for this comment. It's pretty hard to talk about this detailed technical stuff in the chaos of a conference. The discussion you link to and our web page both have a bunch of information that I think is high signal/noise for people interested in the tech details. If anyone is at Disrupt, please come by and see our live demo of a portable cluster of the database dealing with power and network failures. Of course, we'll try our best to answer questions here too.
- fdr 14y ago
  If I had any feedback, it might be to produce a frank document of trade-offs in your system: workloads that work very well, pathological workloads that perform poorly or lead to some awkward code, given the mechanisms at play. I'm sure you have chosen your trade-offs carefully, or else you wouldn't have bothered doing the hard work to commercialize them. Here you may want to assess the advantages of other general approaches (I think specific implementations would be too much detail and invite a quagmire of nit-picking) versus your own, but the problems they also create that you do not have. It's something I'm going to try to do anyway, but it would make me feel as though I have a more constructive relationship with the company rather than trying to guess what mix of design decisions you fall in, probably all of which have at least been implemented at least once independently before in some system or another -- however, your mix is likely novel. However, I don't see this done very often in proprietary offerings (that's still the case for FoundationDB, right?), and I'm not sure if that's because such frankness is a stupid idea or if because everyone is just doing what everyone around them does. It is something that more collaborative open source projects do more freely.

ricardobeat 14y ago

FoundationDB can scale once across a distributed infrastructure. That’s opposed to SQL database technology has to be installed on individual servers. Can anyone explain?

nlavezzo 14y ago
A FoundationDB database can scale "horizontally" by adding multiple machines to a cluster, and you can scale the cluster up by adding more machines. This is opposed to standard SQL databases which provide one or more databases per server, but never one database from multiple servers.
- kraskat 14y ago
  That statement has really no foundation and maybe the founders of FoundationDB should read a introduction to distributed database book, for example "Principles of Distributed Database Systems" by Özsu and Valduriez.