Facebook 欲用 Apollo 取代 MySQL 数据库

自公司创办以来，Facebook就一直在使用MySQL数据库。大多数人对于让这家社交网络网站得以支持来自20多亿用户的数据，又没有任何障碍地顺畅运行的优化方法感到很好奇。
实际上，人们谈论可扩展数据库时，几乎总是免不了提到Facebook。当然，近些年来，数据库管理和增长这个小众领域没有比Facebook更重大的成功案例了。
Facebook可能仍然使用MySQL数据库作为其核心引擎，不过随着时代的变迁，马克•扎克伯格（MarkZuckerberg）亲自领导的团队正像大多数知名企业组织那样逐渐青睐NoSQL数据库。
偏向NoSQL数据库
早在2014年，Facebook的代表杰夫•约翰逊（Jeff Johnson）在纽约QCon大会上宣布推出Apollo。这是Facebook自家版本的Paxos，类似NoSQL数据库。这个新的NoSQL数据库模型是一种分层存储系统。这种高级数据库中存储的数据以碎片形式存在，就像区域服务器中的HBase。
然而，这种新型NoSQL模型的独特之处在于其在线低延迟存储系统。它不是一种面向文档的数据系统。Apollo更侧重数据结构的修改，让用户可以修改数据结构，没有太多的前序（prologue）。数据的单个分片（shard）很小，大小在1字节和1兆字节之间。但数据的总大小可以达到10+拍字节（PB）。它支持的服务器数量可以从区区3台增加到将近1000台。
了解Apollo
存储在Apollo数据库中的数据以小碎片的形式存在。这每一个碎片有四个不同的部分。
Apollo的第一个部分基于Raft。它是一种直接来源于Raft的法定共识协议（quorum consensus protocol），而Raft是来自斯坦福大学的一种成熟稳定的领导者（leader）协议。这是Apollo数据库系统的独特之处。
Apollo数据库中的第二个部分是数据库里面的存储系统。该存储系统受到了RocksDB的启发。它是一种基于谷歌LevelDB的键/值存储系统。Facebook可以轻松地处理该存储系统，模拟其他数据结构，包括老式MySQL数据库结构。值得注意的是，Apollo对于存储的定制不是很友好。因此，Facebook的数据库管理团队正努力为其新的Apollo数据库存储系统添加MySQL数据库支持的部分功能。
第三个部分是Facebook的原生API。任何数据库API都是一个关键部分。对于Apollo而言，它是拥有read()和write()组件的Client API。用户需要表示他们的前提条件。如果前提条件正确，Apollo将返回值（读取或写入）。
你要记住：该数据库中的所有数据都是碎片形式的。因此，Apollo数据库里面任何分片层面的操作都是原子级别的。你始终可以把许多条件与读取结合起来，创建新的操作前提条件。
第四个部分是容错状态机（FTSM）。这是Apollo数据库中系统代码的一部分。每个分片都有单独的FTSM。不妨这样来考虑：如果有牵涉三台不同机器的分片，它们都将同时执行同样的代码。它在大型数据库环境中有着巨大优势。如果一个代码突然死亡，其他分片将以可接受的适当顺序继续运行同样的代码，并被所有节点所接受。
虽然Apollo成为Facebook新的宠儿掀起了巨大的动静，但到目前为止Facebook没有在生产环境中使用它。相反，该公司期待取代Memcached的一些使用场景。Facebook高度依赖内存缓存存储系统，这已不是什么秘密。坊间传闻称，Apollo成了从Facebook到iOS设备和运营商的出站消息的新型队列系统。它很适合数据分析。此外，它将提升数据提取的速度和准确性。
为何Apollo会存在？
Facebook使用状态机主要用于负载均衡、分片生成及管理、协调跨机器的数据事务以及数据迁移。但是这个过程不够尽善尽美。这些状态机可以向远程服务器发送RPC请求。除此之外，每当用户需要对数据的持续状态进行更改，他们需要经过Raft，并且让其他所有服务器都要同意。
Facebook眼下在使用什么？
Apollo仍在“建设中”，它远远谈不上是Facebook的日常数据库。因此目前，这个社交网络巨头在使用添加了大量修改和附件的MySQL数据库，为每天数量庞大的数据传输和数据存储提供方便。你不能指望一家年收入数十亿美元的公司将MySQL直接拿来使用！它对IO子系统作了一些变动，包括下列新特性：
innodb_read_io_threads，innodb_write_io_threads——这设置了后台IO线程的数量。
innodb_io_capacity——这设置了每台服务器的IO容量，以确定后台IO限制。
innodb_max_merged_io——这一个设置了毗邻IO请求的最大数量。通常，下一批IO请求会在稍后合并成大得多的IO请求。
不像Apollo，Facebook目前依赖MySQL数据库作为键/值存储系统，因而能够在一系列逻辑实例之间随机分布数据。你可以在服务器的物理节点上找到这些。当前服务器的所有负载均衡工作只出现在物理节点层面。
最令人惊讶的传闻称，Facebook拥有大约1800台MySQL服务器，内部却只有三名数据库管理员（DBA）。这似乎是一项不可能完成的任务！即使Facebook果真只有三名DBA来管理整个数据集，要是没有MySQL数据库，那也是永远不可能的。
MySQL简单而强大，Facebook或其他任何类似的社交网络网站多年后才会用新的NoSQL服务器替代全天候运行的MySQL服务器。