5 ms·

Announcing Yugabyte DB 2.0 GA: High-Performance Distributed SQL

106 points by Avi-D-coder 7y ago

truth_seeker 7y ago
Congratulations to Yugabyte Team. If R2DBC is already supported, it would be nice to receive CDC events through driver instead of forwarding to Local file or Kafka or ES just like Change Streams in RethinkDB or MongoDB.
- kmuthukk 7y ago
  Thx @truth_seeker. YugabyteDB CDC support is in early beta right now. To read more: https://github.com/YugaByte/yugabyte-db/blob/master/architecture/design/docdb-change-data-capture.md https://github.com/YugaByte/yugabyte-db/blob/master/architec...
- rkarthik007 7y ago
  We are working on r2dbc, this is currently an active project. We have made good progress so far. If you have a use case or are in guiding the project, please join our community slack!
dstaley 7y ago
> Again, YugaByte DB's Jepsen tests did not pass. They do not currently pass. Correctness issues we identified in our collaboration, mainly due to non-transactional schema changes, are still unaddressed. YugaByte and I have talked about this.[1] [1] https://twitter.com/jepsen_io/status/1174317882056040456 https://twitter.com/jepsen_io/status/1174317882056040456
- kmuthukk 7y ago
  As Kyle mentioned << Because these problems involve schema changes (e.g. creating tables), they may not impact users frequently. YugaByte doesn't think they're relevant to the core transactional mechanism in YugaByte DB, which is why they're not discussing them when they say "Jepsen tests passed". >> the impact of this is very limited, and not core to the transactional mechanism in YugabyteDB. Most "Distributed DB" vendors do not support transactional DDL yet to our knowledge, and haven't been subjected to this specific test. In any case, I have updated the post/blog to clarify this: << Given that DocDB, Yugabyte DB’s underlying distributed document store, is common across both the YCQL and YSQL APIs, it was no surprise that YSQL passed official Jepsen run safety tests relatively easily (with the exception of transactional DDL support, which almost no other distributed SQL database vendor supports, and we plan to support soon. The real-world impact of this open issue is really small as it is limited to cases where DML happens before DDL has fully finished). >> The ticket tracking this open issue is https://github.com/YugaByte/yugabyte-db/issues/2021 https://github.com/YugaByte/yugabyte-db/issues/2021.
  - tptacek 7y ago
    What does the fact that other vendors don't support the feature have to do with whether you implemented the feature correctly?
    - d3ckard 7y ago
      It helps to establish the software as state-of-the-art, even of particular issue is not addressed yet.
      - tptacek 7y ago
        What does it matter if it's "state-of-the-art" when we're asking whether the database is correct?
        deleted 7y ago
        [deleted]
        d3ckard 7y ago
        There is a world of difference between not having a common and necessary feature and not having feature nobody else has neither. If project tries to establish itself as a serious competitor in a given field, communication is crucial. “We don’t have it but we’re working on it and softwares you currently use probably doesn’t have it” is way different message than “we miss something you probably use”.
        hkolk 7y ago
        Ehm yeah. If it was groundbreaking. But there are 5+ other contenders in this field who are dealing with the same issues, and in some cases are fairing better. We are currently evaluating multiple NewSQL vendors, and it really does come down to the details making or breaking the case. I am not sure what potential NDAs I am on so I can't share details, but there is a sharp difference in one company and another claiming "Distributed Serializability". Cockroach for instance enforces a lot of stuff to maintain consistency, and as a result can be (or is) slower. But at least it's also predictable. In the end it's all trade-offs and I actually like the Yugabyte product a lot. I just wish they are more transparent about what choices they made and the impact of that
- Scarbutt 7y ago
  In more general terms, almost every database we tested with Jepsen fails
  - awinder 7y ago
    "In more general terms, almost every database we tested with Jepsen fails, sometimes in dozens of ways, before its test suite passes. That's how we know Jepsen is working! The vendor headline that comes out of that process is usually "X passes Jepsen"." Read between the lines.
