Life of a Vitess Cluster | Hacker News Reader

Life of a Vitess Cluster

vitess.io

44 pointsgesaint8 comments

Life of a vitess cluster is a weird title for this, would expect something more like “how to bootstrap a vitess cluster”.

"Life of a query" is a class that every Google engineer attends during orientation. It goes through all the frontends and backends involved in serving a search request. Many more presentations with similar titles have been created since, about all sorts of projects and systems, so this one follows that tradition.

Eh, if it was called life of a vitess query. And it talked about the grpc client, the vtgates, the routing in the vtgates, the vttablet and finally the MySQL database. That would make sense.

But for it to be titled life of a vitess cluster and talk only about setting up a vitess cluster. I don’t really think it follows. For instance, I might expect how reparents happen to be included as well. Or what it takes to reshard a key space, etc.

Suddenly Google Cloud Spanner doesn’t look overly expensive.

Click saver for people who don't know what this is: a MySQL clustering thingamabob, according to their front page.

Call me old fashioned but I’m not a fan of any of these patchset distros to make RDBMS scale-out. There are just too many things to worry about. I’d much prefer to use something like Cassandra which comes with proper sharding support out of the box and the ability to tune consistency.

When I first heard of Vitess I thought it was gonna solve a bunch of issues for our team.

But then as I started taking a closer look at it, I realized it was more likely to introduce a host of new, hidden issues, than really solve any of our problems, or make things simpler. For example, it doesn't magically give your cross-shard transactions. And there are situations where it can cause straight up deadlocks, if you're not careful about how you structure your queries.

So basically your devs can see the DB as "one gigantic instance"... but they also have to be (painfully) aware of what Vitess is doing under the covers to avoid poor interactions with it.

Doesn't sound like a win to me.

My team manages a large scale vitess setup. Nothing is free. Vitess is a much better way of sharding mysql than sharding in app. It is not a silver bullet. No matter how you slice it, sharding a database exposes you to everything you described. For most of our devs, they don't actually have to care all that much about what the DB looks like under the hood. The biggest issue is scatter queries, for which we built a detector so you can find out before your code hits prod.

Cross shard queries are evil.

I count myself lucky that I didn't have to live through the migration and first shard splits, it sounds harrowing. We have a shard split coming up this year, but it's gotten way better now that we have our scale under control.

Vitess is a good solution to 'oh shit we use mysql and our app succeeded beyond our wildest dreams and we now have to migrate without or with minimal downtime ASAP, and can't afford the time to rework everything to use cassandra'. It is not something you should really be thinking about when choosing what storage backend to use for your brand new app. We strongly advise teams to choose other technologies where possible. It's not that it doesn't work, or is bad. It's actually really good at what it does. It's rock solid, and scales really well. It's the tradeoffs that make us not want to use it.

Reply on news.ycombinator.com