分类归档: Arch

FriendFeed 使用 MySQL 的经验

一直比较好奇 FriendFeed 网站背后的技术信息。Bret Taylor 的一篇 How FriendFeed uses MySQL to store schema-less data 给出了不少有价值的经验。

概览

FriendFeed 用 MySQL 存储绝大部分数据，超过 2.5 亿条记录。对待网站功能的态度: 让既有功能满足更多用户而不是添加更多的功能。

少添加新功能的好处是数据库 Schema 变化更小。在数据库Sharding 的情况下，如果修改 Schema 结构，必然会影响可用性。此外，几乎不进行复杂一点的关系型查询(比如不做 JOIN 操作 — 这要用到传统意义上的索引机制 )。FriendFeed 也没有采用什么更新的数据库解决方案(比如 CouchDB )，原因无他，对 MySQL 更谙熟，知道其短长，扬长避短同样能发挥更大的作用。

Schema-Less

这是 FriendFeed 对付数据库的基本策略。只存储基本的对象属性，如果需要修改 Schema 层面的东西，只需要存储新的属性即可。其实就是更加”面向对象”，由基本的「元数据」一步一步衍生到所有的数据对象。

坚持「去索引化」，因为维护索引带来了复杂度，将索引数据存储到到表上。我认为这也是反范式的一个新的思路。在 Bret Taylor 文章的「Details」一节中给出了具体的例子。比如要在 user_id 上进行索引，那么创建 index_user_id 表(存储来自所有 Shard 的数据)，以 user_id 和 entity_id 为主键即可。这样在修改基表的时候，不需要对其他「索引」表做变动。而删除「索引」也极为方便–删除创建的「索引表」即可。

一致性与原子性

关于一致性可能会有问题，但是可以确定基本原则：

主条目表中存储的属性数据是规范的
索引可能不对应实际的值(这和关系数据库本身的索引有些不同之处)

写入数据的时候按照如下顺序：

写入条目表用 InnoDB 的 ACID 属性来保证
把数据写入到其他 Shard 上的索引表中(猜测可能还是要延迟写)

在读取的时候可能会有短暂的数据不一致性的现象，但很快就能校正。考虑到 FriendFeed 业务的容忍性，这个问题并不严重。

笔记总结

总体感觉，FriendFeed 用了一种非常巧妙的方式进行数据库扩展（多耗费了一点存储空间)。不过这个方式总体上看来，极大减少了手工维护成本。相信 FriendFeed 分享的这个经验能给国内一些需要处理即时信息的站点一些启发。以上只是我的个人理解，如果去看一下 Bret 文章后面的留言，你肯定能得到更多信息（比如为何使用 UUID )。

最后提一下，FriendFeed 用 pickle 做 Python 的对象序列化。当然 Memcached 也是居家旅行必备佳品。

–EOF–

Smugmug 使用 MySQL on ZFS 的成功经验

看到 Smugmug 的 CEO
Don MacAskill
写的一篇关于使用 Sun 软件栈的经验。Web 2.0 公司用 Sun 这套东西的真的不多见。

Smugmug 解决方案前后对比
旧方案	新方案
Linux	OpenSolaris
MySQL 5.0	MySQL 5.1
LVM2 + EXT3	ZFS
硬 RAID	软 RAID
非压缩	GZip9 卷压缩

其实从一个技术体系迁移到另一个技术体系，最合理的理由就是能得到哪些收益。整个项目看下来，ZFS 是其中最大的亮点。管理简单，功能丰富，足够稳定。此外，ZFS 的备份、压缩功能也是非常值得称赞之处。

至于 OpenSolaris 的启用，倒是有一些潜在的隐患，比如 GNU 工具的集成使用上，缺少经验可能会给用户带来不少麻烦。其实 Sun 也是的，干脆把 ZFS 和 Dtrace 移植到 Linux 上算了。何必抱残守缺呢? 说起 Dtrace ，这可是好东西，性能 Tuning ，那可是屠龙刀。值得一提的是，以 OpenSolaris 衍生的Nexenta 项目似乎很有趣。

–EOF–

专访 Amoeba 项目开发者陈思儒

老文。去年受泰稳之托做的采访。这是我整理的稿件。另请参见 InfoQ 中文站上关于 此文的更多信息。

可能 MySQL Proxy 很多数据库技术人员都比较熟悉了，在前不久，国内也有开发者发布了一个Amoeba(变形虫)项目（http://sourceforge.net/projects/amoeba），这个项目专注分布式数据库 Proxy 开发，引起了广泛的关注。 DBA notes( https://www.dbanotes.net ) 站长Fenng 有幸采访了阿米巴项目的开发者陈思儒，以下是采访全文。

