December 2009 Archives

2009 年个人总结

| 11 Comments

每年的年终总结是个有趣的事情,没有回顾,也就不会有进步。虽然过去几年制定的计划完成情况都不是百分百完成,但却的确对个人起到一点作用。

看一下 2008 年底制定的 2009 个人计划

2009 年的 TO-DO List 完成情况

  • 翻译一本书 和同事合作翻译 Troubleshooting Oracle Performance,中文版叫做 《Oracle性能诊断艺术》已经面市。这本书的翻译用了不少时间与精力,也有收获,这是最后一次翻译图书。
  • 写一本书. 没有完成,图书翻译让我倒了胃口,一鼓作气,再而衰,三而竭。说的就是这样的情况吧。
  • 提高团队声望. 还算可以。对外团队宣传有了一点影响力,为公司招募了几位技术牛人。当然,这多少也是吃力不讨好的事情,但自己个人感觉很欣慰。
  • 提升技能. 做了一个项目,技术功力恢复了一些,当然,重要的是感觉与理解力。对新技术的追踪还算过得去。
  • 技术交流. 参加的交流有一些,但个人的演讲技巧没什么提升,只能说做的一般般。

计划中的几件事情看起来都是很难体现价值的事儿,"如果你觉得有价值,就去做,不必在意别人怎么看",公司老大的这句话给我了不小的启发。除此之外,我还做了哪些事情? 方便说的大致有这么几件:

  • 贝塔咖啡. 我还记得是在元宵节的晚上,白鸦给我打电话,说咖啡馆的成立会议就要开始,要我马上赶到。但是运河边人山人海,没办法立刻赶回去,我说算我默认参加就行了。有些事情,一步步做下来就会成,感谢几位靠谱的朋友,没想到贝塔咖啡真让我们几个捣鼓起来了。在咖啡馆,我结识了更多的朋友,开拓了眼界。谢谢白鸦、思践、坏人、小斌。这件事情还要感谢很多朋友,感谢你们的信任与支持。
  • 一次旅行. 10月份,一个人去了一趟美国。无人同行的一路也是很有趣的。第一次发现在一个完全陌生的环境里,从不同的角度看问题,静静的考虑一些事情。在杭州,很少有这样的场景让自己思考。
  • 一个团队. 从下半年开始,受到召唤回到原来的团队,换了一个角色去做事情。有很大的难度。原来自己越不愿意做的事情要去做,越觉得没有价值的事情要做出价值。这是一次磨练。
  • 一次投资. 尝试着做了一次投资,具体细节不好细说,总之帮助别人也是帮助自己。不过这里的投资不是买什么股票之类的事情,那样的事情实在无趣,不是我要的生活。

这一年下来,痛风对我的困扰小了许多。不过,生活上,自己还是个比较懒惰的人。Blog 文章少了一些,但也有100多篇。

我的 2009 榜单:

  • 年度致敬:花剌子模信使。
  • 年度媒体Twitter,140字的智慧、力量与乐趣。
  • 年度图书:《软件随想录》。有些想法可以做到和别人不一样...
  • 年度运动:翻墙。能够促使积极思考,接近真相。
  • 年度技术:Open Source。开源,那些看似神秘的东西不再封闭,去中心化有了进一步的可能。

2010 年的 TO-DO List (越来越不好写了,稍微写点儿):

  • 做好事情. 以前自己越不屑于做的,其实也是越不容易做好的事情,执行力需要提高;
  • 接点地气. 多琢磨一点客户都需要什么东西,能给客户带去什么,对客户有价值才是自己价值的体现;
  • 学习英语. 英语不过关将来能干点什么呢? 起码得能捣鼓几句口语吧?
  • 集中精力. 收敛一点心神,事情要一件一件做;
  • 拥抱变化. 到三月份,我就在杭州五周年了,生命中最有激情的五年已经用在了电子支付这个领域。或许,有点改变会出现...希望...

寄语2010:或许,你和我都需要收起一点抱怨,多一些忍耐,现在还不是我们展示力量的时候。

最后,祝愿朋友们在新的一年有新的收获。

--EOF--

磁盘的 4K 扇区时代来临

| 4 Comments

Western Digital 在推进一项技术变革,Advanced Format(PDF),将延续近30年的硬盘传统的512字节扇区变更为4K大小。

传统的格式如下图,绿色部分为 ECC (Error Correcting Code)区域。一般来说,每存储1000位(bit)的数据就会有产生一个物理错误,所以必须要有一个可靠的校验机制。这也是 ECC 必不可少的原因。

Legacy Architecture.jpg

每 512 字节用一个 ECC 区,占用 40 字节做错误矫正代码,这在需要存储大数据量的时候,显而易见是比较大的物理空间开销。而将扇区扩大,使用一个相对比较大的 ECC 区也是同样可以达到安全存储的目的。

Advanced  Format Architecture.jpg

如果使用 4K 的扇区,则大约需要 100 个字节的 ECC 区域就行了。空间收益大约是 7-11% 。对于存储工业来说,这是惊人的。当初设计硬盘规格的时候,估计研发者是无法预见到信息如此迅速膨胀的今天的,512 字节已经不太适应现在一个平均 I/O 的大小。

值得注意的是,这个变更更多是在空间上的收益,在性能上的收益还不确定,当然不会变得更差,至于是否有提高,能提高多少,要看具体的场景。另外,也不会提高硬盘的可靠性,每 12.5TB 的数据依然会有一个不可恢复的读错误。(refer) 。4K 扇区其实在数年前就被提出来,只是最近 Western Digital 才真正的推动,估计是因为磁盘容量要保证每年的增长率带来的压力。

