3 ms·

Facebook is backed by MySQL https://engineering.fb.com/2021/07/22/data-infrastructure/mysql/ https://engineering.fb.com/2021/07/22/data-infrastructure/my... (t

Facebook is backed by MySQL https://engineering.fb.com/2021/07/22/data-infrastructure/mysql/ https://engineering.fb.com/2021/07/22/data-infrastructure/my... (though it's only used as the backing data store for their graph database https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf https://www.usenix.org/system/files/conference/atc13/atc13-b...)

evanelias 4y ago
To clarify, since you worded this a bit ambiguously: MySQL is the backing store for the graph database, which is the primary Facebook product database tier. But separate from that, MySQL is also used for a ton of other purposes at Facebook. Or at least it was as of a few years ago; AFAIK this is still the case. For example the internal MySQL DBaaS tier had hundreds of distinct use-cases throughout the company.
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 ago
  This 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 ago
    There 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 ago
  My 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.

evanelias 4y ago

To clarify, since you worded this a bit ambiguously: MySQL is the backing store for the graph database, which is the primary Facebook product database tier. But separate from that, MySQL is also used for a ton of other purposes at Facebook. Or at least it was as of a few years ago; AFAIK this is still the case. For example the internal MySQL DBaaS tier had hundreds of distinct use-cases throughout the company.

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 ago
This 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 ago
  There 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 ago
My 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.