April 2009 Archives

按：在几个月前，我在Twitter上发起了一个试验性的计划：每日推荐一位推友计划 。最初是因为 Blogkid 友情帮我做了点事情，所以友情推荐了他一下，继而忽发奇想，何不以此为契机，做个实验呢? 说干就干。倒没想到一发不可收拾。基本上一段时间下来，每个被推荐人的订阅数都有了不小的增长，而且继而又能从他们那里多看到一些好玩的内容，甚至自己的 followers 也有了很大增长(将近3000 )，互惠，多赢。

有趣的是，网易有篇新闻，引用的图中心节点居然是我...

废话说完，简单说说说一下我推荐原则（逐渐摸索中清晰化的）：

• Twitter 背后的那个人在某个领域要有一定影响力或者有趣或是 Twitter 内容比较有价值。
• 订阅人数(followers)不超过 500 个才可能会加入推荐候选列表。如果订阅者少于100，基本发现很难形成良性互动，有的新用户就会意兴阑珊--毕竟自言自语不是很有意思的事情。而一旦超过200，就基本到了一个比较良性的循环了。对于超过500的,基本上不用推荐也会自然增长，边界效益不高。
• 非商业行为。同时避免侵犯隐私，每个人的介绍以网络可以搜索到的为准。
• 在每个工作日进行推荐，一般在下午 15:00 左右，这个时间也是公司下午茶时间，基本不影响工作。

如果要跟踪这个推荐计划，请 follow 我(@Fenng ). 第一季推荐的人见下面列表(按照时间排序)。介绍语基本上都是我拟就的，如果有不合适之处，那肯定是我没说好。

• @Blogkid
  张磊,Geek,创建过 Niupu.com 。目前即将学业有成,准备赴京陪伴女友,顺便工作,风闻海内外各互联网公司纷纷竞聘云云...
• @izlmichael
  张亮, Apple4us 创建人, 《环球企业家》杂志记者, 他的很多文章让我受益颇深.
• @wingoffire
  王皓(aka.南瓜), 虾米音乐网(xiami.com)创建人, 前摇滚乐队乐手, 阿里黑帮之一 .
• @zhaozexin
  赵泽欣(aka. 小马), Taobao UED 前端技术专家(相当嘀牛). 也是 JobsDigg 热心用户. 补充:最新译作《JavaScript语言精粹》已经上市...
• @taiwen
  霍泰稳, InfoQ 中文站主编(搞 Java 的都知道 InfoQ!)...
• @Tinyfool
  郝培强, 银杏泰克科技有限公司共同创始人, Geek ,乐高积木爱好者.身材有我两个壮,技术至少也是我的 200% .
• @virushuo
  霍炬, 银杏泰克科技有限公司共同创始人. 提供搜索引擎技术服务解决方案, Geek , 双截棍爱好者. 技术至少也是我的200% .
• @zhengyun
  郑昀, 玩聚网创建人, 语义应用探索者.玩聚 SR: http://SR.ju690.com/ 挺好玩. 他最近怎么和月光打起来了? 止戈...
• @CloudWu
  云风[说明: 标签中遗漏, 但对他不需要多介绍. ]
• @Livid
  Livid. [说明: 标签中遗漏, 但对他也不需要多介绍. ]
• @robbinfan
  范凯, JavaEye创建人, 在数个技术领域(Java/Ruby/Web...) 都是牛人. 对 SNS的系列大作让人耳目一新.
• @nowazhu
  Nowa, Web 前端技术开发高手,来自前阿里妈妈技术团队(现淘宝).苹果产品超级粉丝.iPhone 专业破解达人.
• @gofeeling
  刘平阳, 前 Yupoo! 创始人.现在重新出发,潜心做新项目中... 另：通过虾米网点首歌送给平阳：刘欢的《从头再来》...
• @flycondor
  耿新跃, 豆瓣技术总监,负责豆瓣开发过程方面内容.也是 DB 技术高人.他也是豆瓣员工中少数在 Twitter 上活跃的用户...
• @twijean
  陈俊,《东方企业家》高级记者[现在变化了]. 上海 5G 活动组织者之一. 他的 blog 地址: http://www.jeanchen.net/
• @digitalboy
  张扬(@digitalboy ) Geek 商店创建人, 出售各种稀奇古怪的小玩意儿 http://geekcook.blogspot.com/
• @hongqn
  洪强宁, 豆瓣首席架构师,负责豆瓣技术架构方面内容..他将在即将举行的 QCon(北京)的会议上分享豆瓣的架构经验...
• @sky000
  简朝阳, 来自阿里B2B的DBA团队,小伙子不止在 Oracle 方面经验丰富,还对 MySQL 有深入研究, 他的 MySQL 新书《MySQL 性能调优与架构设计》即将上市.