使用该技术对或许企业级服务器用户并不会有什么太大的风险,Western Digital 同时也在固件层提供对传统的 512 byte 扇区的模拟方式。另外,也可以下载这个官方校正工具。对于个人用户来说,多少还是有点影响的,尤其是使用克隆软件安装 Windows XP (Windows 5.x )以及更低版本的操作系统的用户可能要注意一下。

4K 是个有趣的数字,还记得 4K偏移量的问题么?

未完,待补充 ...

延伸阅读:

来自淘宝的架构经验

| 9 Comments

日前参加了一场淘宝网架构师黄裳带来的技术分享,在最后他总计了淘宝这几年来的架构经验,这里和大家分享一下:

  • 1、适当放弃一致性
  • 2、备份和隔离解决稳定性问题
  • 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
  • 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
  • 5、产品化管理

在这里不妨对比一下 eBay 的架构经验:

  • 1、 Partition Everything
  • 2、 Asynchrony Everywhere
  • 3、 Automate Everything
  • 4、 Remember Everything Fails
  • 5、 Embrace Inconsistency
  • 6、 Expect (R)evolution
  • 7、 Dependencies Matter
  • 8、 Be Authoritative
  • 9、 Never Enough Data
  • 10、Custom Infrastructure

关于一致性,可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外,强调了"放弃集中的紧耦合处理"的原则。"备份"这里可以理解为"提供可用的副本"。"分割"是说水平拆分。

架构这东西说起来大致原则,其实都是类似的,但是具体如何在一些通用原则上做到运用自如,是很难的事情。前几天我还感慨,很多架构师对与"异步"与"批量处理"所能带来的益处的理解仍然相去甚远。

--EOF--

在 Twitter ( @Fenng )上发布了几条关于 "员工应遵守的Twitter 准则" 的建议。如果你也是 Twitter (或微博) 用户,以下这几条准则或许可以用来参考:

准则一:不要发布不为公众所知的和公司相关的业务数据。如果要引用公司的公开数据,不要加主观的断言。对于关注你的人来说,小道消息并非那么有价值。

准则二:不要匿名攻击公司(包括自己的雇主和竞争对手)。尽管"在互联网上没有人知道你是一条狗",但是,雇主还是很容易知道你是公司里面的哪一位。

准则三:Twitter 上的信息具有不可修改性,被转发后会引来不同的解读。所以发布消息前要衡量是否会对同事或团队造成负面影响。如果回答为"是",不要发布。

准则四:倾听用户的声音,收集用户反馈而不要和用户争辩,如果能够解释,进行必要的解释,但是记住不要推脱责任,尤其不要攻击或是嘲讽用户。

准则五:如果你的主管或同事不能理解或者认可Twitter会对公司带来的价值,向他们解释,同时最好能证明使用 Twitter 并非是在浪费工作时间--用 Twitter 或许比用 IM 更节省时间。

准则六:必要的时候尽可能转发对用户的警示信息,比如"系统维护公告"或"费用调整"等信息应更快更及时的传递给用户。

准则七:团队的内部规划,正在进行的项目及相关实施细节,未经相关负责人允许也尽量不要披露,以免带来各种不可预期的不利影响。

很多人在 Twitter 上发消息,不可避免的会提及自己的雇主。新用户或许意识不到 Twitter 对消息传播的便捷性会带来的破坏力,如果没有一个类似指导原则的话,可能不经意间就会对雇主造成负面干扰,也会给自己带来一定的麻烦。这里的准则或许不能覆盖所有的情况,所以更多的时候要依赖于常识来判断。

如果你在鼓励同事或者朋友来用 Twitter 或者其它微博,要向他(她)说明这些。( 感谢 @hutuworm 同学贡献了准则七)。

--EOF--

技术出版的危机

| 23 Comments

这个话题的缘起是今天我在 Twitter 上感慨了一下关于翻译稿酬的事情。我和两位同事一起翻译 Troubleshooting Oracle Performance 这本书(中文版《Oracle性能诊断艺术》),三个人,六个月时间出头,稿酬大约 15000 RMB 多一点。很多朋友可能会把这当成抱怨而非提醒。

对此,图灵出版社刘江先生回应到,"技术出版的危机。此书首印 3000 册,定价75 元(不低),利润空间仅两三万,如果部分滞销或退书,很容易就赔了。" 而且,"这本书如果按5%给版税,还不如千字稿酬。" 这实际上道出了当前英文 IT 图书引入国内的一个困境。国外出版社版权费用本已经不低(所以博文视点更倾向于做原创图书,别搞错,我说的是武汉的那个博文),加上纸张以及印刷成本的上涨,以及图书销量连年受到网络媒体的冲击,做一本纸版书不亏本已经不容易了,现在据说在国内一本技术图书能做到 5000 册的销量就是不错的成绩了,出版社不得不通过一些不得以的手段控制成本。有一次和蔡学镛聊天,他说台湾现在的 IT 图书出版已经萎缩得不成样子,而大陆因为市场太庞大,所以一时半刻还能撑下去。

李笑来老师曾经质疑过"为什么引进书籍的翻译普遍都很差?",他认为直接原因就是"稿费太低"。对于译者来说,如果只是为了稿费而做技术翻译的的话,绝对是一件收益不大的事情,何况,这事情本身就是一件"瓷器活儿"。翻译得好的话,必然需要投入更大的精力,而译文质量不过关,读者不会饶过你。我相信像余晟这样把翻译当作一种乐趣的人已经凤毛麟角了,而像阮一峰那样偶尔的"头脑发热"一回也是值得我们欣赏的。

