Facebook 欲用 Apollo 取代 MySQL 数据库

《Facebook 欲用 Apollo 取代 MySQL 数据库》要点:
本文介绍了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服务器.

欢迎参与《Facebook 欲用 Apollo 取代 MySQL 数据库》讨论,分享您的想法,编程之家PHP学院为您提供专业教程。

相关文章

在正式开始之前,我们先来看下 MySQL 服务器的配置和版本号信...
> [合辑地址:MySQL全面瓦解](https://www.cnblogs.c...
物理服务机的CPU、内存、存储设备、连接数等资源有限,某个时...
1 回顾 上一节我们详细讲解了如何对数据库进行分区操作,包括...
navicat查看某个表的所有字段的详细信息 navicat设计表只能一...
文章浏览阅读4.3k次。转载请把头部出处链接和尾部二维码一起...