They say that they brought some new search features to mobile, though I would prefer if they fixed their search on desktop (or in general) first, as it only returns results from recent messages. Until sometime in 2016/2017 it was possible to look for specific things at whatever time (e.g. 2011) and now even things from <3y ago don't return anything.
Migrating Messenger storage to optimize performance
31–35 of 35 posts
Re: Migrating Messenger storage to optimize performance
#32During the dual-write phase, what happens if one request succeeds while the other doesn't?
Re: Migrating Messenger storage to optimize performance
#33During the dual-write phase, what happens if one request succeeds while the other doesn't?
Iris retries the failed request
Re: Migrating Messenger storage to optimize performance
#34TL;DR - Moved from HBase to MyRocks engine on MySQL sitting on top of NVMe storage via their Lightning Server [1], which is a JBOF (just a bunch of flash) setup using x16 PCIe. [1] https://code.facebook.com/posts/989638804458007/introducing-...
Anyone know why Facebook moved off HBase? (article doesn't address this) I get that MyRocks is truly amazing, but I'm wondering what issues they were facing with HBase. I heard HBase was picked over Cassandra (developed at FB) because it was strongly consistent vs Cassandra's eventual consistency.
I also heard they had an issue with network flaps causing unrepairable inconsistency. I never got the full scoop on this.
I had worked with the engineers directly responsible for the HBase choice back when. All water under the bridge now it seems.
Re: Migrating Messenger storage to optimize performance
#35Facebook has been using RocksDB more and more (now messenger, but also Instragram’s flavor of Cassandra). I wonder if Google has a similar penetration of LevelDB (and we just don’t hear about it because Google’s infrastructure work isn’t open source)
As far as I understand, Google doesn't have a bunch of tools that merely work together, they have one huge system with different bits that _live_ together, so much that separating and open-sourcing them is cool but won't give you the same thing as being from inside:
- They use Blaze, a build system that integrates directly with the object store. They open-sourced Bazel as a kind of equivalent, but the build system won't shine unless you have an integrated object store and an integrated vcs client - They have open-sourced Kubernetes, a successor of what they were using for they were using internally for cloud management - They have open-sourced LevelDB, a successor of the fundamental brick they are using for BigTable
So in a way LevelDB isn't used as-is inside Google, but its spirit is in use at a fundamental level by pretty much everyone