kmuthukk's comments

Regarding the last point << Yugabyte was tested by Kyle Kingsbury back in 2019, which uncovered some deficiencies. Not sure what the state is today. The YB team also runs their own Jepsen tests now as part of CI, which is a good sign. >>

Please see this blog https://www.yugabyte.com/blog/chaos-testing-yugabytedb/ for latest updates, as well as information on additional in-house built frameworks for resiliency and consistency testing.

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

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.

Thx @truth_seeker.

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

hi @mpercy,

Thanks for correcting me on the dynamic consensus membership change. Looks like the basic support was indeed there, but several important enhancements were needed (for correctness and usability).

- To make the "online" piece of the membership change work correctly we added support for LEARNER (PRE VOTER) role (where the new member enters in a non-voting mode till it's caught up). https://github.com/YugaByte/yugabyte-db/commit/909d26e31ecd0....

- Load Balancing (which uses the membership changes) is automatic. (https://github.com/YugaByte/yugabyte-db/commit/e4667eb7ec0e6...)

- Remote bootstrap (due to membership changes) also has undergone substantial changes given that YugaByte DB uses a customize/extended version of RocksDB as the storage engine and does a tighter coupling of Raft with RocksDB storage engine. (https://github.com/YugaByte/yugabyte-db/blob/master/docs/ext...)

- Dynamic Leader Balancing is also new-- it causes leadership to be proactively altered in a running system to ensure each node is the leader for a similar number of tablets.

regards, Kannan

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

regards Kannan (Co-founder @ YugaByte)

YugaByte DB's design is that a YB cluster supports Postgres in a native, self-contained & scale-out manner (much like YugaByte's Cassandra and Redis flavored offerings).

At a high-level, the upper half of the Postgres DB is being largely reused. The lower-half, i.e. the distributed table storage layer, uses YugaByte's underlying core-- a transactional and distributed document-based storage engine.

For the DB to be scalable, the lower-half being distributed is necessary but NOT sufficient. The upper-half also needs to be extended to be made aware of other nodes executing DDL/DML statements and dealing with related concurrency while still allowing for linear scale. Also, making the optimizer aware of the distributed nature of table storage is the other major piece of work in the upper-half.

These changes required in the upper half is what makes the "100% pure extension" model a bit harder... but that's something we intend to explore jointly with the Postgres community.