derekperkins

13 ms·

91.
by derekperkins 5y ago
Architected correctly, there's minimal need for cross-shard foreign keys. A common use case is sharding by tenant/customer id, which means that all records for a single customer live on a single shard. That lets you have all the F
92.
by derekperkins 5y ago
Vitess still supports foreign keys (single shard), using MySQL, just not with the Online DDL functionality. I think Cockroach tries to be a little too magical, which is great for starting up a cluster, but I think you can architect for much
93.
by derekperkins 5y ago
I do use it in production and have for years, just not the online schema changes. It's fantastic and FKs are supported in a single shard, which we use heavily.
94.
by derekperkins 5y ago
I'm a Vitess maintainer and I feel the same way. I don't plan to use any of the Online DDL because you'll have to pry my foreign keys out of my cold, dead hands. I understand the reasoning and limitations, but like you, the t
95.
by derekperkins 5y ago
That's my favorite part about using messaging in Vitess. I can emit events in a real transaction. It eliminates an entire class of bugs. https://vitess.io/docs/reference/features/messaging/
96.
by derekperkins 5y ago
Solving both these problems is the best hidden feature of Vitess - Messaging. You can ack a message, do data work, and add to a destination queue all in a single transaction. You can do selective requeuing, and infinite parallelization, sin
97.
by derekperkins 5y ago
I believe most of those are self-hosted Vitess with Planetscale providing technical resources and support.
98.
by derekperkins 5y ago
In practice this doesn't turn out to be a major issue, since a good design will keep >99% of queries/transactions on a single shard. 4 years of Vitess in prod, also a maintainer
99.
by derekperkins 5y ago
That's pretty close to how Vitess handles sequences (distributed auto-increment)
100.
by derekperkins 5y ago
Insane overhead in what way?
101.
by derekperkins 5y ago
It's even more hypocritical than just cherry picking studies. Points in his books are refuted by the same studies he cites! He ignores similar / better outcomes that don't match his bias.
102.
by derekperkins 5y ago
We tried the same thing a few years ago in MySQL that was randomly non-performant: 4000x slower. Still waiting for that to be fixed.
103.
by derekperkins 5y ago
They'll also help you host Vitess, not sure if it's fully managed or not, but that'd get it in your cluster / region.
104.
by derekperkins 5y ago
Have you seen any of those since 5.7?
105.
by derekperkins 5y ago
Still do
106.
by derekperkins 5y ago
Yeah, Google policy was to migrate everything to Spanner, not a technical decision. > Are cross-server transactions scalable? Would anyone architect a system that did them en masse unless they absolutely 100% had to? As a long time Vites
107.
by derekperkins 5y ago
Vitess does just that, letting you seamlessly scale writes in the same way you would scale reads today, scaling linearly with additional nodes.
108.
by derekperkins 6y ago
Most of these are Postgres specific, though MySQL is going to have its own list of issues.
109.
by derekperkins 6y ago
That's why Vitess is so awesome - you can scale writes infinitely. There's not a truly comparable option for Postgres
110.
by derekperkins 6y ago
We just use the git sha and they works great, no reason to overcomplicate it
111.
by derekperkins 6y ago
I think the vast majority of devs work in a single language, at least on a day to day basis.
112.
by derekperkins 6y ago
That was added a couple years ago in MySQL 8, as were window functions and arbitrary checks. The two databases continue to fill in the gaps that were historically reasons to choose one over the other.
113.
by derekperkins 6y ago
Those can both be simultaneously true. Employers can be supportive while still trying to regain lost productivity.
114.
by derekperkins 6y ago
5TB is not that large and it's not that difficult to get good performance. We operated a 50TB single instance of MySQL for 5 years with a tiny team before migrating to Vitess, and it was basically zero maintenance. We did partition our
115.
by derekperkins 6y ago
There is definitely a magical feeling to spinning up Cockroach on a single binary and just letting it do things for you, vs the much steeper learning curve of Vitess. If you aren't looking for peak performance and are optimizing for ra
116.
by derekperkins 6y ago
It's not that it can't be, but it is a completely different codebase from Spanner without the luxury of TrueTime and complete control over datacenters that it runs in. Cockroach simply hasn't been pushed to the same levels of
117.
by derekperkins 6y ago
Since I'm not a Cockroach expert, I'm sure that there are ways to configure it that eliminate some of those latency issues that were common early on. Both Vitess & Cockroach can replicate across regions and survive regional fa
118.
by derekperkins 6y ago
I don't really understand the continuing appeal for CockroachDB. Yes there is some cool tech, but given that all transactions are synchronously distributed, there's a hard cap on how fast it can be. I have yet to see any significa
119.
Cockroach Labs scores $160M Series E on $2B valuation(techcrunch.com)
5 points by derekperkins 6y ago|8 comments
120.
by derekperkins 6y ago
Whatever the service, it isn't the platform that Slack is. I would guess that a huge percentage of their db traffic is from apps and custom integrations.

More ›