国内出版社有的时候自己也扮演杀鸡取卵的事情,据我所知,多数出版社对于翻译时间的限制都比较紧,一本书,一般只给译者 3-6 个月的翻译时间,为了能在既定时间之内完工,要么找更多的的合作者--这会带来翻译风格不统一的问题,译稿质量也难免下降,要么拖延,而拖延,在合同里是写着明确条款的,会根据不同的时间扣除稿费。也就说,如果遇到了不良出版社,而你的合同时间又签得比较不利,那么可能一分钱拿不到。当然,我们这本书总体来说编辑还是比较宽松的,这是非常值得庆幸的一件事。其实话说回来,我认识的几个出版人如果他们转身去做畅销书,至少不会比做 IT 差,或许他们为了理想也在咬牙坚持。

危机,危机,危险之中机遇何在?

--EOF--

MySQL 数据库版本调查与分析

| 8 Comments

针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的,总不会有更大的错误。而如果使用了一个不太合适的版本,或许会后患无穷。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

现阶段收集到的统计数据:

MySQL_version_chart.png

国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本,这个数据是否对你有参考性呢?

--EOF--

Oracle 数据库版本调查与分析

| 6 Comments

据我所知,很多第三方公司给客户实施的时候,选择的 Oracle 版本 都是非常随意的。数据库软件的版本选择多少是有点技术含量在里面的,毕竟数据库这东西要升级并非易事。这里小范围调查一下大家都在用 Oracle RDBMS 的哪个版本,然后把分析数据和大家分享一下。或许会对新手 DBA 有一定的参考价值。

点击访问在线调查 (如果你不能访问这个 URL,需要动动脑子想想为什么)。

统计数据:

Oracle_version_chart.png

出乎我的意料,9.2.0.8 这个版本现在用的人并不是特别多了(没有我预期的多),而10.2.0.4 这个版本现在看起来像是不少用户的选择,这其实也侧面说明着很多用户升级到 11g 还需要一段时间。版本的分散意味着 Oracle 升级的难度的确不小。

不少明显质量不够稳定的版本也有用户在用(比如,10gR1),看来第三方实施的弊端的确不小。Oracle 一般发布的Release 1 其实多少都会有一些问题--否则也不会有后续的 PatchSet 发布了,要知道每个 PatchSet 都是包含几百个 Bug Fix 的。一般来说,在线 OLTP 恐怕少有人用 R1 的版本。

现在收集到大约 100 多份样本,相信还是有点参考价值的。

有的 DBA 对于统计所用的 URL 可访问性有疑问,这侧面验证了我另一个想法:Oracle DBA 对 Web 的熟悉整体上不如 MySQL DBA。

--EOF--

SmugMug 的架构介绍

| 9 Comments

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点,在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建,最初提供面向游戏的视频服务,随后转型为现在的模式。网站流量现在是全球 1800 多,盈利能力自称良好。

在 MySQL Conf 2009 上,SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris),300 多台 4 核(或更多)的服务器(大多是 AMD 的 CPU) ,分散在四个机房,两个运营的人员。SmugMug 充分运用了云计算服务,是 Amazon 的一个大客户,图片和视频总计达到了 PB 级,托管在 Amazon S3 上,图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速,主要是 JavaScript/CSS 等文件的加速,此外,DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中,存储引擎多数用的 InnoDB,数据超过 2TB 的空间,数据库服务器为 4 核或更高配置,内存多达 64GB。缓存方面,用了 Memcached 做加速,有 1TB 的数据在这里面,平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据,减小对 DB 的冲击。数据库设计思路是尽量做垂直分区,没有 Sharding。不过在反范式(denormalized)方面做得比较彻底,不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键,更新或者删除数据也是单行,依赖主键。InnoDB 引擎打了 Percona 的 Patch,并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高,而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方,备份也成问题。ZFS 倒是能满足相关的需求,可惜不支持 Linux(妈的,早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外,对于复制中可能出现的风险,尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后,MySQL 放在 Sun Sushi Toro(Storage 7410,这个东西也支持 SSD ) 上,走 NFSv3 协议。写到这里,发现 SmugMug 的解决方案非常不具有通用行,看起来 Sun 是给了他们不小的硬件优惠,否则一般情况下不会有人这么搞的,用 NFS 协议走数据库,除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走),产品上真的有人跑么?

网站架构的进化,其实也是选定一个方向(比如用开源工具解决),然后一直试错的过程。

--EOF--

Oracle 收购 BEA 之战

| 6 Comments

在 2006 年,Oracle 宣布推出 Unbreakable Linux,同时也暗示了不会对 RedHat 进行收购,人们一直猜测 RedHat 会在 Oracle 待收购名单上,但这个事情到现在也没有发生。另外,在嵌入式 DB 领域也做了收购,将 Sleepycat 收入囊中,Berkeley DB 从此改换门庭。现在,在中国还有一只研发队伍呢。

2007 年底,Oracle 以 33 亿美金的代价收购 Hyperion,在 商业智能 (BI) 领域进一步增强自己的实力。当时在 BI 领域,Oracle 排名第七,Hyperion 第四,尽管收购之后并没有挤入前三名,但至少收获了不少 Hyperion 的客户,从长期看,也是比较划算的生意。

与收购 Hyperion 的 33 亿美金相比,收购 BEA 的 85 亿美元似乎并不太高,因为 BEA 的规模与影响力都是不小,毕竟这是第五大软件公司。可相像的是整个收购过程也遭到了 BEA 创始人的强烈抵抗。其实在 Oracle 收购 PeopleSoft 之前据说就有意向收购 BEA ,只是当时报价让 Oracle 觉得不可接受:37 亿美元。

