3 ms·

Since it doesn't support serializable transactions I'm not sure why FoundationDB would be mentioned as a comparison in the write up. The operations it does supp

Since it doesn't support serializable transactions I'm not sure why FoundationDB would be mentioned as a comparison in the write up. The operations it does support seem to set the bar pretty low as to what to test. edit: good reply by the founder of YugaByte but for some reason the comment is dead. I have noticed that when founders don't have an account on here and then something comes up where they need to reply their comments are often deaded.

mbautin 8y ago
We have run a significant number of useful/practical tests via Jepsen, that only need snapshot isolation level. The tests that were run included a single-key counter test, set tests with and without a secondary index, a "long fork" test ensuring that the order of operations is the same when observed by different clients, and a bank test verifying that the total balance of multiple accounts stays the same when cross-shard transactions transfer funds between pairs of accounts. These tests were run under a variety of failure modes, including different types of network partitions and clock skew. Also, snapshot isolation covers a very large spectrum of practical uses cases, including secondary indexes, for building real-world applications. Having said that, we have recently added support for serializable isolation level to YugaByte DB, and we will be adding tests to the Jepsen suite for that in near term. Regards, Mikhail (a co-founder at YugaByte)
gigatexal 8y ago
We use cockroachDB in production and before that we were on MySQL and as of yet we don’t have a specific usecase where we use serializable transactions. Snapshot isolation or even read committed is just fine. So I don’t think it’s absolutely necessary
- gigatexal 8y ago
  To be clear there’s no way around serializable transactions in cockroachDB. We have had to adapt our monolith to it (we’re thinking of ways to make it more nimble by breaking out services etc). But the point I was making was that we had MySQL for a while and never ran into issues with its isolation levels until it stopped scaling. Instead of vitess or some other MySQL system we went with cockroach after finding vitess didn’t fit us — too complicated and too many moving parts. CockroachDB just works. Also moving to k8s adds complexity too for a monolith built and run on VMs. But so far so good. Cockroach runs fast and is performant given production queries. And ops is happy because it self heals.
  - redwood 8y ago
    First time I've heard about a production use case. Care to share any details?

mbautin 8y ago

We have run a significant number of useful/practical tests via Jepsen, that only need snapshot isolation level. The tests that were run included a single-key counter test, set tests with and without a secondary index, a "long fork" test ensuring that the order of operations is the same when observed by different clients, and a bank test verifying that the total balance of multiple accounts stays the same when cross-shard transactions transfer funds between pairs of accounts. These tests were run under a variety of failure modes, including different types of network partitions and clock skew. Also, snapshot isolation covers a very large spectrum of practical uses cases, including secondary indexes, for building real-world applications. Having said that, we have recently added support for serializable isolation level to YugaByte DB, and we will be adding tests to the Jepsen suite for that in near term. Regards, Mikhail (a co-founder at YugaByte)

gigatexal 8y ago

We use cockroachDB in production and before that we were on MySQL and as of yet we don’t have a specific usecase where we use serializable transactions. Snapshot isolation or even read committed is just fine. So I don’t think it’s absolutely necessary

gigatexal 8y ago
To be clear there’s no way around serializable transactions in cockroachDB. We have had to adapt our monolith to it (we’re thinking of ways to make it more nimble by breaking out services etc). But the point I was making was that we had MySQL for a while and never ran into issues with its isolation levels until it stopped scaling. Instead of vitess or some other MySQL system we went with cockroach after finding vitess didn’t fit us — too complicated and too many moving parts. CockroachDB just works. Also moving to k8s adds complexity too for a monolith built and run on VMs. But so far so good. Cockroach runs fast and is performant given production queries. And ops is happy because it self heals.
- redwood 8y ago
  First time I've heard about a production use case. Care to share any details?