3 ms·

CockroachDB sounds amazing, and all of these blog posts are great to read, but I'm yet to see someone talk about production experiences in comment threads when

• tomsthumb 8y ago
  A previous company I worked at ran it in production. No problems with cockroach per se, but the code they wrote on top of it (to manage multiple writers) was a steaming pile. I’m not convinced that, even if the shim layer was better, it would have been the optimal design decision, but cockroach itself did pretty well while handling a relatively large amount of data all things considered.
  • karmakaze 8y ago
    The thing I know to watch out for is the minimum latency of requests. CRDB doesn't work well for workloads which make many DB queries per 'event' (e.g. N+1 queries which can and should be avoided). Why was it necessary to 'manage multiple writers' in that use case you encountered?
    • tomsthumb 8y ago
      My somewhat embarassed apologies. I have confused RocksDB with CockroachDB. My understanding is that, at the time of development, Rocks itself did not support multiple writers. This was in 2015, or maybe 2014. At this point it looks like TransactionsDB might cover that, but I was not super familiar with that particular project, nor am I super familiar with RocksDB in general. I do know that they asserted Rocks could not handle multiple writers the way they wanted, and they needed something which handled SSTs well. Rocks was chosen and the shim layer was written on that assumption.
      • karmakaze 8y ago
        Thanks for clarifying. I'm also interested in RocksDB, in particular how it's being integrated into the (poorly named) WebScaleSQL MySql variant.