BEA 由比尔·卡尔曼(Bill Coleman) 、爱德·斯考特(ED Scott)、庄思浩(Alfred Chuang)联合创建,公司名字就来自三人名字的首字母,这是大家都熟悉的典故。或许是因为庄思浩是华人的缘故,中国用户更熟悉他。BEA 是一家神奇的公司,其起家并赖以成名的产品 Tuxedo 与 Weblogic 都是买来的,Tuxedo 从 Novell 手里买来,三人先拿到了 5000 万美元的融资,然后借鸡生蛋,买下了 Tuxedo,到后来这东西恐怕比 Novell 市值还值钱,要说的是,BEA 也真有点石成金的本事,因为抓住了中间件领域的这个前所未有的发展机遇, 从1995 年到 2001 年,六年就成为有史以来以最快速度达到10亿美元年收入的软件公司,但是到了这个阶段之后的几年却停滞不前,无法实现更大的销售规模,产品线的单薄给 BEA 种下了苦果。来自 IBM 、Oracle 的竞争也不断加大,而开源软件 JBoss 的壮大也无形中给了 BEA 不小的压力。

如果 Oracle 能够按照预期收购 JBoss 的话,或许也就不会对 BEA 下手了。不过 2006 年 4 月,消息传来,RedHat 用 3.5 亿美元收购了 JBoss 。如果假想一下当初 BEA 能够收购 JBoss 的话,或许市场格局是另一番景象了,但是 JBoss 没卖给 IBM 、Oracle ,恐怕也不会卖给 BEA,毕竟 JBoss 创建人 Marc Fleury 更愿意保持开源精神。

在 2007 年十月的时候,Oracle 以每股 17 美元的收购请求遭到了拒绝。BEA 的拒绝理由是价格不合适,庄思浩将价格提到了 21 美元。请注意这个说法,这意味着 BEA 对其独立性并非如何看重。Oracle 一计不成,欲擒故纵,说要看看投资人的建议, 这时候,一个重要的投资人卡尔·伊坎(Carl Icahn) ,在这次收购案中起到决定性作用。

卡尔·伊坎这个人在美国号称激进投资者,也有人叫他"企业掠夺者",大家应该熟悉这个他,这人也曾是雅虎的股东之一,给雅虎管理层搞出来不小的压力,整天喊着要炒掉杨致远。卡尔·伊坎的拿手好戏是买入公司部分股票,拿到一部分代理权,然后给董事会施压,逼迫企业卖出,获益后抽身而退。卡尔·伊坎在 BEA 股价在 13 美元的时候大肆买进,后来持有超过 13% 的股份,如果 BEA 卖给 Oracle ,必然股价上涨,从投资人的角度看,也是无可厚非的事情,作为投资人,不会对 BEA 有任何感情。投资人都是魔鬼,这话有几分道理。

买家嫌价格高,卖家嫌价格低,卡尔·伊坎倒是成了中间人,以他为代表的投资人力主卖出,以庄思浩为首的董事会虽说不愿意卖,可一看价格已经谈到可接受的地步,私下里掏出计算器算了半天自己能拿到多少利益,也就都半推半就了,当然这是笔者的演绎而已。这次交易,最大的赢家应该是卡尔·伊坎,据说获利超过 20 亿,当然股东们也都有所收获,要不怎么有人将他叫做股东权益代言人呢。

拿下来 BEA 市场之后,Oracle 在中间件领域稳居第二,相信在经历过艰苦的整合之后,将对 IBM 第一的位置发起再次冲击。

这几篇文章都用标题里都用了"战"字,收购过程看似稀奇之处,暗藏的刀光剑影很难为外人所知。而并购过程中对人员的清洗也是相当的残酷,说是大战,倒也不为过。

接下来谁会是 Oracle 的收购对象? 很多人没想到,居然 Sun 成了 Oracle 的盘中餐。欲知后事如何,且听下回分解。

未完待续...

Oracle 放逐的干将们

| 3 Comments

如同互联网时代 Paypal 黑帮一样,在应用软件领域,Oracle 公司的叛将力量同样超级强大。

可以看一下这个列表:

  • Tom Siebel ,创建 Siebel 公司,2005 年被 Oracle 收购。
  • Mike Fields,曾任销售部总裁,后出走创建 OpenVision 公司,1997 年被 Veritas 收购。
  • Gary Bloom ,曾经的二号人物,后出走担任Veritas 公司CEO,Veritas 2005 年被赛门铁克收购。
  • 克莱格·康威(Craig Conway),前 PeopleSoft CEO ,给 Oracle 收购 PeopleSoft 带来了最大障碍。
  • 马克·贝尼奥夫(Marc Benioff),Salesforce公司创始人、CEO。Salesforce 仍然满身光环。

此外,Ray Lane,前 COO,总裁,现在是 KPCB 投资机构的合伙人。在业界的影响力依然很大(KPCB 投资的 Fortify 非常有意思)。或许,Salesforce 是 Oracle 的一大收购目标,只要危及自己或者是收购之后可以抢占更大市场,那就必然在收购名单上,估计马克·贝尼奥夫必然举起反抗旗帜,尽管拉里也是 Salesfoce 的早期投资人,但早已经被赶出董事会,而且,马克·贝尼奥夫以其人之道,还治其人之身,利用拉里的名义帮自己宣传---当年,拉里也是借着在盖茨前面发言而抛出NC的概念,才在更大范围内广为人知的。