Fenng：你好，思儒，很高兴能接受采访，简要介绍一下自己吧?
陈思儒: 我目前是盛大计算机(上海)有限公司的一位高级研究员。在就业生涯中从事分布式消息系统、分布式应用、多层框架设计、规则引擎开发框架研究，以及 Java 2D MMORPG框架研究。

Fenng: 说一下当初开发 Amoeba 项目的缘由如何，估计其中也会有不少小故事吧? 我可是非常好奇。
陈思儒: 其实 Amoeba 的前身是网络数据包分析代理，之所以 Amoeba 能够快速稳定发展也是因为个人在前期使用这些技术分析过一些游戏的数据包(这儿不方便透露一些细节，这些都只是个人爱好而已，并没有破坏那些被我研究过的游戏 :D )。

为什么会有 Amoeba 这个产品，这个话题的确非常有意思，我关注 MySQL Proxy 也有一段时间了。MySQL Proxy 的这种想法做的非常棒，它能够根据自己的想法去构造目标的 MySQL Proxy 应用，比如监控 SQL 执行、数据流量、读写分离。但由于我们使用 MySQL Proxy 并不能非常轻易的解决一些问题（读写分离、数据切分、水平切分、负载均衡），而是需要写大量的Lua Script，这些 Lua 并不是现成的而是自己需要去写。这个工作对于并不熟悉 MySQL Proxy 内置变量、MySQL Protocol 来说是非常困难的。

因此带着这个想法我就设想做一个非常容易使用、可移植性非常强的软件。Amoeba就因此诞生了。为什么叫Amoeba? 其实这个想法我是突然想到的，Amoeba中文意思是”变形虫”，Amoeba被设想为数据库代理的开发框架，它可以为符合Amoeba框架的任何数据库开发代理层。因此也比较象”变形虫”一样能够变成目标数据库的代理层软件。

Fenng: 我观察到 Amoeba 与 Oracle 交互的时候似乎还是模拟 MySQL 的驱动器, 实际情况是否如此?
陈思儒：目前Amoeba有2个产品：Amoeba for MySQL，Amoeba for Aladdin 。这2个产品有不同的适用范围：

Amoeba for MySQL：被代理的只有MySQL数据库，需要分析 MySQL网络协议，它的代价比Aladdin会小很多，而且性能也较高；
Amoeba for Aladdin：被代理的可以是目前提供Jdbc driver的所有数据库，这些数据库可以同时并存于Amoeba for Aladdin后端。

其实在我上一家公司的时候也正在研发 Amoeba for Oracle，这个产品目前还正在研发状态。这个产品性能也跟 Amoeba for MySQL 一样出色。

就 Amoeba for Aladdin 产品来说，后端的任何数据与 Aladdin 交互采用 JDBC Driver. 对于 Aladdin来说，数据库的协议是透明的，而应用跟 Aladdin 的交互则采用 MySQL 协议，这个做法很多人有不明白，其实做这个决定主要是想借助 MySQL 使用的广泛程度以及对各种开发语言的支持。因此对前端的应用来说 Aladdin 就是一个虚拟的 MySQL 数据库。你这个问题应该是问使用 Aladdin 的时候。

Fenng: 是的，是在看了你的 Aladdin 架构图后产生的疑惑。你比我严谨多了(笑)。能否冒昧问一下 Amoeba 项目当前的局限?
陈思儒：虽然 Amoeba 能够很好的解决水平切分、垂直切分等，但还是会存在一些局限性，这些局限性是因为我们在设计目标的数据库架构的时候就必须考虑到我们未来的数据库框架（可以线性扩容的数据库架构）。因此也有些查询将不支持，比如跨数据库服务器进行Join，我们要尽量避免类似的业务出现，也可以通过多次查询来解决这类问题。

Fenng: 你在前面也说到了 MySQL Proxy，能否简单的说说 Amoeba 与 MySQL Proxy的区别?
陈思儒：其实说与MySQL Proxy的区别应该是Amoeba for MySQL与 MySQL Proxy 的区别，在上面表述的第二点应该都涉及到了:

Amoeba只是目标数据库代理的开发框架。
Amoeba for Aladdin 是另外一个类似Amoeba for MySQL的产品。他们共同点是都可以做负载均衡（HA、ROUNDROBIN，WEIGHTBASED）、读写分离、数据切分（垂直、水平）、failOver。

Fenng: 据说你也分析过 Oracle 的 TNS 协议，你认为可靠性如何?
陈思儒：的确，我在上一家公司为做 Amoeba for Oracle 分析过 TNS协议，可靠性以及安全方面都是没什么问题，Oracle 还提供了一些网络层的性能参数，用来改变Oracle的网络吞吐量。但是 Oracle 的数据部封包做法让我和老同事在分析 Oracle 数据包的时候伤透脑筋，我觉得 Oracle 如果想在协议上面升级版本将不是一件容易的事情。而MySQL 的协议封包的做法我比较赞同。

