5 ms·

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 twe

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.

juliangregorian 12y ago
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. I'd say some shit has been cast.
- midom 12y ago
  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. P.S. I wrote the original post.
  - juliangregorian 12y ago
    > It was conversion from standard MongoDB to RocksDB based MongoDB Well that would have been relevant information to put in the article now wouldn't it?
    - nemothekid 12y ago
      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.
      - juliangregorian 12y ago
        What are you going on about? You can absolutely use RocksDB standalone, as you can Postgres and SQLite.

juliangregorian 12y ago

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. I'd say some shit has been cast.

midom 12y ago
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. P.S. I wrote the original post.
- juliangregorian 12y ago
  > It was conversion from standard MongoDB to RocksDB based MongoDB Well that would have been relevant information to put in the article now wouldn't it?
  - nemothekid 12y ago
    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.
    - juliangregorian 12y ago
      What are you going on about? You can absolutely use RocksDB standalone, as you can Postgres and SQLite.