在 Oracle 公司,拉里就是这个王国的君主,谁越靠近他,谁就更可能下台,他的一句以讹传讹的名言是"Everyone else MUST Fail"。企业发展史其实也和政治史没什么本质区别。Oracle 公司的被放逐的干将们倒是充分验证了那条著名的"彼德定律",能力总有不能胜任你的岗位的一天,一旦能力触及天花板,达不到职位的要求,那么在 Oracle 的命运似乎只有一个,滚蛋!不卖力光等着养老那是不可能的。

写这篇文章的时候,Oracle 公司的 2、3 号人物分别是 Charles Phillips 与 Safra Catz 。Safra Catz 投资银行家出身,与拉里关系紧密,但据说缺乏管理经验,而菲利普斯来自摩根斯坦利,加入 Oracle 之前就有针对性的对 Oracle 有过深入的了解。 竞争对手都在猜测目前这两个人究竟谁能接班坐上 Oracle 一把手的位置,还有待于时间的考验,但至少,不会再次出现大清洗的局面了,毕竟这么大的盘子,再折腾恐怕要伤筋动骨。还要给帝国留一个接班人不是?

且说拉里这个人虽说对身边的高管毫不手软,倒是对公司的技术人似乎颇为仁慈。尤其是对自己的老搭档 Bob Miner 评价是相当的不错。拉里当年不是很好的程序员,但是他对技术人员颇为关心,而且自己常常自认为是个程序员,他的确有过当程序员的经历。最近几年,Amdahl 定律渐渐广为人之,但是很少有人知道,当年这个 Amdahl 公司还曾经解雇过他的往事,那时候他在 Amdahl 做程序员。

另外,尽管不懂细节,但他是个很不错的预言家,从主机时代,到客户端/服务器架构时代,到 Internet,Oracle 每次都能提前转身,抢在很好的战略位置。这要完全归功于拉里对商业需求的敏锐预知。尽管他也曾经有过不太靠谱的 NC (网络计算机)的论断,但现在看起来,倒像是一次提前但成功的预言。他也是少数真的懂得销售自己家产品的公司掌舵人,或许这一点和他的好朋友乔布斯有些相像。

未完待续...

成为 Oracle ACE Director

| 18 Comments

昨天上午收到了 Oracle 公司负责人的来信,我的 ACE Director 资格被提名后资格获得最终确认(Oracle ACE Details)。

Oracle 的 ACE 程序目前分为两级,ACE 与 ACE Director。自己被提名为 Oracle ACE 还是 2007 年二月间的事儿,当时作为国内第一批被批准的 ACE ,还是有一点点满足感的。在杭州的前面几年,技术上磨练了很多,但有很多东西不能对外写,错过了更好的扩大影响力的机会。最近两年我在数据库技术上进步倒也不大,中间大量的精力转向 Web 方面的学习与研究,却倒是有些收获。今年下半年接受挑战重新回到支付宝数据库团队,收拢了一下心神,尝试"打怪升级"。

对现在的国内 ACE 的数据做了一个简单的 统计说明。现有的 ACE 我大多也比较熟悉,目前仍有半数活跃在一线。这东西只是个荣誉,最好不要自己把它当作一个负担。个人觉得相比 Oracle ACE ,成为 ACE Director 后最大的好处就是可以免费参加 Oracle 在世界各地的 OpenWorld 会议--只要有时间和精力的话,有好处,当然也意味着更多的责任与承诺。如果 Oracle 和 Sun 的合并能最终圆满完成的话,以后或许也有更多机会介绍一下 MySQL 和 Solaris 方面的技术。分享,意味着收获。

感谢 Oracle 公司 Jack 对我的提名,感谢朋友们!感谢我所效力的支付宝公司给我的机会,对我的容忍以及对我的支持;感谢我现在所在的 DBA 团队,他们中很多低调而务实,醉心于技术,不为名所累,为我所不及也。

--EOF--

Oracle 收购 Siebel 之战

| 4 Comments

从 2005 年开始,Oracle 的发展历史差不多就是其收购史。在收购仁科之前,Oracle 有的收购动作并不多。可圈可点的似乎只有一笔,那就是收购 DEC 的 Rdb ,并且从 Rdb 吸收了 CBO (Cost-Based Optimizer)技术。

直到 2004 年开始,Oracle 开始展开收购战略,这恐怕与 Charles Phillips 在 2003 年加入公司有关。数次收购都是 Phillips 操刀。

在 2005 年除了整合仁科之外,Oracle 还进行了 12 次收购(参考),其中对 Retek 的收购达到 6.3 亿美元,对 i-Flex 的收购金额为 9 亿美元,其它的收购金额没有对外公布。这一年的收购目标大致上都是为了完善自己的在不同行业的解决方案而做。

有两个收购值得一提,一个是针对 Innobase 的收购,Innobase 是开发 MySQL 存储引擎 InnoDB 的公司,而 InnoDB 从现在来看,仍然是 MySQL 最好的存储引擎。Oracle 用极小的代价牵制住 MySQL 的潜在威胁。这是一步妙棋,堪称神来之笔。

另外一个是针对 TimesTen 的收购,这是 Oracle 对实时数据处理的尝试。不过从近几年来发展来看,TimesTen 被用户接受的程度不大,因为 Memcached 或类似开源解决方案对这个产品的冲击太大了。

收购 Siebel 之战

2005 年另一个大手笔收购是 58 亿美元收购 Siebel。如果说,收购仁科之战让 Oracle 抢到了 ERP 领域的资源,收购 Siebel 则是拿下了 CRM 软件市场的大片江山。

