8 ms·

I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to w

I am one of the Maintainers of Vitess and I just wanted to pipe in on a few points. The comparison chart lists vitess as not having "High Performance" due to what they are saying is a single coordinator node ( vtgate ). You can actually have as many of those as you want to scale Vitess far beyond what any other system ( including yugabyte ) offers in terms of performance. We recently did a benchmark in partnership with AWS showing how far you could push AWS Aurora using Vitess ( https://planetscale.com/news/planetscale-aws-benchmark https://planetscale.com/news/planetscale-aws-benchmark ) Secondly is the claim that there are no distributed transactions or cross shard joins. There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions. We do recommend that you are aware of the sharding mechanism as we will not trigger a cross shard transaction unless we need to. Finally they do say there is no Native Failover/Repair which is only technically accurate. We use a third party tool called orchistrator to do the fail overs, and we recommend you run that along side the cluster so yes its not "built in", but it will launch as part of our Helm Chart fully configured to automatically do native fail overs.

gigatexal 7y ago
Vitess runs YouTube. Mic drop. Nothing else to say.
- gigatexal 7y ago
  To be fair. There has been a lot of work to make it easier for mere mortals to run it. So take the complexity of it into consideration when evaluating it for use.
espadrine 7y ago
Vitess is great. Although I am wondering whether the Planetscale achievement is partially attributable to the fantastic work put in the closed-source Aurora. In particular, it is an order of magnitude better than the displayed CockroachDB benchmark[0], with 81 c5d.9xlarge nodes instead of Vitess’ 64 r4.16xlarge. Can you still beat that with MySQL or MariaDB? [0]: https://www.cockroachlabs.com/docs/v19.2/performance.html https://www.cockroachlabs.com/docs/v19.2/performance.html
- PeterZaitsev 7y ago
  I would imagine this is some form of AWS partnership to showcase Aurora here. I do not think results with MySQL would be substantially different. If anything I would expect better price performance.
  - dkhenry 7y ago
    That is correct, this was done in partnership with AWS to show off Aurora, however we have achieved similar results with stock MySQL. We are pretty confident that with standard MySQL using MyRocks and some high end storage devices we will be able to beat those numbers with fewer resources.
    - pm90 7y ago
      Don't mean to be crass... but why not do what you just describe and publish it to promote Vitess? Would lay the argument to rest :)
      - dkhenry 7y ago
        The cost to run those benchmarks with AWS was close to $50,000 just in infrastructure cost ( that was the main reason we jumped from 16 shards to 64 shards at the larger instance size, we wanted to show the top end, but we didn't have the resources to do all the sizes in between ), that doesn't even account for the engineering time to put together the solution and run the tests. We would love to have more funding to run those kinds of tests, but Vitess doesn't have a big sponsoring company to bankroll it the way some other projects do.
irfansharif 7y ago
Those numbers are surprising to me. Have latency charts to share? And are you using think time? http://www.tpc.org/tpcc/detail.asp http://www.tpc.org/tpcc/detail.asp
- espadrine 7y ago
  Hmm, it does seem like they are not using think time. From the official TPC-C specification[0]: > The maximum throughput is achieved with infinitely fast transactions resulting in a null response time and minimum required wait times. The intent of this clause is to prevent reporting a throughput that exceeds this maximum, which is computed to be 12.86 tpmC per warehouse. So the maximum result they should be able to get at 100K warehouses is 1,286,000 tpmC. To reach higher, they should do what Alibaba did[1] and use 4,794,240 warehouses. They got officially accepted with a result which dwarfs even Planetary’s incorrect benchmark. [0]: http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_... [1]: https://www.alibabacloud.com/blog/oceanbase-did-better-than-any-other-database-in-the-tpc-c-benchmark_595536 https://www.alibabacloud.com/blog/oceanbase-did-better-than-...
evanweaver 7y ago
> There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions. The Vitess docs explicitly say that 2PC transactions are not isolated and are not ACID. Did something change?
- dkhenry 7y ago
  We will normally list it as ACI*D since there is a situation where you can break isolation.
  - evanweaver 7y ago
    What situation? Are cross-shard transactions ever isolated?
    - dkhenry 7y ago
      Yes they are normally isolated, however its only at a READ_COMMITTED level, and a nuance of the implementation is that you may see committed data rolled back by the protocol in the event of a failure. Its still technically READ_COMMITTED, but its an unexpected behavior from stock MySQL so we make sure to qualify our documentation.
      - kd5bjo 7y ago
        I may be just tripping over semantics here, but how can you consider data that may still be automatically rolled back to be “committed”? I thought that’s supposed to mean the data has been fully stored such that it can only be changed/removed by a subsequent transaction.
        dkhenry 7y ago
        The data will be committed, but you may get a subsequent read that has the previous value, before it is overwritten by the final value. This would only occur if the shard where the commit is occurring fails, while the promoted shard replays the transaction before the final commit is propagated to the user. Since the shard as failed is impossible for a single transaction to experience this behavior, but an outside observer would be able to see this behavior. Transactionally everything would still be isolated, but outside the transaction you would see behavior you won't expect.

gigatexal 7y ago

Vitess runs YouTube. Mic drop. Nothing else to say.

gigatexal 7y ago
To be fair. There has been a lot of work to make it easier for mere mortals to run it. So take the complexity of it into consideration when evaluating it for use.

espadrine 7y ago

Vitess is great. Although I am wondering whether the Planetscale achievement is partially attributable to the fantastic work put in the closed-source Aurora. In particular, it is an order of magnitude better than the displayed CockroachDB benchmark[0], with 81 c5d.9xlarge nodes instead of Vitess’ 64 r4.16xlarge. Can you still beat that with MySQL or MariaDB? [0]: https://www.cockroachlabs.com/docs/v19.2/performance.html https://www.cockroachlabs.com/docs/v19.2/performance.html

PeterZaitsev 7y ago
I would imagine this is some form of AWS partnership to showcase Aurora here. I do not think results with MySQL would be substantially different. If anything I would expect better price performance.
- dkhenry 7y ago
  That is correct, this was done in partnership with AWS to show off Aurora, however we have achieved similar results with stock MySQL. We are pretty confident that with standard MySQL using MyRocks and some high end storage devices we will be able to beat those numbers with fewer resources.
  - pm90 7y ago
    Don't mean to be crass... but why not do what you just describe and publish it to promote Vitess? Would lay the argument to rest :)
    - dkhenry 7y ago
      The cost to run those benchmarks with AWS was close to $50,000 just in infrastructure cost ( that was the main reason we jumped from 16 shards to 64 shards at the larger instance size, we wanted to show the top end, but we didn't have the resources to do all the sizes in between ), that doesn't even account for the engineering time to put together the solution and run the tests. We would love to have more funding to run those kinds of tests, but Vitess doesn't have a big sponsoring company to bankroll it the way some other projects do.

irfansharif 7y ago

Those numbers are surprising to me. Have latency charts to share? And are you using think time? http://www.tpc.org/tpcc/detail.asp http://www.tpc.org/tpcc/detail.asp

espadrine 7y ago
Hmm, it does seem like they are not using think time. From the official TPC-C specification[0]: > The maximum throughput is achieved with infinitely fast transactions resulting in a null response time and minimum required wait times. The intent of this clause is to prevent reporting a throughput that exceeds this maximum, which is computed to be 12.86 tpmC per warehouse. So the maximum result they should be able to get at 100K warehouses is 1,286,000 tpmC. To reach higher, they should do what Alibaba did[1] and use 4,794,240 warehouses. They got officially accepted with a result which dwarfs even Planetary’s incorrect benchmark. [0]: http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_... [1]: https://www.alibabacloud.com/blog/oceanbase-did-better-than-any-other-database-in-the-tpc-c-benchmark_595536 https://www.alibabacloud.com/blog/oceanbase-did-better-than-...

evanweaver 7y ago

> There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions. The Vitess docs explicitly say that 2PC transactions are not isolated and are not ACID. Did something change?

dkhenry 7y ago
We will normally list it as ACI*D since there is a situation where you can break isolation.
- evanweaver 7y ago
  What situation? Are cross-shard transactions ever isolated?
  - dkhenry 7y ago
    Yes they are normally isolated, however its only at a READ_COMMITTED level, and a nuance of the implementation is that you may see committed data rolled back by the protocol in the event of a failure. Its still technically READ_COMMITTED, but its an unexpected behavior from stock MySQL so we make sure to qualify our documentation.
    - kd5bjo 7y ago
      I may be just tripping over semantics here, but how can you consider data that may still be automatically rolled back to be “committed”? I thought that’s supposed to mean the data has been fully stored such that it can only be changed/removed by a subsequent transaction.
      - dkhenry 7y ago
        The data will be committed, but you may get a subsequent read that has the previous value, before it is overwritten by the final value. This would only occur if the shard where the commit is occurring fails, while the promoted shard replays the transaction before the final commit is propagated to the user. Since the shard as failed is impossible for a single transaction to experience this behavior, but an outside observer would be able to see this behavior. Transactionally everything would still be isolated, but outside the transaction you would see behavior you won't expect.