4 ms·

I noticed that the question on performance was ignored, but I think it's worth noting that FoundationDB died on exactly the same beach. [1] I'm not extremely fa

I noticed that the question on performance was ignored, but I think it's worth noting that FoundationDB died on exactly the same beach. [1] I'm not extremely familiar with the CockroachDB architecture (other than "it's kinda like the F1/Spanner/Bigtable stack"), but I suspect that there are some commonalities. For example, CockroachDB's Bigtable-style two-level range indexing means you could run into exactly this problem: > FDB-SQL stores metadata in the KV store itself. This is great from a distributed correctness point-of-view. It’s also great from a simplicity point-of-view. If I trust the underlying system to be safe and consistent, then my metadata is also safe and consistent. But now I need to do a ton of reads before I run my SQL to know how to run my SQL. Where’s my data, for example? [1] https://www.voltdb.com/blog/2015/04/01/foundationdbs-lesson-fast-key-value-store-not-enough/ https://www.voltdb.com/blog/2015/04/01/foundationdbs-lesson-...

petermattis 9y ago
(Cockroach Labs co-founder here) CockroachDB also stores SQL metadata inside of the KV store, but that metadata is also gossiped around the cluster (i.e. it is replicated to every node) so that SQL execution almost never has to read it from the KV store. Handling changes to this SQL metadata is challenging and required a design [1] that is unable to take advantage of the easy correctness of simply doing reads from the KV store on every operation. [1] https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/table_descriptor_lease.md https://github.com/cockroachdb/cockroach/blob/master/docs/RF...
- elvinyung 9y ago
  I see -- so how is performance? I see that there are no published numbers for e.g. TPC-C or YCSB. (For the record -- in case I seem to be especially pessimistic -- I'm actually extremely hopeful that CRDB will actually make scaling OLTP applications significantly easier for everyone. It's just that this probably shouldn't be FDB all over again.)
  - petermattis 9y ago
    Performance is "ok". CockroachDB 1.0 won't be winning benchmarks, but that was never the goal. We have seen near linear scaling from 3-64 nodes on a uniformly random write workload. And the new distributed SQL execution engine has shown O(num-nodes-in-cluster) speedup on some queries. But none of this has been wrapped up into published numbers, so take it with a grain of salt.

petermattis 9y ago

(Cockroach Labs co-founder here) CockroachDB also stores SQL metadata inside of the KV store, but that metadata is also gossiped around the cluster (i.e. it is replicated to every node) so that SQL execution almost never has to read it from the KV store. Handling changes to this SQL metadata is challenging and required a design [1] that is unable to take advantage of the easy correctness of simply doing reads from the KV store on every operation. [1] https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/table_descriptor_lease.md https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

elvinyung 9y ago
I see -- so how is performance? I see that there are no published numbers for e.g. TPC-C or YCSB. (For the record -- in case I seem to be especially pessimistic -- I'm actually extremely hopeful that CRDB will actually make scaling OLTP applications significantly easier for everyone. It's just that this probably shouldn't be FDB all over again.)
- petermattis 9y ago
  Performance is "ok". CockroachDB 1.0 won't be winning benchmarks, but that was never the goal. We have seen near linear scaling from 3-64 nodes on a uniformly random write workload. And the new distributed SQL execution engine has shown O(num-nodes-in-cluster) speedup on some queries. But none of this has been wrapped up into published numbers, so take it with a grain of salt.