Siebel 公司由 Tom Siebel 伙同 Patricia House 在 1993 年创建。Siebel 在发展的过程中拿手好戏也是收购,这可能与 Tom Siebel 的销售出身有关。 要知道,当年他也是埃利森手下得力干将。据说在 Oracle 有句话,叫做谁离拉里最近,谁就最快垮台。做老板的当然不愿意看到下属抢了自己一点风头,拉里尤其如此。只是从后来的事情发展来看,Tom Siebel 和拉里似乎并无多大冤仇。

在收购 PeopleSoft 之后,Oracle 虽说也是 CRM 领域的一个参与者,但是远远排不上前三名,而此时的 Siebel 正在面临市场下滑萎靡不振的局面。与 SAP 的正面争斗没得到什么好处,Salesforce 异军突起也抢走了 Siebel 不少客户(Salesforce 创建人马克·贝尼奥夫也曾是 Oracle 的干将)。待到 Oracle 手持收购大棒前来,Siebel 竟然开城投降。相比之下,人家 克莱格·康威(Craig Conway) 在 PeopleSoft 作为一个打工者尤能抵抗到底,而 Tom Siebel 作为创建人,倒是生生的把自己的孩子送给了人。收购时,Siebel 手里的现金还有 22 个多亿,Oracle 相当于 36 亿拿下了这个竞争对手,可以说是相当的便宜。

Oracle 收购 Siebel 倒不是感受到了来自这家公司的压力,其目的也是要扩大自己的产品解决方案能力而超越 SAP。当然,SAP 的领头羊地位要超越可并非易事。

或许有人问,Oracle 收购这么多大牌厂商,如何消化? Oracle 这样的公司,本质上说,是销售驱动技术的公司,所以,销售线路的整合并非难事,都是买东西而已。至于研发方面,因为收购的厂商大多以 Oracle Database 为基础开发的软件,PeopleSoft、Siebel 都是如此,双方在收购前就已经有所合作,技术上的融合也并非太大难事。当然,这也是我个人的理解。

在 2005 年,Oracle 在产品方面没有什么太大的动作,只是发行了一个免费的 Oracle Database 10g Express Edition (XE)。

未完待续...

Oracle 收购仁科之战

| 2 Comments

最近稍微修订了一下《书写历史的甲骨文--ORACLE公司传奇》,本文可以看作是其续篇。在接下来一段时间,我可能会把 Oracle 这几年的发展历程做个回顾。

收购仁科之战

2004年12月13日,Oracle 公司宣布签订了以每股26.50美元、总计约 103 亿美元的代价收购仁科(PeopleSoft) 的最终协议。历时十八个月的争斗终于尘埃落定。

从 2003年6月宣布的51亿收购金额,到最终的 103 亿美元,Oracle 可以说是付出了血本。这次收购对于 Oracle 公司来说有着深远的意义。且听笔者慢慢道来。

PeopleSoft 公司由大卫·杜菲尔德(Dave Duffield)和 Ken Morris 在 1987 年联合创建,面向企业应用软件,在上世纪 90 年代发展得顺风顺水,到这场收购大战之前,在 ERP 领域已经稳坐第二把交椅。市场第一当然是SAP,而 Oracle 则远远落在后面。现在回过头看,PeopleSoft 当年能够在强敌如林的 ERP 市场有其一席之地,把客户放到第一位,用更好的服务赢得客户的心是PeopleSoft 的竞争法宝,而能做到这一点,与创始人大卫·杜菲尔德的处世之道有直接关系 。

Oracle 觊觎企业应用市场已久,苦于无法抢占更大领地,而在 2003 年,PeopleSoft 完成对 J.D. Edwards 的收购,代价是 15 亿美元,J.D. Edwards 在中型企业及制造、流通和资产密集型行业颇有一手,本来PeopleSoft 在人力资源管理方面已经是绝对的领先者,合并后,在企业应用市场,PeopleSoft 绝对超过 Oracle 处于第二位,这样一来在 ERP 领域也无疑给 SAP 相当的压力,老二当久了,谁都要做老大。话说,这样一来,Oracle 觉得在 ERP 领域要追上第二名都已千难万难,要做第一,更是无望,至于做到世界第一的位置,更是遥不可及了。因而这一领域是 Oracle 必争之地,依赖数据库这一块,虽说赚得盆满钵满,担市场增长毕竟有限,不在企业应用领域有所突破,迟早会在这个强手如林的市场上走下坡路。

如果某个领域不能战胜对手,最好办法就是收购,然后让竞争对手消失。手持大把现金的 Oracle 宣布对 PeopleSoft 展开并购,受到时任 PeopleSoft CEO 克莱格·康威(Craig Conway) 的超强力反对。康威本是 Oracle 的旧臣,曾任高级副总裁,当年也是埃利森身边红人,按理说应该和 Oracle 暗通款曲,竖起白旗才对。其实不然,当初康威离开甲骨文并非功成身退,而是被迫出走。正是出于这样的原因,新仇旧恨,难免要发起强势阻击。仁科公司上下也几乎都反对收购,明摆着一旦收购成功,Oracle 必将大刀挥起进行裁员。当然,这些因素不会有决定性作用,股东以及董事会才是决定这家公司命运的人。

这场收购战的前 16 个月可以说胜负未分,仁科抛出了若干自救的方法,大施"毒丸计划",除了与 Oracle 对薄公堂之外,对客户发起了退款保证计划,大幅度增加福利提高 Oracle 收购成本,甚至和 IBM 结盟力求自保。

