I don't understand the nuances and fighting over what database is better.
So the key takeaway for me is the reminder that persistent storage is generally no longer spinning rust. Programs and operating systems should evolve to take advantage of the different strengths and weaknesses of flash based storage.
Seems like for whatever reason RocksDB has decided to shit all over MySQL and Mongo lately, which is an interesting strategy because they are both capable of using RocksDB storage engines.
Facebook makes RocksDB. The MySQL forked you linked is maintained by Facebook. The blog post is from a Facebook engineer who works on MySQL at Facebook. The tweet linked in the blog post is from a Parse engineer talking about using MongoDB with a RocksDB storage backend. Parse is a Facebook product.
I don't see how any of that is attacking MySQL or MongoDB, just their stock storage engines.
Yes, should say Facebook makes RocksDB. So Facebook engineer points out how shit InnoDB has become and how RocksDB is gonna eat its lunch. Facebook/Parse engineer is called in to hoot about space utilisation, which is suspect as no info given as to how much data was duplicated on the Mongo replica set, but safe to assume it was at least 3 times. Which means RocksDB was 2.6x more space-efficient. Okay, but if the Mongo replica set had 5 members RocksDB is only 1.5x more space-efficient. Mongo doesn't really optimize for space efficiency, because updates are ideally done in place and documents are normally padded to make that easier. On the other hand RocksDB is aggressively optimizing for space usage, as well as this particular case being a fresh import (no fragmentation). So it really doesn't make a whole lot of sense to crow about it, especially since it comes with a loss of redundancy.
It was conversion from standard MongoDB to RocksDB based MongoDB, so replica count calculations don't really apply.
And yes, Mongo did not optimize for space efficiency, which is why there're efforts to optimize for space efficiency.
Just like there were efforts to optimize InnoDB for space efficiency, that stalled and got derailed by these hole punching ideas.
InnoDB did not become shit, it just stalled and did not progress in an area where lots of innovation is happening elsewhere (and there were possible avenues for optimization), so it may become less relevant.
As the post [title] said, InnoDB lost its advantage.
Its probably caused by a misunderstanding. RocksDB is just a "library" - not really a database in the sense that you can connect to it and query it.
So to someone well understood in the space going from RocksDB to MongoDB without mentioning any sort of front end is meaningless. It would be like going from Postgres to Sqlite.
There's not supposed to be one. It makes no sense to say "How InnoDB lost it is advantage" so it's not supposed to have an apostrophe. It took me decades to internalize that rule, and even now, I accidentally do the wrong thing.
So the key takeaway for me is the reminder that persistent storage is generally no longer spinning rust. Programs and operating systems should evolve to take advantage of the different strengths and weaknesses of flash based storage.