
Distributed SQL vs. NewSQL - sickeythecat
https://blog.yugabyte.com/distributedsql-vs-newsql/
======
dkhenry
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.

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

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

~~~
colanderman
Ya. The stuff on NuoDB is basically all untrue or misleading as well (source:
I work there). I wouldn't put too much stock in this self-promotion article.

------
bithavoc
I tried Yugabyte a few weeks back, the TServer kept crashing while my backend
was creating some very simple tables. I'm stuck with CockroachDB for the time
being.

~~~
vvern
> I'm stuck with CockroachDB for the time being.

Would you care to share any negative experiences you've had with CockroachDB?
What is motivating your desire to look elsewhere?

~~~
bithavoc
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 the authorization system triggers before
IF NOT EXISTS condition, so I had to make changes to make it work in
production. I honestly thought that if I stayed away from Enterprise features
then I would be fine, but no: it seems like if I wanted to deploy my backend
on-premise, the deployment process would have to include an step to run the
CREATE DATABASE script out of band either before enabling TLS or via
localhost(?) in a database node, otherwise I'm fucked unless the client buys
CRDB Enterprise to smooth out the deployment process. That's a very extreme
case of Open-Core money-squeezing shit I would like to stay away from.

CockroachDB Core is fine as a product, the docs are up to date and it's not
hard to operate, all that is appreciated it. I just don't think I'm the target
user, unless you make a shit ton of money as you scale it will be hard to
operate without:

\- Distributed Backups(Enterprise)

\- Follower Reads(Enterprise) (no, follow-the-workload doesn't cut it)

\- RBAC(Enterprise)

Yugabyte offers all that in their open-source license, which is why I'm
rooting for them, that in addition to Change Data capture(Enterprise offering
in CockroachDB) is also included.

~~~
knz42
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 following:

\- you need an admin user to create databases;

\- the only admin user is root;

\- it appears that you cannot log in with root on a secure cluster (TLS
enabled). Is that understanding correct?

I think I understand the following: your SQL client is attempting to connect
using TLS but without presenting the root client cert to the server. The root
client cert is a cert that you can generate using the cluster's CA key (using
the `cockroach cert` command). Without a valid client cert, the connection is
refused.

You may think this seems to work for other users than root. This is because
for other users, when cert validation fails, the server allows the client to
use a password instead. This choice to use a password is not available for the
root user up to and including 19.2.

Here is your way forward:

\- either you configure your SQL client that creates database to present the
root client cert to the server. This will enable you to use the root account
on a secure server and create databases (and other users, and then assign
privileges to these users over the new database).

\- or, you wait until crdb 20.1, where it will be possible to configure a
password for the root user and let root clients use password authentication
instead of presenting client TLS certs.

Does this help?

If it doesn't please create an issue on github and describe your situation in
more details and cc me (@knz). Thank you

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

~~~
irfansharif
v20.1 is slated for release in April.

------
themoop
Yugabyte has great articles in general and seems almost to be good to be true
what I have read.

It is just missing a bit of independent third party reviews but it does look
interesting.

Anyone with hands on experience?

~~~
dilloc
Yugabyte v. Cockroach analysis: [https://www.cockroachlabs.com/blog/unpacking-
competitive-ben...](https://www.cockroachlabs.com/blog/unpacking-competitive-
benchmarks/)

disclaimer: I work at cockroach

~~~
pm90
Nice. Seems a bit disingenuous on yugabyte to claim they’re better performant
in light of this.

Just want to say that I love your docs. Haven’t used cockroachDB just yet but
the docs are clean, easy to follow, devoid of marketing and focused on facts.

~~~
bithavoc
Second that, the CockroachDB documentation is excellent. All the DDL and DML
statements are clearly documented and with examples, that's really cool.

------
willvarfar
I know this is basically an ad for yugabyte, but it’s a nice summary
nonetheless.

------
vearwhershuh
Does anyone have good experiences with seamless sharding at the database
layer? I'm old school and I'd be strongly inclined to look for a simple cut
that allowed me to shard at the app layer, but I'd love to hear an alternative
view.

~~~
derekperkins
Vitess is awesome if you're using MySQL.