眼看着 Oracle 打赢了反垄断的案子,一场大战即将决出胜负,谁料想仁科董事竟然临阵换将,解除了康威的职务,理由是对其继续领导公司的能力失去信心,当时也有传言说董事会对康威不满有其它原因,包括其行事作风独断专行,但这个时候临阵换奖,无疑是头脑发昏。几年后回顾这个情节,真的怀疑是不是 Oracle 用了什么反间计,感觉像在看商业版的赤壁之战。

创始人杜菲尔德重回公司,企图挽救仁科。但这个时候情况已经对 Oracle 有利了,逐利的投资者们临门一脚,竟然多数同意收购,仁科束手投诚。尽管杜菲尔德坚决不妥协,但游戏规则就是如此,自己一手创建的公司从此改换门庭。

收购完成后,Oracle 裁掉了仁科 5000 多名员工,大屠杀,热忱的杜菲尔德自掏腰包建立了一只基金,帮助被裁员工就业,足见老爷子的仁爱之心。

从这次收购开始,Oracle 在企业应用软件市场上一跃成为第二名。这么大手笔、马拉松式的收购的最终成功极大的刺激了大手笔并购的信心与野心,整合仁科(包括J.D. Edwards)这样的大公司也给其带来了大量且可复制的并购管理经验。从这次收购开始,Oracle 收购战正式拉开序幕,其影响直到今天仍未散去。

未完待续...

前一段时间提前读了几章 Joel Spolsky《软件随想录》(More Joel on Software)。这是一本能带来新思维、能改变技术官僚思维惯性的图书。

这本书的内容覆盖了一个 IT 人将要面临的方方面面,不管是否认可书中的观点,不可否认的是 Joel 的见解的确是颇为独到的,有些话语堪称一针见血,这家伙的写作风格也是从不隔靴搔痒。我觉得在这本书中传递给我们的是一种理念--如何把技术效能发挥出来,如何把技术的价值最大化。而 Joel 本人也用自己的亲身经历来证明他所说的并非是做不到的事情,实际上,他创建的 Fog Creek Software 就是一家很酷而且颇为成功的公司。

《软件随想录》不是一本讲技术的图书,但是我相信如果认真读过之后会发现对自己的技术提升会最大。另外,有必要强调的是Joel 对人才的论述,如果要招聘真正牛的技术人员,那么自认为理解技术人员的管理者都应该读一下这本书,某些章节场景或许会让你觉得脸红,哦,原来以前自己所谓的一些招聘手段是多么的低级而低效,我们有太多的理念需要转变

今天晚上还给 Yupoo 的刘平阳推荐了这本书。个人觉得,无论是一线技术人员还是 IT 公司的的管理者,或是创业团队的成员,都应该读一下这本书,相信能给你很多启迪。

八卦一下:Joel Spolsky 给自己起了一个中文名字:周思博,不知道他知道在中国有这么多粉丝不?

好久没有读到这么有趣的书了,也要感谢译者 阮一峰 的辛苦工作,他也是个有趣的家伙。

--EOF--

数据分片(Sharding)设计问题一例

| 5 Comments

Question:假设一家 C2C 网站,数据库中某表存储买卖双方交易的数据信息,对于一条交易来说,买卖双方数据具有一定程度的耦合性,比如卖家的状态更新对应买家的状态也会更新,对于一个中大规模的电子商务网站,架构师在设计中如何考虑数据分片的问题(假定该表随着数据的膨胀必须拆分)?

Answer:对于一个中大规模的电子商务网站,随着网站的不断发展,其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站,由于交易记录不容易进行水平的数据分割,因此对于这样的应用处理要再进行细分:

  • 买卖双方交易的信息,具备较高的时效性,即交易全部完成后就不会再有更新,因此这部分数据可以与正在交易中的数据区分开来,并可以单独分表,定时归纳。具体的做法可以采用水平分割的数据分片技术,比如可以根据用户号码段范围进行切片,把不同的群体划分到不同的 DB 上,这样可以很好的进行横向水平扩展(Scale Out)。它可以很好的突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。
  • 对于正在交易中的数据,主要根据时间进行分表。如果分的更细,则可以分三个表,但是这样在事务保证方面则要复杂很多,不建议这样做。

这个问答是《程序员》杂志架构师接龙栏目的第一期的内容。提问者是我,回答者是腾讯研发总监王速瑜先生。其实我抛出问题后当时还真不知道接龙的是哪位,只是知道会是百度或是腾讯的朋友来回答,当然我也对这两家的数据处理方式都是比较感兴趣的。最后刊登的内容或许让很多人觉得不过瘾 -- 如果能更详细一点就好了(毕竟还有其他问题呢)。不过能够引发思考就好,这也是这个栏目的初衷吧。

对这个问题或许可以补充的是,切分或许还算是容易的事情,但是切分后用户对数据的查询多少是有点麻烦。一旦要查询历史交易信息,则必须考虑跨多个数据分片获取数据并排序的问题。交易中的数据与交易完成的数据是否做切分,是有必要根据自己的实际情况仔细衡量。要注意如对交易中的活动数据单独存放的一个表中,则还是不可避免的要产生 I/O 热点问题,而且,这个表实际上变成了一个数据队列(新的瓶颈)--新生成的交易进来,完成的交易删除或归档。这样产生的双重 I/O 压力不容忽视。

当然,这个问题的前提限制了回答的发挥,其实在设计初期也可以考虑买家信息与卖家信息分别放入不同的表中,然后对这两种属性的表再进行切分,这也是可选的途径,这样的开销是每笔交易会重复存储一条记录,而记录的变化也要在两个表中更新。对数据的一致性维护有一定的挑战。这似乎是个只带来额外开销的办法?其实也有益处--索引的设计起码会更简单一些,而用户对交易记录的定制查询也会更加方便。

