3 ms·

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 S

by 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.
  - bsaul 11y ago
    Great, i'm looking forward to see that talk. To me, it seems that the only way you can make sure that an implementation is correct, is either via extensive testing ( and when talking about acid property over a distributed system, i think the kind of simulator fdb built is a requirement), or run a theorem proover ofer your source code, ala Coq. But i've never heard of any code analysis tool that is able to guarantee properties over a distributed system. But, since i'm absolutely not working on the field, i'm really looking forward to see what professional people like you are finding to tackle those issues.

by jhugg 11y ago

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.
- bsaul 11y ago
  Great, i'm looking forward to see that talk. To me, it seems that the only way you can make sure that an implementation is correct, is either via extensive testing ( and when talking about acid property over a distributed system, i think the kind of simulator fdb built is a requirement), or run a theorem proover ofer your source code, ala Coq. But i've never heard of any code analysis tool that is able to guarantee properties over a distributed system. But, since i'm absolutely not working on the field, i'm really looking forward to see what professional people like you are finding to tackle those issues.