5 ms·

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

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
        rkarthik007 7y ago
        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)
  - aphyr 7y ago
    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.
missosoup 7y ago
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.
riku_iki 7y ago
Why not write: "passed all Jepsen tests except transactional DDL"?
ben509 7y ago
> 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.
- aphyr 7y ago
  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.

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
      - rkarthik007 7y ago
        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)
- aphyr 7y ago
  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.

missosoup 7y ago

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.

riku_iki 7y ago

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

ben509 7y ago

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

aphyr 7y ago
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.