39 ms·

Everytime i read one of those post (or other about mongodb failures), i keep thinking about this talk http://youtu.be/4fFDFbi3toc http://youtu.be/4fFDFbi3toc A

by bsaul 11y ago

Everytime i read one of those post (or other about mongodb failures), i keep thinking about this talk http://youtu.be/4fFDFbi3toc http://youtu.be/4fFDFbi3toc And why noone tried to repeat their strategies for building a robust db system : start by building an extremely robust failure simulation and testing facility. Then build your product. Actually, i think what those guys at foundationdb did was so exceptional, that by buying the company and killing the product, Apple harmed the software industry for the next 10 years. The fact the foundationdb is mentionned in OP as the only distributed db system one could recommend makes me more confident making that statement.

lostcolony 11y ago
Only distributed SQL store. You want non-distributed SQL, there are options, you want distributed NoSQL, there are options.
- rspeer 11y ago
  Aphyr's been testing more than SQL stores. "NoSQL" is not a magic bullet: concurrency is still hard when you skip the SQL.
  - lostcolony 11y ago
    I know. Sorry, I should have been clearer; what I meant was Aphyr has had some fine results for SQL DBs, provided you avoided distribution. And he has had some fine results for NoSQL DBs, when distributed, provided you preferred availability to consistency (generally in certain scenarios, or with certain caveats). What he has not had, and so presumably was lamenting, was any distributed DB that offered transactions that passed any sort of muster, except for FoundationDB, which was made defunct. That, or any DBs he could recommend that met every claim their documentation made (as that's largely what he's testing for). I meant that with this being the first distributed SQL store, he was saying there was nothing he could recommend that actually offered similar guarantees to what this was claiming. That is, ACID style (well, technically --ID I believe) DB transactions in a distributed environment. FoundationDB did (though it was NoSQL), hence his mentioning it. But that's different than there is nothing he can recommend, at large; he can't recommend similar solutions, but for a given problem he could likely recommend a compelling, different, solution.
threeseed 11y ago
FoundationDB was hardly redefining the database industry. There is more to a database being successful in the market than how well it fairs in one particular guy's blog posts (as excellent as they are). Apple isn't harming anyone.
jhugg 11y ago
This might be overdoing things a bit. FoundationDB was a rigorously tested KV store with strong consistency (uncommon for such a product). Yes, that talk from StrangeLoop was great, but there's two common misconceptions here: (What follows is my opinion / guesswork as a VoltDB employee) 1. FoundationDB wasn't killed by Apple; it was rescued by Apple. The product couldn't compete on just being a KV store and wasn't doing well in the market. Apple saw a very bright and now experienced team and scooped them up for a song. 2. Before this happened, FoundationDB realized they needed a way to query their system to compete, so they bought Akiban (a failing SQL db company) to add SQL to their system. But they assumed they could do this without deep integration, which was wrong. They added a SQL "layer" on top of the KV store and it was way to slow to be practical. The benchmarks they published were embarrassing. I wrote a blog post about this: http://voltdb.com/blog/foundationdbs-lesson-fast-key-value-store-not-enough http://voltdb.com/blog/foundationdbs-lesson-fast-key-value-s... SUMMARY FoundationDB: Great Testing, Great Engineering, Not particularly good product...
- bsaul 11y ago
  Very interesting pov, thanks for sharing. Actually, the thing that i find most impressive in their tech stack is the approach they took for building it starting with the simulator + c++ extension. Those are the technology that i think would benefit all the community, if they were ever open sourced. As a voltDB engineer, how do you ensure your implementation doesn't compromise the theorical correctness of your system ?
  - jhugg 11y ago
    I'm actually going to be discussing this at Strangeloop next month. http://www.thestrangeloop.com/2015/all-in-with-determinism-for-performance-and-testing-in-distributed-systems.html http://www.thestrangeloop.com/2015/all-in-with-determinism-f... VoltDB is actually a bit simpler with what it promises, full serializable ACID for all transactions. This is much easier to understand and verify than lesser isolation. We think what we've done is pretty clever too. We've built a determinism checker into our replication engine, so that we can verify that each replica has the same state at each logical point in time, and each operation makes identical changes to that state. Then we built test patterns that are designed to be as co-dependent as possible and run them against a replicated VoltDB cluster. That VoltDB cluster goes though one or more kinds of failure, including multiple simultaneous failure, and then a checker ensures no data is ever lost, corrupted or run in the wrong order. It's different from the FDB thing. The simulation they did is certainly easier to run on a pure KV store, but keep in mind we also have to test SQL that queries millions of rows, along with upserts, materialized aggregations, etc... We're working on some blog content on this in addition to my talk. Stay tuned.