• @JunChen
  吴隽辰, 途牛网设计总监.资深驴友.设计师,Blogger,UCDChina发起人. 值得一提的是,发型也超酷无比,堪称非主牛代表.
• @hellodba
  张瑞, 看 ID 就知道是个 DBA , 来自阿里B2B的DBA团队. 比我资深多了,讲究生活品质,物质、精神层次两手抓.[补充:最近一篇关于数据中心的大作传遍江湖.]
• @accesine
  田春峰,早期关注搜索技术,搜房的,现在对 SEO 很专注,他的Blog 名叫做"我想去桂林",不知道他是否已经有时间去过桂林了.
• @LinuxToy
  LinuxToy.org, 原因只有一个－－LinuxToy.org 这个站点内容的确不错.
• @erning
  张尔宁, 曾是 eBay CDC 资深架构师,安居客创建人之一.其实, erning (二宁)就是一宁的弟弟,兄弟俩都热心公益事业.
• @wangpei
  王佩, 当年互联网四大杀手之一: 红心杀手. 他现在的活动据点：http://www.baibanbao.net/ . 我和他同在杭州,居然去年在广州网志年会才见面一次.王佩缠着绷带参加年会,给我印象最深了,哈.
• @mranti
  安替, 自由撰稿人,新闻研究人. 纵横周刊创建人. 去年中文网志年会主题演讲就是他.其实关于他是谁可能不需要介绍了.
• @aleksoft
  Alex.Mou博士,做啥网(zuosa.com)的创建人. Twitter 上也有不少做啥的用户,使用有问题,给他拍砖！
• @yudunde
  于敦德,途牛网(tuniu.com)创建人之一. 要旅游,找途牛.老于也是技术人,当年分析 LiveJournal 架构的文章流传颇广.
• @hzsijian
  思践, 虾米网创始人之一, COO. 是阿里创业黑帮代表人物. 在电子商务圈非常有影响力.
• @mijia
  米嘉,Firefox 中国的工程师. Geek. 如果你是 Firefox 的粉丝,或许从他那里能看到很多小道消息.
• @belltoy
  赵钟秋, 出色的 LAMP 技术人员,沟通能力值得称赞.对"Web技术和开源技术感兴趣,有强烈的热情", 刚刚友情帮 JobsDigg 解决了一个技术问题. 另请移步访问：http://belltoy.cn/
• @dreamwords
  孟岩, 此孟岩不是CSDN那个,而是财帮子创建人之一. RoR 高手.曾供职于 Sun、微软.
• @gongjun
  梁公军,鲜果网(xianguo.com)创始人.坚持将 RSS 普及到底的家伙.
• @turen
  谭晓生, Myspace 中国区CTO,前阿里巴巴-雅虎中国技术研发部总监.
• @Alipay
  支付宝(@Alipay). 考虑到今天日子比较特殊(注：04.01).所以推荐一个非官方的虚拟角色吧.当然 @Alipay 背后也是实在的人(不是机器人).有些我不方便说的,会在这里体现.
• @dashhuang
  黄一孟, VeryCD.com 的创始人啦,年轻有为.Twitter 上的绝大部分朋友都用过他们的服务了吧? 不多介绍,等 dash 同学自己推消息吧.
• @turingbook
  刘江, 图灵图书主编.是IT出版界的奇才之一（另一位下回介绍),目光如炬.当年在电力引入的那批书至今仍有余威,更别说近年来的图灵系列了.
• @yurii_yusheng
  余晟，前抓虾主程，现银杏泰克主程，奥地利经济学派著名著作《权力与市场》译者，《精通正则表达式》译者，即将出版的《技术领导之路》译者.
