JDBC is not a protocol, JDBC is an API, hence the need for a different JDBC driver per RDBMS. I doubt the author is a developer, I see this misunderstanding often with architects who don’t code.
And no dup tag, flags?
> stateless services hosted in Kubernetes®
> using the JDBC™ protocol
> Percona™
> Cadence™
> Docker®
> Oracle InnoDB® engine within the mysqld process. We can configure this to use other MySQL engines like Meta RocksDB™.
Trademarks that obnoxious are off putting. The audience must not be engineers.
puts aluminum foil hat back on
Uber offshored some parts of their engineering so all the new-ish blogs fit the stereotypes. Lazy written, LLM generated, by their offshore indian folks.
Make of that what you want.
(Especially hilarious given it's Uber, which obviously could never have engineers doing anything morally dubious ever /s)
I don’t see that implication in the original post.
I was hoping to find some reason for Uber to use MySQL over the other popular FLOSS RDBMS (i.e.: Postgres).
For Facebook I more/less know what are their reasons. I was hoping to learn about Uber's reasons, but the article was was not going that deep.
Largely truth, some small mistakes. Generally friends don't let friends use Mysql but at scale all the hacks and workarounds actually work.
What drives this sentiment?
People say 'Facebook uses Mysql', but if a page fails, you just refresh. Most of the time the page is different so if everything is broken in the back end no one cares. Same with ad tracking (I have written code to check impressions via second sources).
If I refresh my bank balance I want to see the same. That's why they use Posgtges (yes the bank I worked on), or some commercial thing like SQLServer or Oracle, where integritry is more highly important.
You seem to be under the impression that MySQL just "fails" on random read queries? That is nonsense.
In reality Facebook's db fleet is a massive sharded system, and sometimes shards are temporarily offline due to hardware failure on the shard's primary/writer node, but it's quite brief in the vast majority of cases. When you have such a massive number of servers, hardware failures happen many times a day.
Due to caching and other services it's also a multi-leveled data access stack, so a page load could fail due to some non-MySQL component having problems as well. Or a network issue, etc. It's not magically MySQL's fault every time something goes wrong at Facebook.
Meta uses MySQL for a variety of mission-critical use-cases, including financial ones. Every single committed MySQL write is replicated before success is returned to the calling code, nothing is lost or thrown away.
> Things that are missing in most other proper databases, like transactional DDL [...]
> some commercial thing like SQLServer or Oracle, where integritry is more highly important.
And yet Oracle DBMS does not have transactional DDL either, so why aren't you equally critical of it here?
In modern MySQL, DDL is atomic and crash-safe on a per-statement basis. It's just not "transactional", in the sense that you can't combine multiple DDL statements (nor mix DDL and DML) into a single transaction.
See https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html for reference.
Modern versions of MariaDB also have atomic DDL, although their underlying implementation is quite different.
And even in older versions of MySQL and MariaDB, an ALTER TABLE which causes an integrity violation was still rolled back. Think about it: the only possible non-instantaneous integrity violations are when adding a new unique key, new foreign key, or new check constraint. Check constraints didn't exist in old versions of MySQL or MariaDB, so that just leaves unique keys and foreign keys. And there's no notion of a "partially populated" index or a "half applied" foreign key constraint in MySQL, so your assertion of the ALTER just "stopping" mid-stream without rollback is just plain wrong.
A quick search hints me that there is still more ultra-large MySQL setups than there are PostgreSQL. By a large margin it seems.
Between easier upgrades/HA, thread connection model, Vitess and engines like MyRocks, it's hard to beat for many use cases.
MySQL is fine, boring tech that powers a great many companies. There's nothing wrong with choosing it for a new venture, but there's also nothing wrong with another choice. Which RDBMS you use won't be the deciding factor in your success these days.
It's waaaay more quirky in our experience.
Also: Oracle hate is not unwarranted, even in this day-and-age.
> There's nothing wrong with choosing it for a new venture
I'd advise anyone in that position not to choose MySQL. Go with Postgres unless you have a good reason not to.
I find myself having to STRAIGHT_JOIN more often than I would like because it simply won’t generate sensible execution plans sometimes.
* sub-query needs to be wrapped in a sub-query
* we had an issue recently (dont have the link at hand) where mysql team closed the bug as fixed but only documented it as a "know issue". we had to split up one query in 5 queries to fix this
* ask Lucas Eder what is a better db, he has intimate experience with all of 'm
Here are some we also run into:
https://www.codementor.io/@goetas/why-i-prefer-postgresql-to...
The fun thing is MySQL will also require schema migration tooling, but since their native migrations are so bad the tooling around it has evolved to be much better. Things like pt-osc and gh-ost will kick the butt of anything Postgres has, let alone when you pull out the big boy tools with Vitess.
Don't get me wrong, most databases will never need such tooling whether they're Postgres or MySQL. But still I find it interesting that (for the migration story at least) at small scale they're equal, then at medium scale Postgres wins out and at larger scales MySQL starts to win again.
Nice insight!
I'd say because most apps wont reach mega scale, that on the small scale Postgres should win. Also having to deal with less quirks is really nice on small scale too!
Unless you need the kind of sophisticated extensions Postgres supports MySQL is likely to be a good fit. The query planner is straightforward, performance tuning slightly more predictable and easy compared to Postgres.
What are you referring to here?
When people talk about bad defaults in old MySQL, they're typically referring to lack of strict sql_mode by default prior to MySQL 5.7 (2015). They're not talking about OS users.
I've been using MySQL for 22 years and your comment about sudo bears no resemblance to anything I've ever experienced.
Collations and charsets and the DB engine and other stuff wasn't particularly good either, but I can't be arsed to figure out specifically when so I glossed over the details. I don't think it matters. 8 is what, a decade old or so?
That require you to what? Nothing in MySQL inherently requires sudo or involves "hooking into sudo".
The mysql server daemon (mysqld) typically runs as mysql:mysql, with directories owned by mysql:mysql in the Unix permission model, but this is all entirely dependent on how you have installed it.
Inside the database server, you can freely configure database users, which are entirely separate from the notion of OS users. Although the default superuser in MySQL is typically called "root", it can be called anything, and is not tied to the OS root user.
Connecting to MySQL can be done either via tcp/ip or locally through a Unix domain socket; this is all completely configurable on a per-database-user level inside the database itself.
When connecting over the local Unix domain socket, connections are permitted if the requested user name has a database user entry with @localhost for the host portion.
I suppose your OS user is relevant in two ways when using the local Unix domain socket:
* You need OS permissions to interact with the socket. That's the case with any Unix domain socket, not MySQL specific.
* If you're using the standard `mysql` command-line client and you haven't supplied a database user name for the connection, your OS user name will be used as a default.
So perhaps you were running `sudo mysql ...` to connect to the local mysqld because your OS user lacked the :mysql group to interact with the socket; or because your OS user did not have a corresponding database user/grants inside the database. In the latter case, you can just type `mysql -u root ...` instead to specify what database user to connect as. There's literally nothing requiring sudo in that case.
That said, you can optionally make this passwordless using the auth_socket auth plugin, in which case there are extra considerations around having the users match and maybe that's what happened to you. But there's no requirement to use that passwordless auth_socket approach for administration.
> Collations and charsets and the DB engine and other stuff wasn't particularly good either,
That's quite vague and it sounds like you aren't well-informed about MySQL in general so I suppose there's little sense in diving into it.
> I don't think it matters. 8 is what, a decade old or so?
MySQL 8.0 came out less than seven years ago, but that's irrelevant since everything I described above regarding permissions is equally true in MySQL 8.0.
What's your experience with Postgres?
To re-summarize, MySQL administration involves use of a mysql user (meaning, a user defined inside the database server and NOT an OS user), and since there is no 1:1 mapping between OS and db users in MySQL there is quite obviously no requirement to use sudo or su for anything at all.
Postgres is not relevant to that claim, as we’re discussing MySQL behavior here.
Furthermore none of this behavior is specific to MySQL 5 (it hasn't changed in 8.0, nor anything after it like 8.4 or 9.0) and none of it relates to defaults.
It's entirely possible some default changed in the package for your chosen Linux distribution / package management system, but that is outside of MySQL itself.
When you administrate Postgres you typically run psql as another user, with MySQL you typically don't, instead you tend to use the root@localhost in the database or sudo on the rather large set of binaries that gets installed with the server.
And I don't really care whether you think the old MyISAM engine was fine and not problematic or whether you've come across problems with utf8mb3 or latin1 or whatever, and I especially don't care whether you think I'm an experienced, professional MySQL user or not.
I have no idea why you keep replying with non sequiturs, but I’m going to stop responding now, as you don’t seem to understand anything I am saying.
PHP is also something I'd not advise anyone to use on a greenfield app unless you have really good reasons for doing so.
There are much better --also very conservative-- stacks available for free (and no, those are not JS based).
For instance: Kotlin, http4k, JTE/KTE (or kotlinx.html), SQLDelight, Postgress.
Big shops with big legacy PHP code bases all move away from it.
LAMP = Linux (sure), Apache (no-way, use NGINX or in app web server instead), MySQL (sorry, Postgres won) and PHP/Perl (these langs are going the way of the Dodo).
So LAMP is a bad choice nowadays. I'd say it has been since Ruby on Rails 1.0.
https://github.com/WalkerCodeRanger/ExhaustiveMatching
I prefer languages that have been designed with this in mind. Kotlin in this case goes a long way.
Golang is shit IHMO. No null-safety. No sum types. I dont know what Rob Pike was thinking when he designed this. Total disregard for the last 40 years of innovation in software engineering. Sad.
Solutions like this also exist for PG, any insight into why vitess is better?
I'm not sure I would call it even close to battle hardened.
They are still many lurking footguns and bugs.
Try running it with > 250k tables. Falls down hard.
Error logic around etcd/topo server is very shaky, edge cases can wedge cells/clusters into broken state.
https://www.percona.com/blog/orchestrator-for-managing-mysql...
Please do some additional research into the state of maintenance of that piece of tech before jumping on it. But it certainly did a lot of powerful things for us back in the day. The automatic promotion of followers was key to our deployment.
Well kinda. Galera looks like it's an amazing solution, and it can be for careful operators who read the docs, learn the new procedures and ensure that they're running workloads that fit well. It can eliminate the usual HA / replication / failover stuff. But it has the ability to act like a foot-machinegun.
Outside kubernetes where you don't have an kubernetes operator that can run the database cluster, spin up nodes and pods, manage volumes etc it's difficult to imagine how you might automate that infrastructure in addition to managing the database cluster, without building a lot of it yourself.
Make sure you up ulimit and systemd LimitNOFILE in the MySQL service config. Read docs closely, preferably bring on someone who's spent some time making mistakes in this area to help out, test diligently before putting into production, including load tests.
This is written like unintentional comedy! I'm glad their nodes are so... numerous.
Please enjoy each one equally.