Fenng: 对于分析 TNS 的可行性，我的看法倒是和你类似。顺便问一下，现在 Amoeba 是否已经有了成功案例, 方便的话能否举几个?
陈思儒：Amoeba for MySQL 的成功案例，目前就网友直接跟我说的有几个，但我还没具体了解他们具体的公司名称，以后知道了我再透露。

Fenng: 到时候千万要通知我一下。对了，能否说一下 Amoeba 项目的愿景以及下一步的目标?
陈思儒：目前距离Amoeba发展目标还有一点距离，Amoeba 未来将是一个更加容易使用、可管理、可动态装载配置、Amoeba集群等。

如果未来可行的话，我将补充 MySQL 协议，做一个用于负载均衡的”重定向路由器”（类似F5功能，但它只是做连接跳转）。

Fenng: 现在开发者主要是你一个人? 是否还有其他维护者 ?
陈思儒：Amoeba 框架、Amoeba for MySQL、Amoeba for Aladdin 目前的开发就我一个人。

Fenng: 很高兴你接受我的采访。期待 Amoeba 项目取得更大的成就，也祝你工作愉快！
陈思儒：客气！也希望有更多的开源爱好者或是数据库技术爱好者加入到这个项目的开发中来。关于 Amoeba 项目的进展我会在 “Amoeba 开发者博客“上更新，欢迎订阅。

–EOF–

旧文重发，期待新的一年这个项目能有更大的发展，能有更多公司从该项目中受益。

云计算中的存储续

接上一篇。这其实是一篇综述文章 :)

是否该建设云存储服务?

可能有些企业已经在战略中加上了云计算这个关键字，问题是，真的需要那么多云计算么? 如果在技术上、规模化不能有效的节约成本，那么跟风建设云存储服务是缘木求鱼。更多的企业是自身的存储建设都远远不到位，大谈云存储无疑是痴人说梦。至少在国内，我们的基础建设还和国外有一段距离，而内容审查与一些政策上的限制又会增加建设、运营成本。

是否该使用云存储服务?

回答这个问题之前，我建议先看看服务提供方是否真的是云存储服务，如果只是炒炒概念，用老的架构支撑，换汤不换药，那还是谨慎为妙。企业如果不能从技术上做些本质突破而节约成本，那么成本肯定要转嫁到消费者身上，如果消费者不买单，那该服务如何能长久? 和我们现实生活中很多山寨 IDC 类比一下就知道了，动辄听到某主机托管商一夜之间蒸发，用户欲哭无泪的事情。

如果使用云存储服务，不妨和竞争对手使用同一家服务商。出问题的时候大家都出问题，保证始终处于同一起跑线。

在国内，短期内还看不到有规模的云存储服务商。由于网络的问题，企业用户也不太可能去使用国外的服务（不排除将来 Amazon S3 这样的服务能在国内提供服务）。期待在未来的一段时间能看到一些变化，但这恐怕只是乐观的想法。

云存储的潜在问题

数据安全

同样是数据存储到云存储服务商那里，如果我的隐私数据被泄露了怎么办? 业务数据被竞争对手盗用了怎么办? 消除用户的顾虑仍然需要时间。

网络带宽问题

只有数据没有网络，好比鱼儿没有水。如何保证大规模数据的有效分发与负载均衡，这也是云计算提供方与使用方都需要考虑的问题。

SLA 的问题

对于提供云计算存储服务的公司，用户很难看到他们严格执行SLA (Service level agreement) 。遇到大规模故障的时候，还做不到有效的为所有用户提供服务支持的能力。

云存储的钱途与前途

时值全球经济的寒冬，能够为用户省钱的服务相信也应该能够赚到钱。从用户的角度上看，云存储解放了自身的生产力，能够允许中小创业团队集中精力做发展业务，只要不形成恶性竞争，应该不用担心盈利的问题。

就以 Amazon的 S3 来说，基本上也很好的展示并实践了 Web 2.0 长尾理论：利用企业建设剩余的存储以及网络带宽能力而为广大中小网站提供服务，前途大好。相信 Google 推出类似服务也是指日可待的事情。但这个市场内应该不会出现过多的有力竞争者，有些存储厂商(比如 EMC) 也在进入这个领域，数据存储不是问题，但网络能力可不是那么好解决的事情。

云存储与传统存储：SAN 能否还能发挥余热?

从我们前面提到的云计算中的存储特点来看，SAN(存储区域网络)产品就暴露出一些不适合的应用场景，毕竟 SAN 是面向集中式计算的架构。另外，大家也都知道 SAN 产品一般不便宜(现在也有厂商在力推低端海量存储产品，后面会介绍)，而且，主机端如果用 HBA 卡，也会进一步提高成本；SAN 面向传统企业应用而设计的扩展能力难以满足云计算的需求。

