I too am interested in this. I just took a look through the docs. SQL layer over a distributed key-value store...
Full ACID and looks to have support for FK/PK JOINs/ and multi-table queries. Their benchmarks page looks super awesome. How well does this work in practice?
One major difference from Cassandra (I think) seems to be that coordinator nodes are set statically (but can be changed on the fly). Cassandra is not this way. While there are coordinator nodes during client connections, they are chosen dynamically by the client during the session and not some fixed config point.
Different tools for different problems. I think Cassandra fits Apple's content distribution model better (e.g. streaming music/movie blobs out of C* for iTunes all over the world), but for a traditional RDBMS that is distributed, this looks like a great escape.
Scaling seems pretty easy if it's as easy as copy-pasting the config file from node to node and bouncing the service. Anyone know about this in practice?
“The most important innovation with MongoDB is its API,” Rosenthal said. “We sell an amazing storage technology that could be compatible with NoSQL technologies like MongoDB.”
Full ACID and looks to have support for FK/PK JOINs/ and multi-table queries. Their benchmarks page looks super awesome. How well does this work in practice?
One major difference from Cassandra (I think) seems to be that coordinator nodes are set statically (but can be changed on the fly). Cassandra is not this way. While there are coordinator nodes during client connections, they are chosen dynamically by the client during the session and not some fixed config point.
Another difference appears to be transaction limits (https://foundationdb.com/layers/sql/documentation/Concepts/k...). This is fundamentally different from Cassandra, but to be expected without tunable consistency.
Different tools for different problems. I think Cassandra fits Apple's content distribution model better (e.g. streaming music/movie blobs out of C* for iTunes all over the world), but for a traditional RDBMS that is distributed, this looks like a great escape.
Scaling seems pretty easy if it's as easy as copy-pasting the config file from node to node and bouncing the service. Anyone know about this in practice?