HN Explorer

6 comments

[ 5.1 ms ] story [ 192 ms ] thread
lobster_johnson
I wonder how this compares to FoundationDB's architecture, which also had an SQL layer on top of a K/V store, and was reportedly slow at SQL queries.
bdarnell
(I work for CockroachDB) Our architecture is broadly similar to FoundationDB's, although in our case the separation between the layers is not as strict as I believe FoundationDB's was. This will allow us to improve performance by distributing parts of the SQL processing down to the nodes where the data lives, instead of doing all the processing on a SQL node that is distinct from all the data nodes.
kodablah
Have been following Cockroach for a bit now, looking forward to it. One of the things I like about Cassandra's CQL is that it doesn't let you shoot yourself in the foot. You have to opt-in to doing conditionals that require range scans, you have to provide the PK (or indexed column) for every query, etc. Will Cockroach will do similar in forcing the users to select their data in a certain way that is performant (or at least require opt-out to do full scans)?
bdarnell
(I work for CockroachDB) This is something that we're definitely interested in. We haven't decided yet exactly what form it will take, but we plan to offer some way to ensure that the DB will return an error instead of silently falling back to an extremely inefficient query plan.
steeve
That's cool, although I'm mostly interested about how they are going to do distributed JOINs