the secondary indexes are saved in a different table and (I can only assume) the application layer (or one layer above mySql) is responsible for keeping that table up to date.
If you use only 1 table, then it's by no means "relational", so I don't see why you'll need a database system designed from start to finish to support a relational model.
> If you use only 1 table, then it's by no means "relational" [...]
FYI The term "relational" in "relational database" does not refer to the relation between tables but to the mathematical concept of a relation which is some set of tuples ie a single table.
Well, the relational model does not describe or contain a notion of table really, so I guess you could model it in any way you want, even within a single table.
But I think that's a mute point, I doubt they kept any part of the relational model inside their schemaless database.
The "relationalness" is/was not really important here. It's all about MVCC and how storage engines handle it.
Postgres is lacking in these scenarios, whereas a particular fine tuned version (or fork) of InnoDB (or MyRocks or whatever they end up chosing) handles this better.
See Facebook's "mysql-5.6" branch, that has hundreds of patches piled on to support especially these taxing workloads.
Well, for that matter, as I understood it, they also have no transactions nor atomicity and are basically eventually consistant , though these I'm simply inferring from their posts, it was not stated as far as I can remember.
So MVCC also has almost zero bearing on what they are doing.
Just because you may not always use the database with the BEGIN/COMMIT semantics, that absolutely does not mean that "MVCC has almost no bearing on what they are doing".
MVCC and how it has been implemented in the two storage engines in discussion here absolutely has a lot to do with it.
