Facebook中的个人资料不仅仅是姓名、Email、兴趣等属性列表，而是一个非常丰富的社交图谱，包括了亲人/朋友、群组、喜欢、分享等等。刚开始的Facebook社交页面非常简单，采用PHP来构建应用程序，MySql作为长期使用数据库，采用Memcache作为后备缓存支持。PHP应用程序可以直接访问MySql和Memcache，中间没有数据抽象层。
这种简单的数据库架构在访问量很少的情况下优势确实非常明显，但Facebook从开始用户量就飞速增长，最终这种数据架构导致了开发人员敏捷性急剧下降。因为工程师需要使用两种截然不同的数据模型来对数据进行处理，MySql存储主从对集合、Memcache则用于存储和提供派生的平面键值的SQL查询，MySql和Memcache相互协作成为了一个很大的难题，开发者使用数据库前首先要获得关于这两个数据库如何相互协作的复杂知识。
Facebook的数据量暴增也使得MySql的缺点凸显出来，MySql的单体架构很早强制应用程序级的分片，应用程序则需要跟着哪个MySql实例复杂存储哪个用户的配置文件，数据量暴增之后，开发和操作的复杂程度就呈现指数级增长。多数据中心、异地冗余复制也成为了MySql一个非常关键性的问题，主从异步复制转移时，最近的数据无法避免不会丢失。
于是Facebook自开始自研构建小而美的存储系统TAO
TAO可以将facebook现有成百上千的Mysql主从对转化成一个高度可扩展、自动分片、基于地理分布式的数据库集群。TAO可以将分片迁移或者克隆到同一个集群的不同服务器，这样就能平衡负载并消除负载峰值。
如果一次分片更新后、第二次分片更新前出现故障，TAO的异步修复作业就会清除挂起的关联。
使用TAO架构之后本质上还是没有放弃MySQL，因为当时的MySQL和其他数据库都无法单独解决爆炸式数据量的增长。TAO本质上只是创建了一个自定义数据库的查询层，这层抽象了底层分片的MySql数据库。
分布式SQL应运而生
很多人都喜欢SQL普遍性以及灵活性，都不愿意放弃SQL的情况下对它进行扩展。虽然很多企业没有Facebook这样大规模数据增长的问题，也同样希望按照自己的意愿来拓展SQL数据库。
第一波分布式SQL数据库叫做NewSql，包括了Clustrix、NuoDB、Citus、Vitess等等，但这些都不足以从根本上简化开发人员、运营的体验，反而阻碍了开发人员。于是就有了第二波分布式SQL数据库，灵感源于Google的Spanner,数据库层内置了大规模可扩展性和全球数据分布，而不需要像之前Facebook必须内置在应用程序层中。
总结
Facebook、Google等等这样的科技巨头的数据库扩展的历程，都是值得很多人学习和借鉴的。TAO保留了MySql的现有投资，但应用工程师失去了使用SQL的能力。Google则创建了Spanner，走了一条不同的道路创建了一个全新的SQL数据库。
以上个人浅见，欢迎批评指正。
认同偶的看法，请点个赞再走，感谢！喜欢偶的，请关注偶，再次感谢！