目前尽管已经有一些企业在做集群存储然后打包出售，但相对还是在起步阶段。至少现在还看不到真正集群 SAN 产品的出现。当然，如果对云计算的存储部分不计成本的话，SAN 仍然可以在云计算中发挥一些作用，这倒是中了存储厂商的下怀。

不管怎么说，RAID 这个 SAN 中的概念在云存储中已经绝对不适合了。

集群 NAS 是否真的有机会 ?

有业界评论说集群 NAS 可能会演变成云存储的通用架构，我怀疑这是不是 Sun 公司的宣传手段，因为这事实上宣布了 ZFS 将是云存储中的一个关键点。

从现有的情形看，或许会有越来越多的在线存储服务拥抱集群 NAS 。但这不代表集群 NAS 前途光明能够在云存储大展拳脚。集群 NAS 最大的问题是海量数据的寻址是个麻烦事儿，然后是扩展性与容错性的问题，底层的容错性如果通过硬件来做，那么成本无疑会上升，这恐怕是企业不愿意接受的。

分布式文件系统

在开源领域，以 MogileFS 为代表的分布式文件系统能够用于一些相对规模较小的分布式存储场景，很多 Web 2.0 自己的分布式存储就是借鉴 MogileFS 搭建的，不过毕竟 MofileFS 的Meta 信息仍是集中存储、管理的，在更大规模恐怕有些吃力。

此外，Kosmosfs（http://kosmosfs.sourceforge.net/）、Lustre(http://www.lustre.org) 等也都在不断发展中，相信能够给有兴趣研究云存储的技术人员一些借鉴。也有一些软件厂商将其专有的分布式文件系统和存储打包在一起销售，而存储厂商也有的在结合自己的存储产品做一些尝试。目前还很少有相对成熟度的东西进入用户视野。

更多分布式文件系统列表参见维基百科的文件系统列表介绍。

分布式文件系统举例：拥抱开源 Hadoop 的 HDFS

尽管我们接触不到 Google 大名鼎鼎的 GFS （Google File System），但我们能免费获取 Hadoop 的 HDFS (Hadoop Distributed File System)。HDFS 相对上述的 ZFS 来说，属于专门针对廉价硬件设计的分布式文件系统，在软件层内置数据容错能力。Hadoop 目前的案例多数用在数据分析与并行计算上，倒是很少看到有支撑给互联网应用的数据服务，但相信随着其在开放环境中的快速成长， Hadoop 将不断壮大。

（HDFS 架构示意图. from: http://hadoop.apache.org/core/docs/current/hdfs_design.html 关于 Hadoop 也请参阅《程序员》杂志 2008年10月刊的文章。）

速成版存储方案成本评估

云计算中存储的起步容量，我们不妨按照 1PB 可用空间来准备。近年来，随着磁介质存储能力的提升，企业存储的价格也是一降再降，$2.00/GB 的底线早已突破，现在Sun 的Thumper 声称可以达到 $1.20/GB 的成本。(注：企业存储[不是个人消费品]的磁盘价格一降再降，而且有很重要的商业因素，具体的成本应该还要更低一些，只是不知道哪位朋友有更为准确的数字)

粗略估算一下，2PB 的原始容量成本大约是 250 万美元左右(List Price)。单位机柜空间密度最高的已经能够做到4U的机存储48TB的原始容量(目前能看到密度最高的了)，这样最小只需要大约 45 个 4U 的机柜空间。其他方面，加上本地的工业电力价格，大致的硬件总体开销还是可估量的。软件方面，这个存储本身是基于 Sun 的 ZFS，内置的操作系统，成本也是可以控制的。

山寨云存储方案设想

在山寨精神盛行的今天，没准儿已经有人在搭建一套山寨版的云存储方案呢。比如目标定在 1PB 可用容量，预计至少需要如下的东西:

选择廉价的刀片服务器(自己”生产”就不必了)，内置足够多的大硬盘，硬盘速度无所谓，预计每台机器预装4T容量(1T*4，坏了就整台机器替换)，大约需要 500台服务器，总容量2PB，确保每一份数据都至少冗余在另外的物理机器上，冗余后，起码能得到1PB容量(如果备份的数据启用压缩，没准儿能提供更多空间呢)。机架物理空间怕是需要 1000 U多一些，每个标准机柜是42U，怎么也要准备 25 个机架吧，再加上网络交换机什么的… 然后是电力与空调散热问题。

再弄一套 Hadoop ，定制一下跑起来 …当然，山寨与否，关键是拼技术团队，一味的拿来主义注定只能跟风。

其实，这篇文章也是一篇山寨文。

–EOF–