MrBuddyCasino 11y ago
That was a great talk. If there isn't anyone doing this right now, somethings wrong with the world. Its a huge opportunity.

by bsaul 11y ago

lostcolony 11y ago

Only distributed SQL store. You want non-distributed SQL, there are options, you want distributed NoSQL, there are options.

rspeer 11y ago
Aphyr's been testing more than SQL stores. "NoSQL" is not a magic bullet: concurrency is still hard when you skip the SQL.
- lostcolony 11y ago
  I know. Sorry, I should have been clearer; what I meant was Aphyr has had some fine results for SQL DBs, provided you avoided distribution. And he has had some fine results for NoSQL DBs, when distributed, provided you preferred availability to consistency (generally in certain scenarios, or with certain caveats). What he has not had, and so presumably was lamenting, was any distributed DB that offered transactions that passed any sort of muster, except for FoundationDB, which was made defunct. That, or any DBs he could recommend that met every claim their documentation made (as that's largely what he's testing for). I meant that with this being the first distributed SQL store, he was saying there was nothing he could recommend that actually offered similar guarantees to what this was claiming. That is, ACID style (well, technically --ID I believe) DB transactions in a distributed environment. FoundationDB did (though it was NoSQL), hence his mentioning it. But that's different than there is nothing he can recommend, at large; he can't recommend similar solutions, but for a given problem he could likely recommend a compelling, different, solution.

threeseed 11y ago

FoundationDB was hardly redefining the database industry. There is more to a database being successful in the market than how well it fairs in one particular guy's blog posts (as excellent as they are). Apple isn't harming anyone.

jhugg 11y ago

This might be overdoing things a bit. FoundationDB was a rigorously tested KV store with strong consistency (uncommon for such a product). Yes, that talk from StrangeLoop was great, but there's two common misconceptions here: (What follows is my opinion / guesswork as a VoltDB employee) 1. FoundationDB wasn't killed by Apple; it was rescued by Apple. The product couldn't compete on just being a KV store and wasn't doing well in the market. Apple saw a very bright and now experienced team and scooped them up for a song. 2. Before this happened, FoundationDB realized they needed a way to query their system to compete, so they bought Akiban (a failing SQL db company) to add SQL to their system. But they assumed they could do this without deep integration, which was wrong. They added a SQL "layer" on top of the KV store and it was way to slow to be practical. The benchmarks they published were embarrassing. I wrote a blog post about this: http://voltdb.com/blog/foundationdbs-lesson-fast-key-value-store-not-enough http://voltdb.com/blog/foundationdbs-lesson-fast-key-value-s... SUMMARY FoundationDB: Great Testing, Great Engineering, Not particularly good product...

bsaul 11y ago
Very interesting pov, thanks for sharing. Actually, the thing that i find most impressive in their tech stack is the approach they took for building it starting with the simulator + c++ extension. Those are the technology that i think would benefit all the community, if they were ever open sourced. As a voltDB engineer, how do you ensure your implementation doesn't compromise the theorical correctness of your system ?
- jhugg 11y ago
  I'm actually going to be discussing this at Strangeloop next month. http://www.thestrangeloop.com/2015/all-in-with-determinism-for-performance-and-testing-in-distributed-systems.html http://www.thestrangeloop.com/2015/all-in-with-determinism-f... VoltDB is actually a bit simpler with what it promises, full serializable ACID for all transactions. This is much easier to understand and verify than lesser isolation. We think what we've done is pretty clever too. We've built a determinism checker into our replication engine, so that we can verify that each replica has the same state at each logical point in time, and each operation makes identical changes to that state. Then we built test patterns that are designed to be as co-dependent as possible and run them against a replicated VoltDB cluster. That VoltDB cluster goes though one or more kinds of failure, including multiple simultaneous failure, and then a checker ensures no data is ever lost, corrupted or run in the wrong order. It's different from the FDB thing. The simulation they did is certainly easier to run on a pure KV store, but keep in mind we also have to test SQL that queries millions of rows, along with upserts, materialized aggregations, etc... We're working on some blog content on this in addition to my talk. Stay tuned.

MrBuddyCasino 11y ago

That was a great talk. If there isn't anyone doing this right now, somethings wrong with the world. Its a huge opportunity.