数据分片(或 Sharding) 现在几乎是每个网站架构师都必须要考虑的基础问题。多数情况下,分片的粒度和方式取决于业务,慢慢地快变成可意会不可言说的话题了,你有什么建议或意见不妨留言说说。

--EOF--

为了避免误导,对于数据量不大的站点,首选如何利用好 Cache 吧,分片只是手段,不是目的。

OpenDNS 的统计(Stats)服务的实现

| 9 Comments

对国内互联网用户来说,OpenDNS.com 这个服务在技术圈子里还是有些知名度的,当然这要归功于国内电信服务商对域名的无耻劫持行为。

OpenDNS 的员工 Richard Crowley 在 Velocity 2009 上和与会者分享了关于 OpenDNS Stats 服务的实现。当时的数据是每天有 140 亿次的 DNS 查询,而现在从公开的数据看,每天已经超过 180 亿次查询。这个 PPT 的内容就是讲 OpenDNS 是如何处理并统计这些查询记录的。

主要的策略分两步,第一步,根据网段切数据;第二步,聚合与存储。体现到 DB 层面是给每个网段单独分配一个表,尽可能的让表更小,让主键更小。

选择合适的方式存储域名。如果表使用 auto_increment 字段做主键是不太合适的做法--不同的引擎都有或多或少的锁问题,OpenDNS 采用域名的 SHA1 摘要值用来做域名的主键(SHA1 是20个字节,倒也不算浪费空间)。用了两台机器,每台 48GB 左右的存储空间,另外通过跨在 8 台机器上总共 28GB 的 Memcached 来避免对数据库的读操作。

对于聚合数据的进程会产生内存溢出的问题,采取的办法是清空内存,重启进程(而不是释放内存)的思路。利用了 supervise 这个小工具来做到。这地方其实值得商榷。

开始曾发现 80% 的 I/O 等待表的打开与关闭上。通过 Strace 发现存在大量的 open() 与 close() 调用。通过設置 ulimit -n 600000 解决(关于 ulimit 参数的意义参考。这意味着 OpenDNS 用了大约 60 万个表(网段)!(?) 这的确是比较极端的做法。

而在 DB 存储引擎的选择开始用了 MyISAM ,也是不合适的,通过迁移到 InnoDB 速度得到了很大提升。这似乎是缺乏评估与规划的表现,或许 OpenDNS 在这方面并非十分擅长。

OpenDNS.jpg
(Copyright by Richard Crowley )

上图从右向左看,查询日志通过 rsync 同步到 Stage 1 的服务器上(位于旧金山),根据查询到的域名把查询日志映射为中间文件,然后把数据文件同步到 Stage 2 的服务器,启动聚合进程把中间文件读入,修剪(Pruning)进程把拼装好的 SQL 语句写入 DB。整个步骤其实暗合 MapReduce 的思路。虽然不是严格的 MapReduce 实现。

听说国内提供类似服务的 DNSPod 因为上次的暴风长老事件受到了广泛瞩目,前不久成立了公司旨在专门提供智能 DNS 服务。不知道每天查询量有多大。[Updated: 见楼下 DNSPod 站长的回复 "DNSPod请求数每天20来个亿" ]

--EOF--

几句题外话:因为逐渐远离一线技术环境,为保持对技术的兴趣,每天多读一些 PPT 也是有乐趣的事情,或许一年没有敲多少条命令,但是看的 PPT 恐怕没有几个人比我多。看到一些还算有趣的 PPT 就做点笔记和大家分享。或许对人有用呢。

Updated:Google 开始提供 DNS 了。Google Public DNS

还可以参考一下这篇:OpenDNS MySQL abuses,另外,Richard Crowley 已经在2010 年2月份从 OpenDNS 离职...

再跟 Flickr 学习网站运维经验

| 8 Comments
Image representing Flickr as depicted in Crunc...

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长:

  • 24 TB 的 MySQL 数据
  • 每秒钟 MySQL 有 3.2 万次写操作
  • 每秒钟 MySQL 有 12万次读操作
  • 图片容量 6 PB
  • 每天要用掉 10TB 存储
  • 超过 15000 个服务监控点

在 2004 年的时候 ,Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick,我还以为是因为版权问题,现在知道这样做是因为速度,换用 GraphicsMagick 处理速度提升了 15%,而 ImageMagick 功能尽管强大,但都是 Flickr 用不到的功能。如无必要,勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化,Flickr 充分利用硬件本身的更新换代带来的好处,曾经用 18 台新机器替换掉原来的 67 台 Web 服务器,用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多,而整理处理能力并没有削弱。我们总说摩尔定律,但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政,不要只冲着人下手,动手"裁"掉机器,也会省钱嘛...

Flickr 技术团队随着网站的快速发展并没有增加大量人手,个人生产力的产出是相当的高。如何做到的呢?给出了四个非常有趣的原则:

  • 使得机器自动构建 (Teach machines to build themselves)
  • 使得机器自监控(Teach machines to watch themselves)
  • 使得机器自修复(Teach machines to fix themselves)
  • 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上,Flickr 使用了 OpsCodePuppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思,除了内部的 IRC 用于讨论之外,还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化,并且,重要的是,将这些信息弄到搜索引擎里面 ... "信息查找",是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵,重新接管 Yupoo 网站,要知道 Flickr 仍然是最有影响力的网站之一,所以,有理由期待 Yupoo 团队的精彩。

--EOF--

关于这篇归档

This page is an archive of entries from December 2009 listed from newest to oldest.

November 2009 is the previous archive.

January 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.