March 2009 Archives

近期在和几位同事一起翻译这本 Troubleshooting Oracle Performance (TOP)，这是2008 年国外 Oracle 相关书籍中唯一一本值得期待的作品。

本来撺掇同事童家旺写书，不过他谦虚到底，说宁愿翻译，而且一般的图书看不上，只对这本 TOP 感兴趣，家旺慧眼识珠，我也只得勉为其难，助他完成这事儿(其实我对这书也非常感兴趣)。翻译图书是吃力不讨好的活，考虑到各自工作也比较繁重，又拉来同事胡怡文，三个人乐观估计可以拿下这本厚达 600 页的大作。没想到几个月过去，还是耽误了进度不少--出版社估计已经准备扣稿费了 :)

这本书的作者Christian Antognini，对 Oracle 数据库的理解精深，凭借此书已经奠定 Oracle Guru 地位。其人也是 OakTable 的成员，说起 Oak Table ，这是一群 Oracle "科学家(Scientist)" 的圈子，没有几手绝活只凭忽悠那是不能位列其中的。

目前这本书已经倒了后期校稿阶段，近期准备放点样章上来供大家参考。翻译得是否得体，亦或佶屈聱牙，还请各位别吝惜手里的板砖，尽管拍来。

--EOF--

在上周日奇遇花园咖啡馆举办的 Beta 技术沙龙上，手机之家的高春辉和他的战友们带来了他们网站技术架构与大家分享。

之前就手机之家的架构采访过老高，这次是来了图文并茂版了。希望过几天能有个视频的 :) 读了 PPT 之后，比较感兴趣的是关于 Cache 的处理：

...对数据库记录的缓存的访问做了一定的抽象处理，开发出了Cache 处理器。所有的数据访问都经过cache处理器。这样，系统代替程序员接管了缓存的存取访问。缓存的KEY和VALUE由系统处理，从而避免了冲突和混乱。Cache 处理器的引入减少了40%的数据访问层代码！最重要的是，我们采用了Namespace的方法使得缓存能自动清除了。

因为身在杭州，不能分身参加。不过第一时间从老高那里要来了 PPT。共享一下。

最后(最重要的是)，手机之家还在招聘 PHP/Java 人手，有意者给老高发邮件: [email protected] 。

--EOF--

看到消息说 Nutch 正式发布 1.0 版本。这个 Lucene 的衍生项目，现在已经孵化长大。

很早以前我无聊的时候记录过一点使用 Nutch 的笔记(一、二)，现在还有人搜过来 :) 时过境迁，已经没啥用啦。

Apache 基金会下面的几个搜索项目应该说是极大解放了生产力，让搜索引擎这个看似高深莫测的东西走入寻常百姓家。很多公司自己的搜索引擎都参考了 Lucene 和 Nutch 不少吧。

--EOF--

几年前我说：

不久的将来，有 Nutch 支持的个人搜索引擎或是主题搜索引擎会大行其道。到了那个时候，或许 Google 这种垄断式搜索巨头的影响力已经不再！

原来只是痴人说梦。

当一家公司发展到一定规模的时候，可能就不如初创时那么有朝气了，初创时，没有包袱，轻装前进，高标准，严要求。而江山渐渐坐稳，"创新"渐渐就会成为一个熟悉而陌生的词汇。

如果整天喊着创新而实际上产品没有任何新意的时候，应该注意一下是否那些管理人员在其中起着阻碍者的作用。所谓创新，如果不能充分调动基层员工的积极性，那是不可能做到的事情，而无意识的妨碍基层员工进行创新，更多是出于管理者自身本位主义的考虑，管理者们应该知道"不破不立"的道理，但是"破"对他们来说，风险太大，远不如原地踏步，或是拿来主义，这样才稳妥，这样最不济犯错也是别人先犯。这个时候，很难去对他们奢求"用户第一"的自我要求。

回过头来，如果产品自身千疮百孔，被用户整天批得体无完肤。与其开发一些未必靠谱的产品，还不如埋下头来把当下的问题搞定。创新要在一定基础之上，缺乏叫座的产品做铺垫，所谓的"创新"只是空中楼阁。

创新还是撞墙，这是个问题。