- jwr 7y ago
  I think the title should be changed to include "Jepsen-failing", because the tests did not in fact pass.
  - dang 7y ago
    It will be simpler to just take that reference out of the title.
    - rkarthik007 7y ago
      Yup, already done - we dropped it from the title of the post. Our aim was never to misrepresent. Its a difference of opinion on what "Jepsen testing" represents to us - core transactional correctness or transactional DDL (which most distributed DBs do not support). But the nuance is not worth the hassle, and we're working on it anyway - so we'll just update this back in a few weeks.
- rbjorklin 7y ago
  The full Jepsen analysis can be found here: http://jepsen.io/analyses/yugabyte-db-1.3.1 http://jepsen.io/analyses/yugabyte-db-1.3.1
mrtweetyhack 7y ago
2019, more databases, more programming languages, more everything, less me
shay_ker 7y ago
I didn't know much about what Yugabyte was: https://docs.yugabyte.com/latest/comparisons/ https://docs.yugabyte.com/latest/comparisons/ I wonder what architectural reasons there are that allow them to claim low p-99 latency. Is it because of allowing different consistency levels?
- kmuthukk 7y ago
  This is due to a combination of factors-- the choice of implementation language (C++), a variety of enhancements to RocksDB, consistent reads from leaders (using leader leases) rather than doing a 3-way quorum read, etc. We discuss these aspects in more detail here: [1] https://blog.yugabyte.com/how-we-built-a-high-performance-document-store-on-rocksdb/ https://blog.yugabyte.com/how-we-built-a-high-performance-do... [2] https://blog.yugabyte.com/enhancing-rocksdb-for-speed-scale/ https://blog.yugabyte.com/enhancing-rocksdb-for-speed-scale/ [3] https://blog.yugabyte.com/low-latency-reads-in-geo-distributed-sql-with-raft-leader-leases/ https://blog.yugabyte.com/low-latency-reads-in-geo-distribut...
Nican 7y ago
Can anyone speak about the benchmark posted on the blog post? Is there some fundamental difference to CockroachDB that is causing it to be that much slower? Or is it really just raw performance? EDIT: As another note, I believe Aurora added multi-master support recently. How does that compare as well?
- rkarthik007 7y ago
  Hi @Nican, sure thing. There are two benchmark workloads, simple inserts and secondary index. The simple inserts workload 50M unique key-values into the database using prepare-bind INSERT statements with 256 writer threads running in parallel. There were no reads against the database during this period. The secondary index inserts does the same things against a table which has an index on the value column (forcing each operation to transactionally update the primary and index tables). We use this simple workload frequently to test scalability of YugabyteDB. If interested, here is the sample app repo: https://github.com/YugaByte/yb-sample-apps https://github.com/YugaByte/yb-sample-apps Here is a previous version of the benchmark comparing YCQL (no YSQL here, it was not GA then), it has more details about the scenario we are going for (this part applies to this benchmark also): https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-performance-benchmarks-for-internet-scale-transactional-workloads/ https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-perform... The above post goes through more workloads than this one - we have not had the time to run everything on YSQL yet. The aim of this post was mainly to explore write perf and scalability vs Amazon Aurora. > As another note, I believe Aurora added multi-master support recently. How does that compare as well? Good question. Multi-master deployment sacrifices consistency with last writer wins semantics, so we did not benchmark against that. For example, the benchmark driver can write to one node and read from another before the data was replicated. But may still be interesting from a tradeoff perspective (perf vs consistency). Also, note that we have also just announced multi-master support between separate YugabyteDB cluster - so a benchmark is probably something we should do at some point anyway!
- mikesun 7y ago
  Benchmark ran on each DB’s default isolation mode which are different: serializable for Cockroach and snapshot for YugaByte. https://twitter.com/karthikr/status/1174031604106153984 https://twitter.com/karthikr/status/1174031604106153984
lfittl 7y ago
The "Clusters Created" metric seems to imply that every deployed database sends back tracking information to Yugabyte's servers. I've had to look a bit in the docs to find this page, which seems to confirm it: https://docs.yugabyte.com/latest/manage/diagnostics-reporting/ https://docs.yugabyte.com/latest/manage/diagnostics-reportin... As someone who has seen this tracking-by-default issue play out a few times, I'd recommend having a clear notice on the installation page that includes details on how to opt-out.

