Tag Archives: Facebook

Facebook 针对 MySQL 开源 Online Schema Change 代码

有过 MySQL 使用经验的人应该知道，MySQL 要想在线修改个 Schema 结构是个麻烦事，规模不大的表增加个索引造成的锁也可能导致整个 Web 应用宕机。这一点没办法和 Oracle RDBMS 、DB2 等商业数据库相比，甚至 PostgreSQL 也具备联机 ~~DML~~ DDL 的能力。我在过去写过一系列并不成熟的《MySQL 大企业级应用可行性分析》文章中，也很是担忧这个问题。有些公司想迁移到 MySQL ，也因此而只能采取保守的做法。

不过现在这个缺陷临近被彻底修复。Facebook 的数据库技术团队将 Online Schema Change （OSC) 的代码开源，并且撰文进行了详尽的阐述。这是个很大的技术革新，Facebook 数千台 MySQL 服务器在过去增加个索引需要几个月的滚动升级，现在只需要几天即可。

MySQL 5.1 的 InnoDB 引擎具备 Fast Index Creation 的功能，在创建索引的时候无需复制整个表的内容，但是对于一定规模的大表增加索引，仍然需要花费大量时间，对于在线应用来说，仍然不可忍受。而 Facebook 的 OSC 则进一步进行了改进。对于 MySQL DBA 来说，这是个福音。感谢 Facebook 的员工 Vamsi Ponnekanti 的工作。如果要我说，年度 MySQL DBA 应该授予给他。当然，Online Schema Change 的部分代码从 Shlomi Noach 的 Openark Kit 中派生，建议 Shlomi Noach 一同获奖…

对于 MySQL 来说，我认为这是个里程碑式的时刻，无论 Oracle 将给与 MySQL 多大的投入，其它公司已经主动拿过接力棒。Facebook 技术团队再次立功了！

–EOF–

Update: Facebook 工程师在帖子里说了”Note that the above operations can be done within the storage engine itself, or using an external (PHP) script.” 要知道，这并非只是一个 PHP 脚本的实现。我建议技术人员看帖子应该更仔细一些。也不要说这东西你早都想到了之类的技术阿Q的话，我倒现在为止没听到国内一个公司的技术人员做出来这东西。从想法到实现，其实还有十万八千零一公里呢。

MySQL Sunday 见闻

Oracle Open World 第一天一般是注册日加上 Keynote，但这次下午安排了 MySQL Sunday 的活动，这倒是 Open World 上第一次出现 MySQL 的活动，去年可能正在忙于和 Sun 整合，来不及安排吧。之前，搜索了一下议程，有两场 Facebook 的工程师的 Session，早早赶到会场，听完虽然感觉料不够多，但也很过瘾。

Facebook 进行分享的两位工程师分享的议题一个为 Advanced MySQL Replication Techniques ，MySQL Team 的 Harrison Fisk 是演讲人，另一个话题为 Success with MySQL ，分享人是 Mark Callaghan，他也是 MySQL Engineering Team 的 Lead，Facebook 有个 MySQL Performance Team，是介于运维护与工程师之间的团队。演讲的过程中除了 Facebook 之外只能听到 Google，其它公司或许不值一提，也或许是 Facebook 和 Google 渊源颇深的缘故吧。

Facebook 的数据库团队之所以能够维护几千台 MySQL DB，和他们对 MySQL 代码层的驾驭能力有很大关系，Facebook 自己就发布了不少 MySQL 的 Patch(在 Lunchpad 上可以找到)，另外，Google 发布的 Patch 对他们来说也有很大帮助。此外，Facebook 也是当前世界上最大的 Memcached 用户，MySQL 的压力反而小了很多。基本上 DB 是用来做关系数据的存储以及跨 IDC 的数据同步。Faceook OLTP 环境的一些基本数据：查询响应时间 4ms ,写操作的响应时间为 5ms, 峰值每秒钟读取 3.5 亿行数据，修改行数为 350 万行，网络峰值吞吐量为 38GB，每秒钟应对的查询有 1300 万次。相当的惊人。大一点的表基本都进行了 Sharding，会后问了一下，Facebook 目前也没有使用 SSD，但是在做初步测试。

（这是 Facebook 之前的演讲现场，会场人不多，毕竟是第一天报到日）

会场同时也有其它关于 MySQL 的演讲，有关于 MySQL 5.5 新特性的介绍以及一些业界公司的 DBA 分享经验，可惜的是，人不算特别多，可能是听众目标不是集中的缘故吧。很多人的兴趣都还在傍晚时候 Oracle CEO 的主题演讲，当然，那些猛料这会儿大家应该都知道了。

–EOF–

Facebook 架构学习

在 QCon 2008 (旧金山站) 上Facebook 做的这个技术分享有不少值得借鉴的东西。所以，暂停对 QCon 北京的回顾，临时插播一贴。

设计原则

尽可能的使用开源软件，并且在需要优化的时候进行优化
Unix 哲学。包括，模块化原则；整合化原则；清晰化原则等
任何组件具备扩展性
最小化故障影响
简化，简化，简化！

架构概览

Facebook 是 LAMP 的坚定支持者，也差不多是用 LAMP (或许用 LAM²P 更适合) 实现的最大的动态站点。

基础组件加上服务，中间用自己实现的一些工具进行粘合。其中关于运维细节的事情基本不会说出来的，这是很多公司的软实力所在。

PHP 经验

参见《Facebook 的 PHP 性能与扩展性》

MySQL 经验

主要用于做 Key-Value 类型的存储操作，数据随机分布在多台逻辑实例上，访问多数基于全局 ID 。
逻辑实例分散在多台物理主机上(超过1800台)，负载均衡在物理层进行。
不做读复制。
尽量不做逻辑数据迁移(成本太高)。
不做 JOIN 操作 (豆瓣在 QCon 上也阐述了这一点)。数据是随机分布的，关联操作反而带来了极大的复杂度。
对于数据访问，主要的操作集中在最新的数据上，针对这部分做优化，旧的数据进行归档。
在中心 DB 绝不存储非静态数据。
使用服务或者 Memcached 进行全局查询。

Memcached 经验

参见我以前的笔记：Facebook 的 Memcached 扩展经验。Facebook 对 Memcached 做了不小的改进。另外，顺便说一下，前两天 Memcached 刚在 1.2.7 发布几天之后又发布了新版本 1.2.8，修正了一些问题。

一个比较有价值的是关于个人页面数据的获取的描述。这个就完全是需要做单页面 Benchmark 的细致活儿了，可能还需要产品经理能够理解工程师的”抵抗”。

获取个人信息数据：通过Cache，隐性通过用户所在的 DB 获取(基于 User-ID 获知 DB)
获取朋友连接信息：通过Cache，否则的话通过DB(基于 User-ID 获知 DB)
并行抓取每个朋友的 10个照片相册 ID ，从Cache抓取，如果失效，再从 DB 抓取(基于相册 ID)
并行抓取最近相册中的照片数据
运行PHP 把整个业务逻辑跑出来
返回数据给用户

然后是对 Facebook 非 LAMP 体系的东西做了一番介绍，基本上也开源了。最后参考两个架构图。

Facebook NewsFeed 的架构示意图

Facebook 搜索功能的架构示意图

管中窥豹，盲人摸象而已。

–EOF–

Facebook 的 Memcached 扩展经验

周末的时候看到这篇 Scaling memcached at Facebook，感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).，现在 Facebook 在 Memcached 上的内容已经超过 28TB，总服务器数量超过 800 台。可见硬件降价真是够快的，内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器，总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响，这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句，网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力，延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

–EOF–