4 ms·
> only This is nearly all the data stored by Facebook. Every profile post, comment, photo, story, marketplace listing is a row in one MySQL table. Even interna
by nindalf 4y ago
> only
This is nearly all the data stored by Facebook. Every profile post, comment, photo, story, marketplace listing is a row in one MySQL table. Even internal tasks and code changes are rows stored in this one table. I don’t think a bigger MySQL table exists.
Fun fact - You can also access any object if you know it’s ID with Facebook.com/id. For example, Mark Zuckerberg’s profile was the 4th object created, so that’s where https://facebook.com/4 https://facebook.com/4 leads.
- ericbarrett 4y agoThis is right. Source: worked on the FB MySQL team, though it was a long time ago. There is also massive, massive associated caching infra (memcached, Tao). There isn't as much hoopla about it but there are some public blog posts. I think it's even more interesting than the backing store. The UDB tier used to use the InnoDB engine; nowadays it's MyRocks: https://research.facebook.com/publications/myrocks-lsm-tree-database-storage-engine-serving-facebooks-social-graph/ https://research.facebook.com/publications/myrocks-lsm-tree-...
- tpankaj 4y agoThere are a couple of blog posts and associated papers on TAO: https://engineering.fb.com/2013/06/25/core-data/tao-the-power-of-the-graph/ https://engineering.fb.com/2013/06/25/core-data/tao-the-powe... https://research.facebook.com/publications/flighttracker-consistency-across-read-optimized-online-stores-at-facebook/ https://research.facebook.com/publications/flighttracker-con... https://engineering.fb.com/2021/08/18/core-data/ramp-tao/ https://engineering.fb.com/2021/08/18/core-data/ramp-tao/ https://engineering.fb.com/2022/09/07/open-source/taobench/ https://engineering.fb.com/2022/09/07/open-source/taobench/ I work on TAO consistency at FB and we've put out a bunch more articles/papers in the past couple years. Until 2 years ago, there was just the 2013 paper on TAO itself.
- evanelias 4y agoMy memory is fading years after leaving FB, but I don't believe "one table" is correct at all. As far as I can recall, UDB's design permits (but does not require) each object type to have its own table; ditto for association types. I believe different object tables have the same structure / flexible serialization strategy, but the important ones are each distinct tables within a shard.