106 points by Avi-D-coder 7y ago

Congratulations to Yugabyte Team. If R2DBC is already supported, it would be nice to receive CDC events through driver instead of forwarding to Local file or Kafka or ES just like Change Streams in RethinkDB or MongoDB.

kmuthukk 7y ago
Thx @truth_seeker. YugabyteDB CDC support is in early beta right now. To read more: https://github.com/YugaByte/yugabyte-db/blob/master/architecture/design/docdb-change-data-capture.md https://github.com/YugaByte/yugabyte-db/blob/master/architec...
rkarthik007 7y ago
We are working on r2dbc, this is currently an active project. We have made good progress so far. If you have a use case or are in guiding the project, please join our community slack!

dstaley 7y ago

> Again, YugaByte DB's Jepsen tests did not pass. They do not currently pass. Correctness issues we identified in our collaboration, mainly due to non-transactional schema changes, are still unaddressed. YugaByte and I have talked about this.[1] [1] https://twitter.com/jepsen_io/status/1174317882056040456 https://twitter.com/jepsen_io/status/1174317882056040456

kmuthukk 7y ago
As Kyle mentioned << Because these problems involve schema changes (e.g. creating tables), they may not impact users frequently. YugaByte doesn't think they're relevant to the core transactional mechanism in YugaByte DB, which is why they're not discussing them when they say "Jepsen tests passed". >> the impact of this is very limited, and not core to the transactional mechanism in YugabyteDB. Most "Distributed DB" vendors do not support transactional DDL yet to our knowledge, and haven't been subjected to this specific test. In any case, I have updated the post/blog to clarify this: << Given that DocDB, Yugabyte DB’s underlying distributed document store, is common across both the YCQL and YSQL APIs, it was no surprise that YSQL passed official Jepsen run safety tests relatively easily (with the exception of transactional DDL support, which almost no other distributed SQL database vendor supports, and we plan to support soon. The real-world impact of this open issue is really small as it is limited to cases where DML happens before DDL has fully finished). >> The ticket tracking this open issue is https://github.com/YugaByte/yugabyte-db/issues/2021 https://github.com/YugaByte/yugabyte-db/issues/2021.
- tptacek 7y ago
  What does the fact that other vendors don't support the feature have to do with whether you implemented the feature correctly?
  - d3ckard 7y ago
    It helps to establish the software as state-of-the-art, even of particular issue is not addressed yet.
    - tptacek 7y ago
      What does it matter if it's "state-of-the-art" when we're asking whether the database is correct?
      - deleted 7y ago
        [deleted]
      - d3ckard 7y ago
        There is a world of difference between not having a common and necessary feature and not having feature nobody else has neither. If project tries to establish itself as a serious competitor in a given field, communication is crucial. “We don’t have it but we’re working on it and softwares you currently use probably doesn’t have it” is way different message than “we miss something you probably use”.
        hkolk 7y ago
        Ehm yeah. If it was groundbreaking. But there are 5+ other contenders in this field who are dealing with the same issues, and in some cases are fairing better. We are currently evaluating multiple NewSQL vendors, and it really does come down to the details making or breaking the case. I am not sure what potential NDAs I am on so I can't share details, but there is a sharp difference in one company and another claiming "Distributed Serializability". Cockroach for instance enforces a lot of stuff to maintain consistency, and as a result can be (or is) slower. But at least it's also predictable. In the end it's all trade-offs and I actually like the Yugabyte product a lot. I just wish they are more transparent about what choices they made and the impact of that
Scarbutt 7y ago
In more general terms, almost every database we tested with Jepsen fails
- awinder 7y ago
  "In more general terms, almost every database we tested with Jepsen fails, sometimes in dozens of ways, before its test suite passes. That's how we know Jepsen is working! The vendor headline that comes out of that process is usually "X passes Jepsen"." Read between the lines.