• @guojiayue
  郭家悦, 美空网( http://moko.cc/ ) 联合创始人. 美空网的美女密度是国内所有网站最高的.如果要美空注册账户,可以follow @guojiayue 同学,给他提建议/意见.
• @yining
  张一宁, Blogger, 标准Geek, 公益事业积极参与者. @erning 他哥. 另请访问他的Blog：http://www.yining.org/ 近期更新不多.
• @xiaolai
  李笑来, 原新东方托福阅读老师,现艾德睿智国际教育咨询合伙人,乐于分享,博文很赞(http://www.xiaolai.net/) 时间管理著作《把时间当作朋友》即将出版
• @lancelot23
  且听枫吟, 比较陌生? 他就是Leica中文摄影杂志(http://www.leica.org.cn/)的运营者啦.他也是一位资深媒体人,现在某媒体集团做Online Marketing
• @bryanzk
  郑柯,《程序员》杂志 高级编辑. InfoQ 也有不少翻译的技术文章出自他的手笔. 要给《程序员》投稿找他再合适不过.
• @lusoo
  程立, 支付宝当之无愧的首席架构师(没有之一).
• @xmpp
  杨卫华, 英文名Tim Yang, 在新浪搞UC的技术架构工作,对XMPP(Jabber)及开放IM架构经验非常丰富 他的Blog: http://timyang.net/ (后端技术）一定要看
• @ningoo
  宁海元,淘宝网资深DBA, Oracle、MySQL、OS 方面功力深厚（以后猎头都别来挖我了,挖他吧),他的Blog: http://ningoo.net/
• @huairen
  坏人,工作过"北上广深杭",被戏称"交友行业之父",曾任职"世纪佳缘""百合网""珍爱网""嫁我网"产品部,参与多次改版,后上海"篱笆网"产品部.现淘宝UED创新产品.交互和营销,产品项目方面号称略懂.

最后再附加两个好玩的：

• @BetaCafe
  贝塔咖啡馆...即将开业
• @JobsDigg
  帮找工作 ...我的实验性项目

按照我的本地记录,这是目前推荐过的列表. 感谢网友 Ivan Chen(@fireshort)，另请参见他整理了列表，不过我不赞同他的那个帖子的题目。

敬请期待第二季...

现在连岳也开始现身Twitter(@LianYue)，有理由相信他会成为中文Twitter之王。原因? 不说你也知道。

Updated: 你可以批量跟随: TweepML 。(使用前请注意安全性。)

继续贴出 Troubleshooting Oracle Performance 一书第二章《关键概念》的翻译稿的部分节录。昨天贴出第一章的部分内容，收到不少朋友的反馈，坦诚的讲，第一章多半是通用知识，和 DB 相关的信息并不是很多，这次再看看第二章的(借口归借口，问题还是要改正)。必须要说明的是，此书翻译并非兄弟我一人之力。译者包括：童家旺、胡怡文、冯大辉(出版顺序)，还有海外华人朱一和青年才俊张磊两位的劳动成果。如果留言有问题，请在 Twitter 上给我反馈也可： @Fenng

(此书中文名字还未敲定)

绑定变量

绑定变量通过两种方式来影响应用。第一，从开发的角度看，它使得开发或者变得简单，或者是变得更加困难（或更精确地讲，需要更多或更少地编码）。既然这样，具体的效果就取决于用来执行SQL语句的应用程序接口（Application Programming Interface, API）。例如，如果是使用PL/SQL来编码，使用绑定变量来执行就会更加简单。另一方面，如果是使用JDBC（Java Data Base Connectivity）来开发，不使用绑定变量来执行SQL语句则会更加简单。第二，从性能的角度看，绑定变量既有优势也有劣势。

注意：你将会在下面的内容中看到一些执行计划。第6章将会介绍如何获取并解释执行计划。如果有什么不清楚的话，可以考虑稍后返回本章。

2.5.1 优势

绑定变量的优势是可以在库缓存中共享游标，这样就可以避免硬解析以及与之相关的额外开销。下面内容是运行脚本bind_variables.sql的结果，它展示了三个INSERT语句由于使用绑定变量而共享了库缓存中的同一个游标的情形。

SQL代码, 略.

可是，也有一些情况下，即使使用绑定变量也会产生多个子游标。下面的例子就展示了这种情况。注意，INSERT语句与前面例子中的完全一样。只有对应的VARCHAR2变量的最大长度发生了变化（从32变成33了）。

SQL代码, 略.

之所以会创建新的子游标(子游标1)，是因为相对于最初的3个INSERT语句来讲，第4个INSERT语句的执行环境发生了变化。 这个不匹配可以通过查询视图 v$sql_shared_cursor 来得到确认，是绑定变量的原因。

SQL代码, 略.

这是由于数据库引擎应用了绑定变量分级（graduation）。这个功能的目的是为了最小化子游标的数量，它是根据绑定变量的长短将绑定变量（各个大小不同）分为四个级别。在32个字节以内被分在第一个级别，33到128个字节的被分在第二个级别，129到2000个字节的被分在第三个级别，其余的大于2000个字节的被分在第四个级别。NUMBER类型的绑定变量被分在它的最大长度22个字节上的级别上。从下面的例子可以看到，视图v$sql_bind_metadata显示了级别的最大长度。注意，即使在子游标1的变量长度只有33的时候，也是使用最大长度为128的级别。

SQL代码, 略.

系统不要求每次生成子游标的时候都生成一个新的执行计划。新的执行计划是否与另一个子游标使用的执行计划一致，也依赖于绑定变量的值。这将在下面的内容中进行介绍。

2.5.2 劣势

在WHERE从句中使用绑定变量的缺点是会有一些至关重要的信息对查询优化器不可见。事实上，对查询优化器来讲，使用直接文本要比使用绑定变量来的更好。使用直接文本可以提高成本估算的准确性。当检查一个值是否在可用数值范围以外（也就是，小于存储在这个字段的最小值，或者大于最大值）或者是否利用到直方图（histogram）时，就更是这样了。为了展示的需要，我们准备了一个含有1000条记录的表，它的字段id的值在1（最小值）到1000（最大值）之间。

SQL代码, 略.

如果一个用户查询id小于990的所有记录，查询优化器知道（根据对象的统计信息）有差不多99％的记录被筛选。因此，它会选择使用基于全表扫描的执行计划。同时请注意，估算出的基数（执行计划中Rows字段的信息）与查询语句实际返回的记录数是否相符。

SQL代码, 略.

当另外一个用户查询id小于10的所有记录时，查询优化器知道只有大约1％的记录会被选中。因此，它会选择使用基于索引扫描的执行计划。在这个例子中，也请注意估算的准确与否。

SQL代码, 略.

只要是使用到绑定变量，查询优化器都会忽略它们的具体值。从而，前面例子中的准确的估算就不太可能会出现。为了解决这个问题，Oracle9i中引入了一个被称为绑定变量窥测（bind variable peeking）的功能。

警告：绑定变量窥测不支持随Oracle9i一起发布的JDBC 瘦驱动（JDBC thin driver）。这个限制在Metalink的注解273635.1中有记载。

绑定变量窥测的概念是比较简单的。在物理优化阶段，查询优化器会窥测绑定变量的值，将它作为文本来使用。这种方法的问题是它生成的执行计划会依赖第一次生成执行计划时所提供的值。下面这个基于脚本bind_variable_peeking.sql的例子展示了这种情形。注意，第一次优化是使用值990来执行的。结果，查询优化器就选择了全表扫描。由于游标是共享的，因此是这个选择影响了第二次使用10作为条件的查询语句。

当然，如同在下面的例子中那样，如果第一个执行计划替换成使用值10来执行，查询优化器就会选择一个基于索引扫描的执行计划－然后，就会再一次发生这两条查询语句上。注意，为了避免共享前面例子中的游标，这些语句是使用小写字母来写的。

有必要强调，只要游标还保存在库缓存中并且可以被共享，就可以被重用。不管与它相关的执行计划的效率如何，这种事情都会发生。

为了解决这个问题，Oracle11g中引入了一个称为扩展的游标共享（extended cursor sharing，也称为适应性游标共享，adaptive cursor sharing）的新功能。它的目的是在重用一个已经存在的但是会导致执行效率低下的游标时能够自动进行识别。通过查看前面例子中使用的SQL语句在v$sql中的内容，可用来帮助我们理解这个特性是如何工作的。要到Oracle11g中v$sql视图中才有下面这些字段：

• 是否绑定敏感（is_bind_sensitive）：不仅指出是否使用绑定变量窥测来生成执行计划，而且指出这个执行计划是否依赖于窥测到的值。如果是，这个字段会被设置为Y，否则会被设置为N。
• 是否绑定可知（is_bind_aware）：表明游标是否使用了扩展的游标共享。如果是，这个字段会被设置为Y，如果不是，这个字段会被设置为N。如果是设置为N，这个游标将被废弃，不再可用。
• 是否可共享（is_shareable）：表明游标能否被共享。如果可以，这个字段会被设置为Y，否则，会被设置为N。如果被设置为N，这个游标将被废弃，不再可用。

在下面的例子中，游标是可共享的并且是绑定变量敏感的，但是没有使用扩展的游标共享：

SQL代码, 略.

当游标对这个绑定变量赋不同的值执行多次以后，有趣的事情发生了。在使用值10和990执行了几次以后，视图v$sql提供的信息发生了变化。注意，0号游标不再可共享，并且产生了两个新的使用了扩展的游标共享的子游标。

查看与这个游标关联的执行计划，你可能会发现，其中一个新的子游标会使用基于全表扫描的执行计划，而同时另一个会使用基于索引扫描的执行计划：

SQL代码, 略.

有以下几个新的动态性能视图可用来进一步分析生成这两个游标的原因：v$sql_cs_statistics、 v$sql_cs_selectivity和v$sql_cs_histogram。第一个视图说明是否使用了窥测（peeking）以及对应于每个游标的相关执行统计信息。根据下面的输出，基本可以确认，对于同一个执行语句，游标1处理的记录数高于游标2处理的记录数。因此，查询优化器在一种情况下选择了全表扫描，而在另一种情况下却选择了索引扫描。

SQL代码, 略.

视图v$sql_cs_selectivity显示与每个游标的每个选择条件相关的选择性范围。事实上，数据库引擎不会为每一个绑定变量值创建一个新的游标。而是将具有同样选择性的并有可能导致生成同一个执行计划的绑定变量值组合在一起（以生成一个新的游标）。

SQL代码, 略.

总的来讲，为了提高执查询优化器生成高效的执行计划的可能性，最好不要使用绑定变量。绑定变量有时候可能有用。遗憾的是，生成的执行计划是否高效只能看运气如何。唯一的例外是，Oracle数据库11g中的新的扩展的游标共享会自动识别这个问题。

2.5.3 最佳实践

使用任何特性都需要权衡利弊得失。有些情况下，这是比较容易决定的。例如，在不涉及到Where从句（如普通的插入语句）的时候，就没理由不使用绑定变量。另一方面，在柱状图信息对查询优化器有很大影响的情况下，最好不要使用绑定变量。否则，可能会在进行绑定变量窥视的时候遇到较大负面风险。不过，还有以下两个关键案例可供参考：

• SQL语句处理少量数据：每逢被处理的数据量很少的时候，解析时间有可能会接近甚至高于执行时间。在这种情况下，使用绑定变量就经常是一种较优选择。特别是在SQL语句将会频繁执行的情况下。数据资料系统（data entry system，常常也称之为OLTP系统）是典型的使用这种SQL语句的系统。
• SQL语句处理大量数据：在大量数据被处理的情况下，解析时间常常比执行时间要少好几个数量级。在这种情况下，使用绑定变量对于总的响应时间（response time）几乎没有影响，但是它也会提高查询优化器生成低效的执行计划的风险。因此不要使用绑定变量。批量任务处理（batch job）、报表生成或者运用OLAP工具的数据仓库（data warehouse）环境是使用这种SQL的典型场景。

--EOF--

贴出Troubleshooting Oracle Performance 一书第一章《性能问题》的翻译稿的部分节录(初稿)。排版有点差。请多提意见。翻译的过程得到了很多朋友的大力协助，最后我会单独一一致谢!

(此书中文名字还未敲定)

如何解决性能问题？

简单而言，一个应用的目标是为使用它的业务提供便利。所以，优化一个应用性能的理由就是要最大化这种便利。这并不意味着性能的最大化，而是找到成本与性能之间的最佳平衡点。实际上，优化任务包括的努力总要从你期望获得的好处得到补偿。这意味着从商业的角度看，性能优化不总是有意义的。

业务视角 vs. 系统视角

优化一个应用的性能是为了给一个业务提供好处。所以当你着手接近(approaching)性能问题的时候，必须先理解业务问题和需求。然后才跳入应用的细节。图1-2演示了一个具有业务视角的人（一个用户）和一个具有系统视角的人（一个工程师）之间的典型不同。

图 1-2. 不同的观察者有不同的角度

认识到两种视角之间的因果关系是重要的，虽然结果必须从业务视角来识别，其原因必须从系统视角来确定。所以，如果你不想去诊断不存在或不相干的问题（强迫调优失调症），理解从业务视角看问题就变得更重要 -- 即使这需要更多精细的工作。

把问题分类

对付性能问题的第一步是要从业务视角确定它们并为每个问题设定一个优先级和目标。如图1-3所示。

从业务视角来确定问题 > 设定每个问题的优先级 > 设定每个问题的优化目标

业务问题不能通过观察系统统计发现，而必须从业务视角来确定。如果代之以监控服务等级协议，很明显，可以从没有满足期望的操作来确定性能问题。否则，除了询问用户或者负责的人之外没有其他可能性。这种讨论将涉及一系列操作。例如：注册一个新用户，运行一个报告或加载一批可能很慢的数据。

你知道哪些是有问题的操作，就该给他们排个优先级了。考虑类似这样的问题：如果我们只能处理5个问题，应该如何做呢？当然，最好是全部解决它们。但有时候时间或预算是有限的。此外，缺乏必要措施的情况下，不可能解决不同问题的相互冲突。要强调的是在设定优先级时，当前的性能可能是不相干的。例如，如果你处理一整套报告，不一定最慢的那个具有最高的优先级。可能最快的那个也是执行最频繁的那个，因此有可能具有最高优先级并需要首先优化。再说一次，是业务需求在驱动你。

对每项操作，你应当为优化设定一个可量度的目标。诸如"当创建用户按钮按下以后，处理时间最多2秒"。如果性能需求甚至服务等级协议可以得到，可能目标已经知道了。否则，再强调一次，必须考虑业务需求去确定目标。注意，没有目标就不知道何时停止研究一个更好的解决方案。换言之，优化可以是无止境的。记住，努力永远要和获利取得平衡。

解决问题

诊断整个系统比诊断一个单独的组件要复杂得多。因此，任何可能的时候，你应当一次只解决一个问题，简单地从问题列表按照优先级从高到低的顺序解决。

对每个问题，如图1-4所示，必须回答3个问题：

• 时间花在哪里了？首先，你必须确定时间花在哪里了。例如，如果一个特定操作用时10秒，你必须找到这10秒里绝大部分花在哪个模块或组件。

• 时间是如何耗费的？一旦你知道时间花在哪里了，你必须找到时间是如何耗费的。例如，你发现应用用了4.2秒在CPU上，0.4秒做I/O操作，5.1秒等待另一个组件发出队列出队消息。
• 如何减少时间耗费？最后，才是找出怎样使操作更快的时候。要做到这个，重要的是聚焦到处理中最大时间消费的部分。例如，如果I/O操作占整个处理时间的4%，那么即使它很慢也没必要对他进行调整。

时间花在哪里了？ > 时间是如何耗费的？ > 如何减少时间耗费？ 

要注意由于副作用的益处，有时候修复一个特定问题的同时也会修复另一个问题。当然，相反的情况也会发生。采取的措施可能引入新的问题。所以，很有必要认真考虑修复过程中可能引起的所有副作用。显然，所有改变在应用到生产环境前都要经过仔细测试。

--EOF--

真是一种嘲讽，就在刚才，收到一封广告信，标题是 "Sun为企业发展提供更多动力"

对于 IT 产业来说，这是最好的时代，这是最坏的时代。Sun 要做 Web 2.0 中的这个 Dot 没做成，74 亿美金把自己卖掉了。

尽管我不是 Sun 的粉丝，还是感觉不太痛快。这次收购意味着又有若干产品有可能被打入冷宫。而大家比较关心的 MySQL 可谓命运不济，被 Sun 折腾一年多，在开源社区里面一点好没讨到，这回在 Oracle 新的产品线里面如何定位呢? will be an addition to Oracle's existing suite of database products... 当然，InnoDB 这回和 MySQL 算是破镜重圆了。是否有其它变数，比如被原 MySQL 团队赎身出来? 难!

对于 Oracle 来说，这次自己终于有了硬件(SPARC)和操作系统(Solaris)这两块王牌，其实 Oracle 和 Sun 算是多年的合作伙伴了(超过 25 年)，相信整合起来可能问题不大。这次收购比较失败的可能就是 IBM 了，Oracle 这次给了竞争对手 IBM 以更大的压力。难道蓝色巨人出不起这个价格麽? 还是觉得足够鸡肋? Sun 手里的 Java 技术对于 IBM 的小型机是个很好的补充，想不通。再过几年，这可能就是 IBM 犯过的最大错误。

不痛快的除了 IBM ，恐怕还有 RedHat。不过别着急，没准儿哪天 Oracle 也把 RedHat 也一并收了，我相信 RedHat 手里的 JBoss 至少让 Oracle 眼馋不已。有 JBoss 在，其他中间件就不可能赚到更多。

一切皆有可能。其他事情不好确定，但有件事情还是能基本肯定，拉里·埃里森大叔这回又有机会体验一下世界首富的滋味了...

--EOF--

延伸阅读：

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好(除非内存小)--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

--EOF--

• 好的业务模式(产品) + 很好的技术 = 大赚钱
• 好的业务模式(产品) + 能用的技术 = 也赚钱
• 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
• 差的业务模式(产品) + 差的技术 = 自己浪费资源

很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。

不过，eBay 这次的PPT 总算还是有点更新的。

1）数据分片(Partition Everything)

说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文：开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒进。

从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。

2）异步处理(Asynchrony Everywhere)

其实对于任何网站来说，过度追求"同步"化设计还是比较糟糕的做法。以用户能观察到的数据为视角进行设计，中间可以最大限度用异步来完成。

eBay 的举例的模式有两个，一个是事件队列(Event Queue)，另一个是信息分发(Message Multicast)。前者基本上是个生产者--消费者的模型。后者主要用在搜索的架构上。

注意到图中的消息总线，这才是 eBay 整个架构中的动脉，估计轻易不会批露技术细节

3）自动化(Automate Everything)

这里的自动化举了两个例子，一个是针对运维方面的，另外举了关于机器学习的东西，这是演讲者 Randy Shoup 的强项所在。

eBay 的自动化，在一年前的另一篇文章里可以窥测一点东西。只是这篇文章当初没有被更多人重视，参见：eclipse at eBay。可以看到 eBay 能在自动化方面做得这么好(起码敢出来讲)不是一朝一夕之功。

4）故障检测与回溯(Remember Everything Fails)

更好的失败检测机制: 监控每天超过 2TB 的日志，根据日志中的相关事件得出判断或者预警。这个看起来简单，但实现起来还是需要一点技巧和策略的，重要的是，需要不断根据结果的反馈去改进。

完美回滚: 任何服务都通过服务配置中的标记来识别，无痛回滚。(个人感觉这个非常有难度，尤其是升级的时候)

优雅降级(Graceful Degradation)：能够相对容易的对应用标记"Marks down（下线）"

5）拥抱不一致性(Embrace Inconsistency)

举了 CAP 原则，程立将其形象描述为帽子戏法，非常准确。说起一致性，自从 Amazon CTO Werner Vogels的 Eventually Consistent 一出，基本上不需要再废话了，这就是事务处理的九阴真经，大家回家慢慢参详好了。

eBay 也有自己的绝对准则: 绝对没有分布式事务(两阶段提交), 通过状态机与操作顺序最小化不一致性，通过异步事件(消息总线?)达到最终一致性。

--EOF--

另外小道消息：Amazon CTO Werner Vogels 可能会参加六月份在杭州举办的侠客行大会。

以前的老帖子：eBay 的Scalability最佳实践

这次 QCon (北京)会议网站架构案例分析这个 Track ，虽然话题不多，但课程设计时候考虑覆盖的面还是比较广的。作为视频网站代表，优酷带来了一场包含不少实战经验的技术分享。邱丹(优酷网开发副总裁，核心架构师)可能公司的事情比较忙，一直到第二天中午才赶到会场。还半开玩笑说，'怎么这么多人，还以为是小型的会议呢'...

缓存

缓存黄金原则：让数据更靠近 CPU。

CPU-->CPU 一级缓存-->二级缓存-->内存-->硬盘-->LAN-->WAN

讲到了 Youku 自己的内部项目，针对大文件缓存的。目前开源软件中，Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。Youku 不用内存做缓存(避免内存拷贝，避免内存锁)。值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的。

数据库

优酷对数据库 Sharding 做了不少尝试，而且实现效果应该不错。DB 读写分离上有比较丰富的经验。

为了提升数据库 I/O 能力，启用了 SSD 。6 块 SSD 做 RAID 。我在 Twitter 上发了一则 Youku 使用了 SSD 的消息，很多朋友以为是用来存储视频文件，这里需要澄清一下--只是局部使用。

网络吞吐量优化

这是我强烈要求加上来的一节内容。网络优化，视频网站肯定都做得不错。这一节的关键词是 "事件(event)驱动"，令人深刻的一句话是 "ePoll 推动当今 Web" ，的确，现在很多比较热的 Web 组件都是以 ePoll 为卖点。

延伸阅读: The C10K problem (我一直想翻译一下这个页面，苦于腾不出时间) 与 Libevent 如果做互联网，遇到扩展性问题，这两个信息点还是避不过去的。

最后一个例子是针对 Memcached 的 Agent 的，这一点和 Facebook 架构中的 Memcached 处理可以对照来看。

演讲结束的时候，有人提问优酷对视频缓存上有什么特别的地方? 回答是一个大视频可能分成多个小文件，这样缓冲的时候就效果更好一点--(并行啦)...其实访问优酷的确比土豆快那么一点点。

--EOF--

PPT 过几天 InfoQ 中文站会发布。稍安勿躁。

在 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--

这次的 QCon 会议，《豆瓣网技术架构的发展历程》这个议题差不多是最受关注的。洪强宁在演讲开始告诫大家期望值不要太高，我还是相信不会有人觉得失望的。

先说几句题外话，整个演讲听下来，我们会发现豆瓣在发展的过程中也是有点弯路，这些是一个网站发展过程中的宝贵财富，能把自己有周折的地方大大方方的拿出来，是难能可贵的事情。尽管豆瓣批露了很多架构细节出来，也不会(也不可能)有哪个公司一拿到这些东西，就能照猫画虎再做一个豆瓣并且超过豆瓣。从某种程度上来说这体现了豆瓣同学们的气度，这是令国内大多数公司汗颜的。很多公司只愿索取，而不愿奉献哪怕一点点出来，用这样封闭的心态对待技术其实是小家子气，守财奴的思维。技术只有为更多人所用才是大道。

议论说完，再来叙述。写点对豆瓣架构的体会。戏法人人会变，各有巧妙不同。有些东西大家都在用(Nginx)，但是有人的用得好，有人用了比不用还差。所以，需要逐渐总结，改进。学习别人的架构设计，不是要照搬，而是借鉴其思想。

技术的选择

一直以来，豆瓣在技术上都给人很前卫的感觉，看起来好像什么新用什么，其实是不是的，他们一直是"用已掌握的技术解决问题"，现有的东西如果够用，那么就没必要一定迁移到新的上面去，而转换往往是为了解决当前问题。另外，换用新的东西，要有足够的驾驭能力，从演讲中得知，豆瓣曾有几次在临上线前发现基础库的Bug(比如 Libmemcached 的一致性哈希相关的Bug)，技术团队能在第一时间有进行修复并且提交给开源社区。否则的话，就变成了一种错误决策了。

磁盘转速

小话题。如果可能，直接买 15000 转的磁盘好了。10000 转的磁盘可能省钱，但这东西部署了之后几乎就不太可能升级。所以，如果是初创公司，我的建议就是买高速磁盘，因为业务如果发展快了的话，先前对机器的定位也可能发生变化。

杜绝远程 I/O

在普通的 TCP/IP 网络的环境下，不要进行远程数据写入操作。跨网络操作的延时看似没什么大不了的，但一旦达到临界点就回天乏术。这个事情基本是不撞南墙不回头，有的技术人员总要亲身体验一把才肯罢休。

持续保持 URL 友好风格

演讲中有多次提到一致性 URL ，其实体现了豆瓣对 URL Rewrite 的重视，结构调整，或者应用程序变化的时候，URL 最好做到"用户友好"的。这算是"软技术"，但是应该加以最大的重视。

数据库复制延迟问题

对于 MySQL 复制的环境，如果Slave 上有读取操作，那么有些情况下可能因为 Master 和 Slave 节点数据不一致对用户造成困惑。如果从一致性的角度上考虑，其实也不复杂:，只需要对"知道数据发生了变化的用户"提供一致性就行了(基本上就是发起变更的用户)，不知道数据发生变化的用户对数据的不一致有一定的"容忍程度"，当然说着简单，实现起来还是需要技巧和精巧的。

大量小文件同步问题：Merkle tree

关于大量小文件的同步问题，很多上了规模的网站都会遇到，如果设计得不好或者是比较偷懒，用传统的办法(比如 rsync 之类的老模式)很容易触发问题，也浪费资源。DoubanFS 是用 Merkle tree(Hash Tree)的方式进行数据同步的。对这个问题的具体描述可以参见《大量小文件的实时同步方案》。Merkle Tree 是个很精巧的思路，ZFS 在用(refer)，Amazon Dynamo 系统也在用。

不会一会儿又有人留言说：我们早就采用这个思路了...... 我这里预先来句回答：拜托，你早点共享啊?

--EOF--

完整的 PPT 过几天 InfoQ 中文站会发布，我这里就不掠美了。

来北京参加 QCon 的技术会议。QCon 的门票居然都卖光了，不容易。刚才还有位同学问我来买张票。

这几天短暂计划：滞留几天。空下来可能找几家 Web 2.0 公司参观学习一下或者去奇遇花园咖啡馆消磨时间。

北京居然比杭州还热，从机场过来就出了一身汗，而且干燥挺惊人的，以前每次来不觉得，这次一下飞机都觉得呛喉咙，空气质量并不咋样。看来举办了一次奥运会也好不到什么地方去。

--EOF--

• 明天如果有空我会在现场 Twitter 直播 :)
• 在 9 号星光现场音乐厅有苏阳演唱会，有人一起去么?

前段时间因为写稿的缘故回顾了一下过去几年来的 SQL 标准的事儿。如果不考虑太久远的 SQL/92(SQL2) 的话，那么自从 SQL:99 之后，SQL 标准一共发布了三版。

SQL:2003

这个版本针对 SQL:99 的一些问题进行了改进，支持 XML，支持 Window 函数、Merge 语句等。对于 Merge 语句，很多从事数据仓库的朋友耳熟能详了。这个东西也是先有了事实标准然后纳入规范的。且说 SQL:99 发布后，各大数据库厂商纷纷宣布新的版本中对该标准的支持，这是他们一贯的姿态。

SQL:2006

继续增强 XML方面的特性。这个版本发布后，几乎没什么动静。增强 XML 对数据处理的能力。实际上，至少在现在应用中发现 XML 多少让大家都高估了它，也或许背后有商业力量驱动吧。有几家公司不是要凭借 XML DB 超越对手来着?

SQL:2008

去年发布的。几乎没看到有技术圈子的人讨论这个事情。这个版本其实还是和 XML 较劲。从SQL:99 到 SQL:2008，可以看到标准修订的周期越来越短，多少也反映了对技术的需求变化之快。

--EOF--