分类归档: OpenSource

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–

Red Hat 企业版 Linux 的一些改进

Red Hat 正式发布了企业版 Linux 5.5 版本。原以为这个版本发布不会有太多新鲜的内容，读了一下 Release Notes，还是有不少值得关注的地方。

注意其中有一句话，一定要关注一下，每个逻辑 CPU 推荐至少需要 1GB 的内存。为什么?

这一版本对于虚拟化环境中使用 HugePages 有所改进。系统设定使用 HugePages 之后，Libvirt（虚拟化 API) 针对 Virtual Guest Memory 自动使用 HugePages 。需要技术人员考虑这对虚拟化环境中的 DB 有什么影响?

改进了 Completely Fair Queuing (CFQ) I/O 调度器在某些应用场景下的性能。很多 Linux 用户都不太注意默认调度器的问题。性能上其实还是会有很大差异的。知其所以然才好。

关于 SystemTap 和 Valgrind 的引入对于系统管理员来说，是个好消息。前者有助于性能调查，后者有助于内存泄漏分析。

阅读 Release Notes 是个很有趣的事情，技术人针对自己感兴趣的领域可以多关注一些类似产品的特性，用其所长，技术选型上应该采取主动一点的态度。

–EOF–

从 7-Zip 的预设格式说起

在 Twitter 上看到笑来和几个推友说起关于提供下载为何不用更通用的 ZIP 文件格式而用 7z 的格式(refer)。这个倒是挺有趣的话题，刚好我也是 7-Zip 的用户，对这个不习惯也由来已久了，也一直不喜欢这个方式。

7-Zip 的默认压缩文件格式为”7z” (扩展名是 .7z) ，就是这个微小的差异给用户添加了很大的麻烦。设想一下，你用 7-Zip 压缩了一个文件，扩展名为 foo.7z ，传给了你的朋友(非IT人士)，而你的朋友用的是 WinRAR，这是压缩软件市场上的主流，他看到这个格式之后，他会如何反应? 换个应用场景，如果一个普通用户，从网络上下载一个软件，下载完毕之后发现默认没有软件能打开这个 .7z 为扩展名的文件，他会如何做?

必须要承认，7z 压缩格式有很多优点，而 7-Zip 是个很好的压缩工具软件，但在预设格式上的这个事儿，不折不扣的是在挑战用户习惯。或许有人支持这样的做法，一个支持观点是 7z 格式压缩比更高。这是个很好的理由，不过，那么一点点的压缩比收益，考虑到当前个人用户所用设备的存储能力以及网络支撑能力等，对于单个用户来说，无法抵消使用习惯带来的麻烦。除非全世界都是 7-Zip 的用户，很可惜，现在的 WinRAR 仍然是市场绝对的主流，而 Zip 与 RAR 格式也是事实上的标准。另一种支持观点是现在所有主流压缩软件都支持 7z 格式了，所以使用是合理的。的确，主流压缩软件可能支持了，但是，绝大多数计算机用户不知道这个事实，和他们不知道没什么本质区别。或许，会有人认为这是 7-Zip 发展用户的一种独特的手段，如果是的话，那恐怕这是最拙劣的营销方式，形同绑架用户一样。

如果不是市场的绝对主导者，任何挑战用户习惯的的行为无疑是危险的。相比 WinRAR 和 WinZip 来说，作为开源软件的 7-Zip ，只需要使用习惯和前两者一样，而功能甚至都未必那么强，就会赢取大量用户。但是给用户习惯設置障碍的做法无疑是不可取的。如果有人不同意，那么还记得”兼容机”这个词汇吧 ?

开源软件应该多考虑使用习惯上的”兼容性”，做网站也是一样，有多少人在设计网站的过程中真的尊重用户的遗留习惯? 而你是如何做的呢?

–EOF–