5 ms·
Their SQL layer architecture is indeed chatty. If I remember correctly they were doing/planing a lot of optimizations like: 1. delaying requests a little on p
by arthursilva 12y ago
Their SQL layer architecture is indeed chatty.
If I remember correctly they were doing/planing a lot of optimizations like:
1. delaying requests a little on purpose to take more advantage of batch requests
2. fancy techniques to improve join locality (based on Akibans previous work).
These two go hand-to-hand.
So in a good enough network (aka not any public cloud) it'd probably work reasonably well up to a point.
- jhugg 12y agoWhen I started VoltDB, Mike Stonebraker told me we had to be 10x faster than Oracle sitting on a RAM drive, or nobody would care. 5x wasn't interesting to him. It seems like FDB-SQL was closer to 1x, with a much better replication story, but with huge limitations on the kinds of things you can do. (https://foundationdb.com/layers/sql/documentation/Concepts/known.limitations.html https://foundationdb.com/layers/sql/documentation/Concepts/k...) So maybe you could push it to 2x or 3x with a few years of work, but other new systems with more SQL support and more customer traction are doing 10x and up today. It's a tough sell.
- arthursilva 12y agoWhile I do agree with you I don't think anyone used foundation DB sonellly for its sql layer and if they did...
- jhugg 12y agoRight. I'm not being critical of the underlying KV tech. It seemed pretty impressive from what I know. My two points were: 1. The SQL thing wasn't gonna work they way they went about it. 2. Without SQL or some other powerful query tool, it's a less interesting product.