evanelias

73 ms·

1051.
by evanelias 7y ago
I agree that most companies won't ever need to shard, and pre-sharding (or worrying about extreme scalability challenges in general) is usually unwise premature optimization. But it does depend on the product category. Social networkin
1052.
by evanelias 7y ago
And to clarify, I'm not saying that to toot my own horn. My point was, I primarily work on open source schema management and related consulting. I talk to large companies about MySQL schema changes literally every single day. The comme
1053.
by evanelias 7y ago
Cool, so I'm going to assume that means your answer to my question of "Do you have much direct experience with high-volume OLTP database workloads?" is "no". Given your "bet" as well as comments about sche
1054.
by evanelias 7y ago
So are you asserting that the following products are all built on top of a "toy" database, and their engineers have no idea what they're doing: Facebook, YouTube, Wikipedia, Pinterest, Slack, GitHub, Etsy, Yelp, LinkedIn, Sho
1055.
by evanelias 7y ago
The performance impact is at write time, and having the data cached in memory is irrelevant. It's the locking overhead that's non-trivial, especially if each table has several FKs, when operating in a high-volume OLTP environment.
1056.
by evanelias 7y ago
> I’m pretty confident that GitHub doesn’t use foreign keys because it was built as a Rails app Maybe originally, but lack of foreign key usage is certainly not Rails specific today. Large MySQL shops generally don't use foreign key
1057.
by evanelias 7y ago
InnoDB's foreign key support predates the existence of Rails by several years. However, InnoDB wasn't the default storage engine for MySQL at the time, so that may be a factor.
1058.
by evanelias 7y ago
Adding a foreign key to a massive table can take a long time, since all existing row data must be validated against the constraint. With logical replication, long operations like this can be quite disruptive, even with a multi-threaded logi
1059.
by evanelias 7y ago
MySQL 8 DDL is atomic at the statement level, but cannot be combined with other SQL DDL or DML statements in transactions yet.
1060.
by evanelias 7y ago
WeWork is headquartered in New York, where non-competes are enforceable (albeit with limitations, but still, it's not like in CA...)
1061.
by evanelias 7y ago
It's legal and it's a model being increasingly adopted in the US, for better or worse. In the NYC metro area, both Port Authority and NJ Transit are visibly leaning on this model to drive revenue.
1062.
by evanelias 7y ago
> crap SQL that MySQL taught you This seems like an unfair characterization. You're blaming MySQL for "teaching you" nonstandard practices just because it allowed you to use them, but where did you actually learn these
1063.
by evanelias 7y ago
MySQL's defaults have been massively improved in the past two major releases. Can you please cite any major examples of modern-day "bugs and footguns" configuration in MySQL 8 related to bad defaults or backwards compat?
1064.
by evanelias 7y ago
Doesn't seem dubious to me. I would expect it to be removed (or at least have the utf8 alias changed to point to utf8mb4) in the next major release. utf8mb3 was deprecated in the most recent release series (MySQL 8). For feature deprec
1065.
by evanelias 7y ago
I'm the author of an open-source schema management tool, Skeema [1], which uses a declarative infrastructure-as-code approach: you track your table definitions (and procs, funcs, etc) in a Git repo of *.sql files, typically one CREATE
1066.
by evanelias 7y ago
Thanks! Great questions -- unfortunately the short answer to both currently is "not supported yet" :) But there's reasoning behind it being on the back-burner in both cases; in some older threads I've discussed the lack
1067.
by evanelias 7y ago
While I agree with the overall negative opinion of overzealous stored procedure usage, to echo your last sentence, I've come to realize many of these problems are completely solvable with tooling. A personal anecdote, and please excuse
1068.
by evanelias 7y ago
Apologies if I'm misunderstanding. To take a step back and paraphrase this subthread, as I understand it: * `dezzeus said MySQL was better for read-intensive workloads, Postgres better for mixed read/write * I replied saying there
1069.
by evanelias 7y ago
You're severely underestimating the amount of effort that went into MyRocks. The development and deployment was a 3+ year effort spanning quite a few different teams. Automating the physical rollout (as you correctly described) is th
1070.
by evanelias 7y ago
> I dealt a lot with large scale large data sets and I wouldn't recommend mysql for that at all Was your use-case transaction processing (OLTP) or analytics (OLAP)? There are a ton of examples of massive-scale MySQL deployments for
1071.
by evanelias 7y ago
MySQL has supported left/right outer joins for as long as I can remember, and I've been using it continuously since 2003. MySQL doesn't support full outer join , but it's rarely needed, and you can often get a similar r
1072.
by evanelias 7y ago
It's still MySQL/InnoDB under the hood. I don't follow your point -- why does it matter whether an application is talking directly to MySQL, vs using an intermediate service with a non-SQL API? If the intermediate service sup
1073.
by evanelias 7y ago
To echo a few other commenters here, a major point of consideration is your team's experience and broader technical network. Generally speaking, either Postgres or MySQL is likely fine for most applications. But you'll have a bett
1074.
by evanelias 7y ago
That is simply not correct. Please understand that I worked on MySQL at Facebook, so I know what I'm talking about here :) Facebook developed an entirely new MySQL storage engine (MyRocks, which is a RocksDB-backed engine for MySQL) an
1075.
by evanelias 7y ago
MySQL partitioning shines with one specific use-case: time-based data retention. e.g., by using RANGE partitioning over a temporal value, you can very efficiently drop large amounts of old data when no longer needed, and can automate this f
1076.
by evanelias 7y ago
> Several years ago, a knowledgable guy told me that the most compelling reason for choosing between PostgreSQL and MySQL was the expected I/O: "for read-intensive workloads (e.g. blogs), choose MySQL; for mixed workloads (e.g.
1077.
by evanelias 7y ago
Based on what I have read, "kv store" is a major over-simplification. A number of companies have built special-case storage services/APIs on top of MySQL. This is not the same thing as writing your own database. In any case,
1078.
by evanelias 7y ago
MyISAM is considered deprecated at this point. It isn't crash-safe and basically should not be used at all, let alone for a new project. InnoDB has supported fulltext indexes since 5.6 (GA release back in feb 2013). However, to be fair
1079.
by evanelias 7y ago
Fair, but why comment on MySQL's supposed deficiencies if your knowledge of it is so out-of-date?
1080.
by evanelias 7y ago
The L train is pretty hosed on nights and weekends until summer 2020. Yes, the countdown clocks specifically on the L are often wrong on nights/weekends during this project. It's not surprising. Do you have an example on a line th

More ›