We had a sales call with them last year and got to speak to one of their devs. The impression they gave was that it was mostly ex-Facebook data guys that left to start a company based on the work they did on Cassandra and a few other internal projects.
The really interesting feature, to us, was the promise that once the Postgres-compatible layer was complete, we could use whatever semantics were appropriate for our business use case while using the same logical database cluster. We could use the Redis interface for persistent caching, the CQL interface for our NoSQL-appropriate use cases and the Postgres interface for our more traditional use cases. And the client libraries for all those interfaces are the same ones we already use to talk to Redis and Postgres (our conversation happened because we were starting a project that was more NoSQL-appropriate, so we weren’t using Cassandra yet), so very little of our code would have to change.
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.
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.
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
I wanted to add a few details to the previous reply.
While the Raft/HybridTime implementation has its roots in Apache Kudu the results will NOT be quite applicable to Kudu. Aside from the fact that the code base has evolved/diverged over the 3+ years, there are key/relevant areas (ones very relevant to these Jepsen tests) where YugaByte DB has added capabilities or follows a different design than Kudu. For example:
-- Leader Leases: YugaByte DB doesn't use Raft consensus for reads. Instead, we have implemented "leader leases" to ensure safety in allowing reads to be served from a tablet's Raft leader.
-- Distributed/Multi-Shard Transactions: YugaByte DB uses a home grown (https://docs.yugabyte.com/latest/architecture/transactions/t...) protocol based on two-phase commit across multiple Raft groups. Capabilities like secondary indexes, multi-row updates use multi-shard transactions.
-- Allowing online/dynamic Raft membership changes so that tablets can be moved (such as for load-balancing to new nodes).
Yes, it does. At the core, the raft implementation is still based on kudu's. But, these areas have been worked on actively so the implementations might has diverged a little.
May be worth looking through the individual issues to see what applies and what doesn't:
Not a comment on YugeByte, but... I love it when a new Jepsen report get released. Kyle Kingsbury has single-handedly raised the bar on an entire industry. (Well, not single-handedly anymore, but still.)
Couldn't agree more. There are 3 sources of information regarding database serializability/linearizability:
1. Marketing material (mostly useless)
2. Individual projects/post-mortems (50/50 here; some just mis-use the technology from the get-go, others have valid feedback, but it's tough to determine when either applies)
3. Jepsen Tests (which is more like independently verifiable science)
Sure, you can decide that your social-media solution has no need for consistency (or even durability!) - but in my experience, most solutions don't have that flexibility.
I think the YB team members are probably best equipped to talk about this, but I can note that while some databases do build their own clock synchronization protocol, many prefer to let the OS handle clocks. For one thing, clock sync is surprisingly tricky to do well, so it makes sense to write daemons that do it well once and be able to re-use them in lots of contexts. There's also the question of HW support: in theory, datacenter and hardware providers could do better than pure-software time synchronization by, say, offering dedicated physical links to a local atomic + GPS clock ensemble. AWS TimeSync is a step in this direction, and I wouldn't be surprised if we see more accurate clocks in the future.
There are still tons of caveats with this idea--Linux and most database software ain't realtime, for starters--but you can imagine a world in which clock errors are sufficiently bounded and infrequent that they no longer represent the most urgent threat to safety. That's ultimately a quantitative risk assessment.
My suspicion is that DB vendors like YugaByte and CockroachDB are making a strategic bet that although clocks right now are pretty terrible, they won't be that way forever. I'd like to see more rigorous measurement on this front, because while I've got plenty of anecdotes, I don't think we have a broad statistical picture of how bad typical clocks are, and whether they're improving.
Jepsen is not a performance test; we verify safety. I haven't looked at ScyllaDB personally, but you can read about Scylla's own work testing their database here [1], and see some of the issues they found here [2].
[+] [-] the_duke|7 years ago|reply
Seems to be another distributed SQL (aka 'newsql') alternative to TiDB and CockroachDB.
Based on RocksDB (like Cockroach) with a custom distributed key/val layer and and additional SQL layer on top. PostgreSQL protocol compatible.
OS with Apache license.
Seems interesting. (when ignoring the "planet scale SQL" marketing speak... [1])
[1] https://www.yugabyte.com/planet-scale-sql/
[+] [-] curun1r|7 years ago|reply
The really interesting feature, to us, was the promise that once the Postgres-compatible layer was complete, we could use whatever semantics were appropriate for our business use case while using the same logical database cluster. We could use the Redis interface for persistent caching, the CQL interface for our NoSQL-appropriate use cases and the Postgres interface for our more traditional use cases. And the client libraries for all those interfaces are the same ones we already use to talk to Redis and Postgres (our conversation happened because we were starting a project that was more NoSQL-appropriate, so we weren’t using Cassandra yet), so very little of our code would have to change.
[+] [-] marknadal|7 years ago|reply
But their willingness to license it as truly open, Apache-style, instantly is a big win-over.
I'm a competitor, but I can tell these guys/gals are genuine in their efforts.
We need more people, teams, and DBs like YugaByteDB in the world.
Thank you for your efforts.
[+] [-] spullara|7 years ago|reply
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|7 years ago|reply
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|7 years ago|reply
[+] [-] danburkert|7 years ago|reply
[+] [-] kmuthukk|7 years ago|reply
While the Raft/HybridTime implementation has its roots in Apache Kudu the results will NOT be quite applicable to Kudu. Aside from the fact that the code base has evolved/diverged over the 3+ years, there are key/relevant areas (ones very relevant to these Jepsen tests) where YugaByte DB has added capabilities or follows a different design than Kudu. For example:
-- Leader Leases: YugaByte DB doesn't use Raft consensus for reads. Instead, we have implemented "leader leases" to ensure safety in allowing reads to be served from a tablet's Raft leader.
-- Distributed/Multi-Shard Transactions: YugaByte DB uses a home grown (https://docs.yugabyte.com/latest/architecture/transactions/t...) protocol based on two-phase commit across multiple Raft groups. Capabilities like secondary indexes, multi-row updates use multi-shard transactions.
-- Allowing online/dynamic Raft membership changes so that tablets can be moved (such as for load-balancing to new nodes).
regards Kannan (Co-founder @ YugaByte)
[+] [-] acubel23|7 years ago|reply
May be worth looking through the individual issues to see what applies and what doesn't:
https://github.com/YugaByte/yugabyte-db/projects/11
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] robterrell|7 years ago|reply
[+] [-] Jupe|7 years ago|reply
1. Marketing material (mostly useless)
2. Individual projects/post-mortems (50/50 here; some just mis-use the technology from the get-go, others have valid feedback, but it's tough to determine when either applies)
3. Jepsen Tests (which is more like independently verifiable science)
Sure, you can decide that your social-media solution has no need for consistency (or even durability!) - but in my experience, most solutions don't have that flexibility.
[+] [-] shin_lao|7 years ago|reply
[+] [-] aphyr|7 years ago|reply
There are still tons of caveats with this idea--Linux and most database software ain't realtime, for starters--but you can imagine a world in which clock errors are sufficiently bounded and infrequent that they no longer represent the most urgent threat to safety. That's ultimately a quantitative risk assessment.
My suspicion is that DB vendors like YugaByte and CockroachDB are making a strategic bet that although clocks right now are pretty terrible, they won't be that way forever. I'd like to see more rigorous measurement on this front, because while I've got plenty of anecdotes, I don't think we have a broad statistical picture of how bad typical clocks are, and whether they're improving.
[+] [-] truth_seeker|7 years ago|reply
[+] [-] aphyr|7 years ago|reply
[1]: https://www.scylladb.com/2016/02/11/jepsen-testing/
[2]: https://github.com/scylladb/scylla/issues?utf8=%E2%9C%93&q=i...
[+] [-] manigandham|7 years ago|reply
It offers access to the data in multiple interfaces: Redis, Cassandra CQL and now PostgreSQL.