Announcing Yugabyte DB 2.0 GA: High-Performance Distributed SQL | Hacker News Reader

Announcing Yugabyte DB 2.0 GA: High-Performance Distributed SQL

blog.yugabyte.com

106 pointsAvi-D-coder28 comments

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-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.

> 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

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.

What does the fact that other vendors don't support the feature have to do with whether you implemented the feature correctly?

It helps to establish the software as state-of-the-art, even of particular issue is not addressed yet.

What does it matter if it's "state-of-the-art" when we're asking whether the database is correct?

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”.

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

Hi @hkolk,

Thanks for your feedback! Not sure when you tried yugabyteDB, but our serializable isolation level and YSQL API (which is needed to exercise serializability) were in beta till a couple of days ago. That said, if you can share some feedback, that would help us out immensely. All kinds of feedback welcome - be it about the product or why you feel we are not transparent. Absolute transparency has always been our goal, your feedback will definitely help us improve.

(cto/co-founder)

To add some context: every Jepsen test involves table creation. YugaByte DB's table-creation process was exceptionally fragile, which is what prompted tests specifically pushing on that behavior.

I think if the authors of the tests say you failed the tests, then you failed the tests.

'Jepsen tested' is a clever dark-patterny choice of technically correct but entirely misleading language here.

Why not write: "passed all Jepsen tests except transactional DDL"?

> 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

So... database migrations.

I was actually thinking of exactly this problem, but it turned out to be difficult to demonstrate, because YB doesn't allow you to add columns with default values to an existing table.

There might be other ways this could play out in migrations--I haven't had time to look deeply.

In more general terms, almost every database we tested with Jepsen fails

"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.

I think the title should be changed to include "Jepsen-failing", because the tests did not in fact pass.

It will be simpler to just take that reference out of the title.

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.

The full Jepsen analysis can be found here: http://jepsen.io/analyses/yugabyte-db-1.3.1

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.

Thx @truth_seeker.

YugabyteDB CDC support is in early beta right now. To read more: https://github.com/YugaByte/yugabyte-db/blob/master/architec...

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!

I didn't know much about what Yugabyte was:

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?

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-do...

[2] https://blog.yugabyte.com/enhancing-rocksdb-for-speed-scale/

[3] https://blog.yugabyte.com/low-latency-reads-in-geo-distribut...

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?

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

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-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!

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

Reply on news.ycombinator.com