jwr 7y ago
I think the title should be changed to include "Jepsen-failing", because the tests did not in fact pass.
- dang 7y ago
  It will be simpler to just take that reference out of the title.
  - rkarthik007 7y ago
    Yup, already done - we dropped it from the title of the post. Our aim was never to misrepresent. Its a difference of opinion on what "Jepsen testing" represents to us - core transactional correctness or transactional DDL (which most distributed DBs do not support). But the nuance is not worth the hassle, and we're working on it anyway - so we'll just update this back in a few weeks.
rbjorklin 7y ago
The full Jepsen analysis can be found here: http://jepsen.io/analyses/yugabyte-db-1.3.1 http://jepsen.io/analyses/yugabyte-db-1.3.1

mrtweetyhack 7y ago

2019, more databases, more programming languages, more everything, less me

shay_ker 7y ago

I didn't know much about what Yugabyte was: https://docs.yugabyte.com/latest/comparisons/ https://docs.yugabyte.com/latest/comparisons/ I wonder what architectural reasons there are that allow them to claim low p-99 latency. Is it because of allowing different consistency levels?

kmuthukk 7y ago
This is due to a combination of factors-- the choice of implementation language (C++), a variety of enhancements to RocksDB, consistent reads from leaders (using leader leases) rather than doing a 3-way quorum read, etc. We discuss these aspects in more detail here: [1] https://blog.yugabyte.com/how-we-built-a-high-performance-document-store-on-rocksdb/ https://blog.yugabyte.com/how-we-built-a-high-performance-do... [2] https://blog.yugabyte.com/enhancing-rocksdb-for-speed-scale/ https://blog.yugabyte.com/enhancing-rocksdb-for-speed-scale/ [3] https://blog.yugabyte.com/low-latency-reads-in-geo-distributed-sql-with-raft-leader-leases/ https://blog.yugabyte.com/low-latency-reads-in-geo-distribut...

Nican 7y ago

Can anyone speak about the benchmark posted on the blog post? Is there some fundamental difference to CockroachDB that is causing it to be that much slower? Or is it really just raw performance? EDIT: As another note, I believe Aurora added multi-master support recently. How does that compare as well?

rkarthik007 7y ago
Hi @Nican, sure thing. There are two benchmark workloads, simple inserts and secondary index. The simple inserts workload 50M unique key-values into the database using prepare-bind INSERT statements with 256 writer threads running in parallel. There were no reads against the database during this period. The secondary index inserts does the same things against a table which has an index on the value column (forcing each operation to transactionally update the primary and index tables). We use this simple workload frequently to test scalability of YugabyteDB. If interested, here is the sample app repo: https://github.com/YugaByte/yb-sample-apps https://github.com/YugaByte/yb-sample-apps Here is a previous version of the benchmark comparing YCQL (no YSQL here, it was not GA then), it has more details about the scenario we are going for (this part applies to this benchmark also): https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-performance-benchmarks-for-internet-scale-transactional-workloads/ https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-perform... The above post goes through more workloads than this one - we have not had the time to run everything on YSQL yet. The aim of this post was mainly to explore write perf and scalability vs Amazon Aurora. > As another note, I believe Aurora added multi-master support recently. How does that compare as well? Good question. Multi-master deployment sacrifices consistency with last writer wins semantics, so we did not benchmark against that. For example, the benchmark driver can write to one node and read from another before the data was replicated. But may still be interesting from a tradeoff perspective (perf vs consistency). Also, note that we have also just announced multi-master support between separate YugabyteDB cluster - so a benchmark is probably something we should do at some point anyway!
mikesun 7y ago
Benchmark ran on each DB’s default isolation mode which are different: serializable for Cockroach and snapshot for YugaByte. https://twitter.com/karthikr/status/1174031604106153984 https://twitter.com/karthikr/status/1174031604106153984

lfittl 7y ago

The "Clusters Created" metric seems to imply that every deployed database sends back tracking information to Yugabyte's servers. I've had to look a bit in the docs to find this page, which seems to confirm it: https://docs.yugabyte.com/latest/manage/diagnostics-reporting/ https://docs.yugabyte.com/latest/manage/diagnostics-reportin... As someone who has seen this tracking-by-default issue play out a few times, I'd recommend having a clear notice on the installation page that includes details on how to opt-out.