Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed SQL vs. NewSQL

blog.yugabyte.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Distributed SQL vs. NewSQL

#31

Post by irfansharif »

dkhenry wrote: post #23

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 wi…

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

Re: Distributed SQL vs. NewSQL

#32

Post by espadrine »

irfansharif wrote: post #31
dkhenry wrote: post #23

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 wi…

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

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

[1]: https://www.alibabacloud.com/blog/oceanbase-did-better-than-...

Re: Distributed SQL vs. NewSQL

#33

Post by bithavoc »

knz42 wrote: post #26
bithavoc wrote: post #17

Earlier quoted context omitted.

A few weeks back after my attempt to switch to Yugabyte I decided to commit to CockroachDB in a dedicated cluster with TLS, my backend runs migrations including creating the database but only admins and root are able to create databases but because TLS was enabled my root user didn't work anymore. I was not able to create more admin users because that's part of the RBAC Enterprise offering. The database was there but…

Hello bithavoc, I happen to be currently working on that area of CockroachDB and I would like to help. To start with, any scenario that you find where a secure deployment without an Enterprise license makes you unable to operate your apps using the core features, would be a serious bug on our side and we'd give it high priority. There is no intent to do bait-and-switch here. If I read between your lines I can see the…

Correct, I’m using TLS with password authentication, I don’t want to generate certs for my backend user, so yes, root password authorization solves the issue. I can wait for 20.1, should be coming up this month right?

Re: Distributed SQL vs. NewSQL

#34

Post by dkhenry »

PeterZaitsev wrote: post #30
espadrine wrote: post #29

Earlier quoted context omitted.

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

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.

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.

Re: Distributed SQL vs. NewSQL

#35

Post by irfansharif »

bithavoc wrote: post #33
knz42 wrote: post #26

Earlier quoted context omitted.

Hello bithavoc, I happen to be currently working on that area of CockroachDB and I would like to help. To start with, any scenario that you find where a secure deployment without an Enterprise license makes you unable to operate your apps using the core features, would be a serious bug on our side and we'd give it high priority. There is no intent to do bait-and-switch here. If I read between your lines I can see the…

Correct, I’m using TLS with password authentication, I don’t want to generate certs for my backend user, so yes, root password authorization solves the issue. I can wait for 20.1, should be coming up this month right?

v20.1 is slated for release in April.

Re: Distributed SQL vs. NewSQL

#36

Post by evanweaver »

dkhenry wrote: post #23

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 wi…

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

Re: Distributed SQL vs. NewSQL

#37

Post by dkhenry »

evanweaver wrote: post #36
dkhenry wrote: post #23

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 wi…

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

We will normally list it as ACI*D since there is a situation where you can break isolation.

Re: Distributed SQL vs. NewSQL

#38

Post by evanweaver »

dkhenry wrote: post #37
evanweaver wrote: post #36

Earlier quoted context omitted.

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

We will normally list it as ACI*D since there is a situation where you can break isolation.

What situation? Are cross-shard transactions ever isolated?

Re: Distributed SQL vs. NewSQL

#39

Post by jhugg »

Re VoltDB:

>In VoltDB, all replicas for a given shard are updated synchronously by the client application. This is where VoltDB pays a significant performance penalty for write operations when compared with Raft/Paxos-powered distributed SQL databases. Distributed consensus protocols like Raft and Paxos require writes to be sent to all replicas but commit as soon as a majority of replicas have acknowledged the request. Waiting for all replicas to respond is not necessary since the consensus can be established with a majority. Additionally, VoltDB does not detect network partitions by default and requires a special network-fault-protection mode to be configured. When a node of the cluster gets partitioned, the network-fault-protection mode comes into play. It negatively impacts cluster performance by increasing cluster recovery time for not only accepting writes on the shards whose replica was lost in the node partition but also for repopulating the data on the partitioned node when it joins back the cluster.

Wow. Basically none of that is true.

Re: Distributed SQL vs. NewSQL

#40

Post by dkhenry »

evanweaver wrote: post #38
dkhenry wrote: post #37

Earlier quoted context omitted.

We will normally list it as ACI*D since there is a situation where you can break isolation.

What situation? Are cross-shard transactions ever isolated?

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.
Post reply on HN