--EOF--

再有几天 QCon (Beijing) 技术大会 就开始了。QCon 是这几年出现的最有价值的技术会议，"绝对有技术含量"，相信北京这次也会让每个人不虚此行。这还是第一次在国内举办，很多国外的大师都来了，有机会能参加也是一件好事。

受邀主持网站架构案例分析这一场，所以有机会提前看到各位技术演讲人提交的 PPT。前天晚上看到豆瓣首席架构师洪强宁的 《豆瓣技术架构的发展历程》，击节称赞! 这个 PPT 会成为一份相当经典的架构参考文档。

据说现在已经一票难求了，如果要购票的话，可以用我的折扣代码。买票的时候报我的 BLOG 或者我的名字就可以省点钱。

--EOF--

按：这其实是某一本书的推荐序(我这段时间没写 Blog 净帮着人忽悠了)。不过遇到了不靠谱的出版社不靠谱的编辑，据说整篇文章最后"只采用一两句行不行"? 当然不行。以后如果有出版社找我免费写推荐序或者书评，请自己考虑好再来浪费我的时间，多谢配合。

有的时候朋友们聚在一起聊天，会谈到国内国外技术人员的差异。我常喜欢说一句话"国内的 IT 公司基本上是劳动力密集型高科技企业"。比如就国外 Web 2.0 站点来说，Craigslist 、Wikipedia 等流量比较大的网站不过数十人的小团队而已，如果放在国内，这样规模的网站起码要几百人乃至更多人员才能足够支撑。国外程序员一个人做的事情，国内可能要一个团队来做，当然可能还做不好。这里面或许有企业管理效率低下的因素存在(宁愿相信是这样的原因)，不过大家都不愿意说的另一个因素是我们技术人员生产力效率低下。这种差异来自不是智力、体力上的差异，而是因为做事情的方式和方法，存在大量的重复劳动和人工劳动，对技术不能充分有效运用。如果不能对工作方式方法进行改进，我们永远都是技术流水线上的编码工人。

我们常说，重复的行为才能形成习惯，只有良好的习惯能导向成功。或许有人某些书籍或者聆听了某些"教诲"会逆反性的产生不以为然的想法，"这个我早就知道......" -- 我自己常常就是这样自以为是。问题是，只是"知道"而没有行动起来加以"运用"，这样即使知道再多的技巧也不会形成良好的习惯，自然无法产生实质的改进，这可能也是技术人员惰性的一方面吧。其实我们需要的是能有更多的技术人员真正的行动起来，利用这些经验/教训/技巧...提升自己，也去积极影响他人，形成更良性的互动，不要让"持续改进"成为一句空话。另外，必须要补充的是，如果技术人员持续从事低效率的工作，极有可能逐渐厌烦技术，疏远技术，乃至对技术绝望，而一个高效的技术人才能从技术中获得真正的快乐。

也想告诉那些所谓的管理人员，不提升每位技术人员的生产力而希翼增加人手来解决技术困境的想法是不切实际的。那样做除了给企业增加负担，使组织更加混乱低效，很难起到什么实质作用。好的管理者必须能够引导下属持续提升生产力，不能一味用死板的流程制度限制团队的整体节奏。彼德克鲁克这之类的管理大师的大腿人人都好抱，但那是屠龙之术，您暂时还可能用不上，来点痛快实在的才是王道。

--EOF--

文章有删节。出版社的名字我就不直接说了，不过类似的经历的人还有潘加宇。你猜这是哪一家?

来到杭州四年了。前几年都还有个兴致简单总结一下过去一年的感受，今年都忘了这件事儿了。昨天好多朋友在 Twitter 上给我发来生日的消息，很感动。虽然我是按照老家的传统过阴历的生日。

上周有新入职的同时过来采访老员工，一天居然接待了两拨，向他们传递一些积极向上的信息的时候，自己其实心里非常困惑。可能人总要靠一些梦想支撑着做事吧，如果你信，就是真的，否则，真的你也不信。

最近有些事情缠身，杭州又连下了多天的雨，难受，压力之下戾气大增。"阴晴圆缺在窗外，心中一片艳阳天"，这是挺难得的境界。

