Hacker News Reader

Comment by dstaley | Hacker News Reader

> 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

View on HN

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.

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

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.

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.

Reply on news.ycombinator.com