如果没看到我发布 Blog ，那么我的 Twitter / Flickr / del.icio.us 可能都有内容更新，他们的价值或许比我写的文章更高。

不管怎样，我没有离开，依然在那儿，对，在网络上。

--EOF--

接下来的一些事情:

• 4月去北京参加 QCon 技术会议
• 杭州有家咖啡馆快开业了...
• 和同事把手里的稿件校对完
• 继续改进 JobsDigg ，让更多人受益

这几天给我印象比较深的是 HeroKu ，提供 Ruby 快速部署环境并提供托管能力，他们的架构图做得十分漂亮，一幅图胜过千言万语，要是对 Web 架构感兴趣，都别问架构师了，看看 HeroKu 的架构估计就明白个差不多了 :)

概览图

好的架构图是画出来的，好的架构未必是设计出来的，最后架构好不好，还要看持续的改进能力。

使用 Nginx , 这一层只进行 HTTP-level 的处理。Nginx 现在是不二选择。

对于静态内容，使用 Varnish 进行缓存。如果你在 Squid 和 Varnish 之间作选择，这里已经投了一票。

用 Erlang 实现的架构组件，路由寻址，用以提升可用性和扩展性。

用户部署的代码运行在这里，可以简单看成是应用服务器集群环境，只是粒度更小一点而已。

对于 Dyno Grid 的进一步信息：

服务器操作系统是 Debian ；Ruby VM 是 MRI ，开源，C 写的；App Server 用的 Thin，他们说 Thin 比 Mongrel 更精炼；Rack，应用服务器接口；Rack 中间件，可选组件；框架，任何 Rack 兼容的都成；最后是客户托管的代码。

数据库

PostgreSQL，也可以采用远程数据库。

Memcached ，居家旅行架构必备。

这几张图看下来，多少算是对 Ruby 环境有了一些感性认识。可以进一步查看 HeroKu 提供的文档，包含了一些代码实现上的准则。

部署是基于 Git 的。不知道大家有没有注意到 Git 在最近一年来的爆发? 超过 SVN 或许不是不可能的。

国内热炒"云计算"的，跟人家学学吧，与其整天帮着客户开发定制软件，还不如给客户提供一些弹性应用托管环境，起码看起来靠谱一些。

HeroKu ，不读 Hero-Ku, 读作 Her-oh-koo, 挺有趣

--EOF--

图的来源：HeroKu Platform Architecture

最近北京奇遇花园咖啡馆举办了一场 "Beta 技术沙龙", 关于"有道阅读器产品设计"的话题。

在杭州也没办法过去参加，倒是第一时间看到了 PPT。又问了以下，PPT 可以进行传播。所以截取了两张图(版权属于有道)学习一下。先是交互易用性问题。有道的数据库缓存策略是把当天的数据缓存起来，用 Memcached ，不知道改造过过还是默认方式使用。有道的 Ajax 交互的响应速度相对比较快。也是 用 JQuery -- 几乎快成了居家旅行必备 JavaScript 库了。

用 YSlow 分析了一下有道前端的一些策略，发现大部分都做得不错，挺专业。Web 服务器是 Apache (不是 Nginx )，不过大部分图片设置为一周过期有些问题，太保守了，其实图片不过期也没啥问题，RSS 阅读器中的静态文件其实几乎不变化--除了用户的头像。应该说，判断一个网站是否合格，看看前端优化做得如何就可以了，如果做的不好，要么是太有钱，不担心带宽和计算资源的浪费，要么是根本不考虑用户的使用感受。

对于抓取的数据全部保存的问题，我不知道有道对 Feed 抓取过的内容更新问题如何处理。谁让咱没去现场呢，等下次有机会再了解一下吧。最后一点期望：有道什么时候能把订阅数让 FeedBurner 正确识别? 相信对大一点的网站 Google 多少能重视一点吧 ?

--EOF--

今年以来，一些小型但有针对性的技术沙龙逐渐活跃起来了，嗯，杭州，在 5 月份之后也将开搞，敬请期待。

肯定有人问哪里有 PPT ? 访问 Club.blogbeta.com

另参见：霍钜的 《关于有道阅读的beta技术沙龙》

一直比较好奇 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--