January 2008 Archives

前几天在 Blog 里提到答应了 Piner（陈吉平) 要给他的新书《构建 Oracle 高可用环境--企业级高可用数据库架构、实战与经验总结》写篇书评。书是拿到了多日了，断断续续再看，一直没看完。

首先恭喜一下 Piner 的新书终于顺利出版，写一部书本是一件不容易的事情，也一本有质量的书就更难上加难了。也恭喜一下博文视点顺利拿下这本书，装帧质量的确不错，相信读者也会对此满意。记得好几年前 Piner 最早在 CSDN 论坛数据库版灌水，签名经常写着"弱水三千，只取一瓢饮"，灌水地移师 ITPub 后没多久我就注意到了这个家伙。那个时候他就经常发一些总结的很好的技术文档(可见写作能力早早就开始培养了)，新书的出版也是他厚积薄发的体现。

做 DBA 久了，有时也难免动一动写书的念头，可面对 Thomas Kyte 、Lewis 这些大师的书，真有些"眼前有书写不得，大师图书在上头"的感觉。但是《构建 Oracle 高可用环境》没有作无意义的重复，就内容上，可以说是独辟蹊径。有些章节堪称填补了 Oracle 技术图书的空白，比如第 10 章的 "高可用环境下数据迁移" 与第 16 章的"高可用环境监控架构设计" 都是前人所未能阐述的东西，对很多 DBA 来说，似乎是隔了一层窗户纸，可实际上，能够有功力捅破窗户纸可不是容易的事情，没有足够的经验写不出来，只有经验而没有总览全局怕是也写不出来。

身为国内最大电子商务网站的首席 DBA，"经验总结" 毫无疑问会让无数 DBA 心痒，到底淘宝的数据库是怎么维护的? (我就时不时的去偷师借鉴经验)。不只是 DBA 应该看这本书，架构师、技术经理都应该是这本书的读者。通过本书由点及面的阐述，能够树立一个以 DB 为核心的架构观，进一步理解企业信息技术体系，增强实践技能。

我会向 DBA 推荐本书(建议春节期间就买本回家看)。《构建 Oracle 高可用环境》将会是 2008 年中文图书市场比较重要的一本数据库类图书。

(最后挑个小毛病：建议批量数据更新的处理策略能够用 "Bulk Collect"方法，Piner 似乎一直不喜欢这么用。)

--EOF--

“跃迁”这个词借鉴自阿西莫夫的机器人系列故事。类似一个世界向另一个世界的瞬间移动，具体怎么移动的，阿西莫夫一语带过，类似古龙的小李飞刀，如何之快你也不知道--扯远了，扯回来：最近越来越觉得(我实在有些后知后觉)桌面工具与客户端工具被淘汰的趋势已经不可逆转，用户习惯慢慢转向并会习惯 Web 应用。

举几个例子：

• Outlook --> Gmail
• Booksmarks-->del.icio.us
• FeedDemon / GreatNews-->Google Reader
• MS Office --> Zoho Suite / Google Docs
• Media Player --> YouTube

这个名单还可以拉得很长。把计算能力和存储能力交给“大计算机”来做，而浏览器(或提供同样功能的软件)作为 "元(Meta)工具" 将会长时间存在。

用户习惯一旦发生改变，再想逆转怕是不现实的事情。上大学的时候，没事的时候就去电脑城买 D 版软件光盘，那时候信息的载体很大一部分是通过 CD 走的，现在，还会有大学生去买电脑城的盗版软件么? 或许有，但会极少。单机版游戏盛行的时候，网络游戏虽然也有(如 Mud)，但毕竟是小众，现在呢，守着单机版游戏的玩家怕是太少了。这个“迁移”一旦发生，几乎就不可能有回头路。当初有多少 FeedDemon D 版的死忠用户，可现在习惯了 Google Reader 的我们即使 FeedDemon 免费了也不愿意再次使用它了。

记得有段时间在讨论 Web OS ，可能是长时间没见到比较接近的产品，大家的兴趣又减退了。或许将来，世界只需要五台超级计算机。一旦我们把习惯切换过去，还会再回来么?

微软的 Live.Com 没什么起色，而 Google 在这方面已经走的很远了。绕来绕去，好像又绕到 SaaS 上去了，但其实我没扯那么远。

--EOF--

昨天在家看了《盲井》，就像期待的那样沉重。今天想想，回味出来两个字："回家“。

互联网传来的消息也只有两个字：雪灾。根深蒂固的家的传统观念...一年一度的人口大迁徙偏偏碰上这五十年(百年)不遇的雪灾...年，这个中国人永远摆脱不了的节日啊

上苍保佑! 上苍保佑回家的人们

--EOF--

又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的 阿华（沈志华）同学，了解了一些小道消息。

作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：

带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

该架构图给出了很好的概览(点击可以查看在 Yupoo！ 上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了"

对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。

名次解释：

• YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
• YPFS--Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。

我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo! 今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。

对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。

非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

--EOF--

前提: OpenSSH 配置完毕。并且，目标端到源端通过 SSH 登录无需提示密码验证. (参见我以前的也是关于 rsync 的废话)

下载 AIX 5L Expansion Pack CD 中的 rsync，这个版本稍微有点低。其实也足够了，不过如果和更高版本混用的话，会报告另外一个错误：

sync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) ...

在 AIX 上 rsync 需要依赖 Popt--A C library for parsing command line parameters，通过 rpm 命令安装即可. 现在的 AIX 系统默认应该就有安装 rpm （AIX-rpm) 工具包的.

在维基百科上 有 对 rsync 算法的介绍。简单的理解是这么回事：待传送的文件被分成若干定长的文件段，然后对每个文件段做个 "Rolling Checksum"，加上一个强 MD4 校验码, 传送这些信息给接收方, 接收方查找本地类似文件--定长的每个文件段, 对比 Rolling Checksum 与 MD4, 然后传送差异(Delta)数据.

rsync 1996 年才被搞出来，最初是用来对付在低速网络连接上传送差异化文件的。

我一直比较好奇的是 Oracle 的 Data Guard 用什么算法保证所有的归档能无差错传送到远地(?)。

--EOF--

这几天存储行业比较大的一个新闻是 EMC 宣布在高端 Symmetrix 产品支持 SSD (固态盘, Solid State Drive)，注意是基于闪存(FLASH)的固态盘。不到半年前，和一些存储厂商的朋友提及 SSD 仍有人不知为何物，现在似乎一夜之间 SSD 到处都是了。EMC 虽身为市场的领先者，也敢于吃螃蟹，来者不善。

EMC 这次采用的 SSD 是 STEC 公司 Zeus-IOPS 产品线的产品。这一型号号称随机读操作的 IOPS 能达到 52000 个，采用 SLC (single-layer cell )，写也可以达到 17000 个 IOPS。只从这个数字看，单块 SSD 的性能是机械硬盘的 30 倍还多。在可靠性上，SETC 据说实现了 ECC 机制.

现有的机械硬盘的虽说在单位容量上还在不停的增加，但是性能基本上是到了瓶颈，即使用于高端存储的高速硬盘，IOPS 的能力基本上也就是 150 个左右。而 SSD 单块就能提供几万个 IOPS ，且耗电量极小，平均故障间隔时间(MTBF)又是普通硬盘的10倍之多, 这对以期得到高 IOPS 的 DBA 来说, 简直是银弹。

但是(什么都怕这个"但是")，但是 SSD 的有它固有的缺点。其中一个就是可擦写次数(这个在几个新闻稿里面可算是一笔带过的)，尤其是基于 Flash 的 SSD。传统磁盘虽然有它的缺陷，但是可擦写次数几乎是无限次的。

听听来自竞争对手的声音或许也能让我们多点心眼。HDS 的 CTO Hu Yoshida 在 Blog 上撰文，提出了他对 SSD 能否被市场接受的三点疑问：

• 1) 价格因素：SSD 大约是普通磁盘驱动器的 30 倍.
• 2) 磁盘供应商多数是初创公司，主流磁盘生产厂家并没有上阵呢.
• 3) Flash SSD 可擦写次数有限.

如果说前两条只是竞争对手的 FUD 的话，那么最后一条还是会令 EMC 销售很头疼，如何让客户消除这个疑虑是有些难度的。STEC 官方的技术参数是可擦写次数能达到 200 万次。这样看的话，在高端存储上用 SSD 还是有比较合适的应用场景：在 EMC 提倡的 “智能分层存储” 前提下由 SSD 提供密集读的操作能力。

--EOF--

有句俗话说的好，”当你手里拿着锤子的时候，整个世界都成了钉子“，数据库理论专家 David DeWitt 也闹这毛病，他的这篇 MapReduce: A major step backwards 差不多快成最近几天技术圈子的一个笑料了，连久不更新的汪海都来了兴致写了一篇评论。

有的时候我怀疑是不是国外这些学院派的教授也和国内这些老学究差不多，固步自封? 估计 David DeWitt 被一群实践派的后生小子当作笑话消遣肯定很恼火，期待他后续的回击。其实话说回来，RDBMS 理论这么多年来基本上也就是搞些"老树成精"的研究，真正转入实际应用的理论怕是真不多，VLDB、BI 方面貌似繁荣，其实也就那么回事。就拿 Oracle 来说（汪海说了：千万不要对自己不熟悉的东西妄加评论），在这几年的 VLDB Endowment 上，发布的论文寥寥。实际在产品中起用的技术就更少了。

我前几天推荐的几个 Windows 小工具的 PathSync 一直没有汉化版。前几天收到网友 我爱新软 的邮件，他也是这个软件的忠实用户，并且动手做了一个汉化版。

相信这个软件有了汉化版后能更普及一些。我个人谢谢这位热心的朋友。他的网志：我爱新软 专门介绍一些软件工具的信息。

--EOF--

最开始看到和菜头对这本书的评论。看书名还以为是一本偏学术的书，看评论似乎又不是，心痒难当。偏偏在 Amazon.cn 订书之后，快递来公司送了几次，我都因加完班在家睡觉而不在，直到最后终于前台 MM 替我代收，算是好书多磨。

陈老先生一生经历独特，且身为名医，上至达官贵人、下至贩夫走卒，三教九流皆有接触；况且本人又有记日记的好习惯，所以回忆起来就好似一部老式黑白摄像机，替大家还原了一下银元时代的老上海生活。旧时的生活习惯、典故娓娓道来，非常过瘾。八卦一下，陈老先生还曾是老版《上海滩》特别顾问。

或许过去我们都太轻视传统了，读罢此书算是补了一课。最大的一个感慨是，民国时代是中华民族最差的一个时代，也是最好的时代。

这半年来看过的书里面，何兆武的《上学记》和这本《银元时代生活史》有的一比。接下来计划把《抗战时代生活史》买来看完。

--EOF--

看完了《耳朵大有福》，心里有点堵得慌。导演张猛，查了一下，好像曾经是赵本山的小品编剧。范伟主演，演技真的不错，范伟怎么也算是草根出身，东北那块的生活小细节都刻画的很到位。整部电影虽然有些笑料在里面，总体却是很严肃。

东北小县城，每天都会发生类似的故事。国企职工下岗、卧病不起的妻子、修了一半的建筑工地、烂俗的流行歌曲、电脑算命、贯穿早晚的新闻联播、永远挤满了未成年人的网吧、网络游戏、老头老太太组成的传销队伍、手巧的蹬三轮的、修车人、擦鞋妇女、欺软怕硬的小混混、公园力摆摊的骗子，草台班子老板、闹离婚的女儿、二人转、没出息的儿子...终日麻将的弟弟、无人照管的老父亲......东北人生活的所有元素，几乎都能看到。

人活到五十岁，活不明白也要明白。即使过去有点光荣，也在也只能用来回味了。要不还能怎么样呢? 在这片土地上，现在就是这样的生活啊。

一部好电影其实只需要记录下真实的生活就足够了。如果把主演换个非职业演员，这就是东北版的《三峡好人》，英文名字倒也是很贴切的--Still Life。

--EOF--

一直以为新浪是国内几家门户网站中技术比较糙的一家(也可能是太低调了)，这应该是我比较无知的偏见，无意冒犯。看到这位新浪技术人员介绍的开源软件项目: NCache 与 Memcachedb 。挺欣赏他们这种国内环境下比较少见的分享精神。为他们喝彩！

• NCache = Nginx Cache
• Memcachedb = Memcached + Berkeley DB

这两个软件，应该都是从实际应用需求上得来的，可以说是"设计以致用"，不是纯用于研究的，而设计思路很有些 "Mashup"。我没有实际使用经验，不知 Memcachedb 和 Tugela Cache 二者有何差别。我对 Memcachedb 这个项目倒是比较感兴趣的，把 Cache 和 DB 有效结合起来，消除 DB 单点 I/O 承受的应用压力...而且，实现方便且廉价...十分美好的前景。

期待能有更多类似的项目涌现出来。国内的 Web 2.0 站点软件设计人员也可以借鉴一下。

--EOF--

更新：【很多人估计从来不仔细看文章的具体内容。我这篇文章里可看不出来 "对Memcachedb的思想比较推崇"的, TBStore 也未必就有多超前，内存 + DB 八百年前就有人想到了。只是赞扬一下 Sina 团队的精神而已，如果只是攀比牛B，去和Google 、eBay 比比好了】

更新2： Memcachedb 现在在有了官方站点：http://memcachedb.org/

今天不知道是什么日子，又一个震撼业界的消息，大胃王 Oracle 收购 BEA。

正在走下坡路的 BEA 算是卖出了合适的价钱。原来自己估价的 82 亿美元，倒是误差不大。不过我倒是真的看不出 Oracle 收购 BEA 有什么必要，应用服务器市场也就那么大嘛，收购 RedHat 不是更物美价廉么? 前几天我写帖子预测 Oracle 会出现财务危机，看来只能算是信口胡说了啊。

照这样下去，应用软件市场也就是能剩下几个巨头了，IBM、微软、Oracle，扳着手指头就能算过来了，对了，还有 SAP，前几天刚用 68 亿美元收购了 BO。说白了，还是有钱公司的财富游戏。

--EOF--

2008 年 IT 业第一个大收购: Sun 宣布 10 亿美元收购 MySQL AB, 8 亿现金加上 2 亿股票，MySQL 把自己卖掉了。

MySQL 最近几年一直喊着要 IPO 来着，谁知道突然甩手把自己卖掉了。难道 MySQL 就这么大一点志向么? 还是投资者急于套现? "LAMP" 的 "M" 以后是 Sun 家的了，Sun 能否把 “LAMP" 变成 "SAMP" ? S-Solaris，这恐怕只能是个假设而已, Solaris 在开放上慢了一步，这一步可就被 Linux 甩的太远了。

话说回来, Sun 这几年可真的是日薄西山。这笔买卖恐怕也是“驴粪蛋--表面光”，真正能带来多少收益恐怕天知道，要知道 MySQL 07 年的收入恐怕也就是 5 千万上下。Sun 一向是活雷锋, Java 造福了这么多公司，就自己不赚钱。希望能继续发扬该精神，让 MySQL 能够继续为 Web 2.0 公司提供数据支撑，要知道现在的 Web 2.0 公司至少有 9 成都在大量使用 MySQL 啊。哦，难不成 Sun 是看中了这块的硬件市场?

Sun 会继续保持 MySQL 开源，这是毫无疑问的。但我也相信众多 MySQL 用户这下子要考虑一下使用策略了。

MengYan 提醒我说 "别忘了 Sun 要做 .com 中的那个 Dot "，的确，当年的 .com 大潮中，Sun 风头无两；这么一说，Sun 的意图就比较明显了，这回Sun 要做 Web 2.0 中的这个 Dot.

--EOF--

豆瓣最近发布新功能有些"疯狂"，所以服务器也有新的部署。看到阿北同学在豆瓣广播里说：

豆瓣的第二台应用服务器终于投入了使用。Hongqn 忙了一晚上就完成了部署。第一台服务器支撑到 500 万动态PV/天，服务 On Demand 即时分布式部署......

500 万 PV , 还是动态 PV, 是个很惊人的数字。因为，如果都能达到一台机器支撑 500 万，那么国内稍有点规模的网站(就说动态 PV 上亿的吧)，只需要 20 台 Web 服务器就够了。事实上，即使比较强调技术的网站怕也要上百台 Web 服务器的规模。

我们知道豆瓣用 Lighttpd 做 Web 服务器。 从侦测到的数据看，目前线上有两个版本。

$ curl -I http://www.douban.com
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.15

另外一个版本：

$ curl -I http://www.douban.com/people/ahbei/
HTTP/1.1 200 OK
.....(无关内容略)
Server: lighttpd/1.4.18

其实豆瓣服务器还有个更为惊人的性能数字。从这个 Powered by Lighttpd 的列表来看，豆瓣在一台 Gentoo 服务器上的记录是 1200 万/天的点击量。这应该是动、静态页面混合情况下的吧。

有同事对这个数据有些好奇，问我到底豆瓣是用啥做的服务器，其实这个问题我也问过阿北，他们就是自己攒的 PC 服务器，然后把性能发挥到极致。阿北也表示过，即使现在豆瓣流量激增个十倍啥的性能也不会是问题。这也是从起始就考虑扩展性的收益吧。

这里这位老兄用 七个 Mongrels 实例(也是一台Server)跑了 55 万 PV (thanks Robin 纠正) 就蛮自豪的，所以豆瓣的一台跑了"500 万动态 PV" 的确非常惊人。

Updated 2008-1-17 0:57:09

阿北留言了。主要是上面的有的数据还是旧的:

Lighty 网站上的数字很久没有去更新了。现在豆瓣的web服务器(lighttpd)每天估计2500万 Hits, 高峰时间大约1000 req/s (这里说的是主要输出HTML/CSS/JS和小图片的一台前端。大图片有另外的web服务器)。
我在广播里说500万PV/天的是应用服务器，就是lighty和mysql之间跑python的那台。现在豆瓣大多数PV来自注册用户，每个页面都需要几到十几种类的动态数据。
现在的服务器只是单片双核的opteron。换4核的话，应该能到一台1000万PV/ 天。

友情提醒，留言很精彩，敬请查看。不过在这个 Blog 上留言的确用户体验很糟糕(我也很烦),相信本周末能得到解决。

承蒙朋友们的支持，前一段时间的拉票效果立杆见影，最后获得了ITPub 的 2007 最佳版主奖。说也惭愧，自打来杭州后并且沉迷写 Blog 后在 ITpub 上参与的技术讨论真的不如以前那么多了，好在自己现在多少也还写点 Oracle 相关的技术帖子。

原来参会行程都计划好了。不巧的是准备赴北京参加会议（2008 中国 IT 技术精英年会 ) 前夕，因为公司项目发布，结果没去成。看到老杨都在 Blog 上念叨我了，以前同事登峰和 Quest 于大姐也电话来问我为啥没去，感谢这么多朋友记得我。

会议地点在九华山庄，参加的朋友都在那里泡了温泉。这大冬天的，泡泡温泉倒也的确是一大乐事。ITPub 这么多年人气渐长，看朋友们写的一些会议感受，也能觉察得出举办的挺成功的。一个技术论坛能最终运营成有这么大的声势，除了 IT168 在后面的支持，也和 Tigerfish 的苦心经营分不开吧。想想自己这几年也在论坛上获益量多，认识了很多朋友，真的要感谢一下。

今天在家里昏睡了一天，下午起来后去了一趟淘宝办公室，把 ITpub 颁发的奖品拿回来了。一个奖杯和一台三星的打印机。帅哥小薛千里迢迢从北京把这些东西背了回来(打印机很沉），很辛苦，看来这顿饭是定要请他吃了。

也抢了一本 Piner 的新书，第一感觉印刷质量很出色，已经答应了要给他写篇书评 :)

--EOF--

早晨回家，天还蒙蒙亮。走到东方威尼斯附近的时候，忽然发现卖煎饼的夫妻俩已经准备好摊子了。今天有点冷，夫妻俩偎依在那里，看着好温馨。旁边的东方威尼斯也算是杭州的著名消费场所了，即使是清晨，也停了不少不错的汽车。

每天早晨上班的时候，都看到好多人在那里排队买煎饼，自己因为痛风不能多吃"油炸"性质的东西，也不愿意等太久，还真没吃过几次他们的东西。Laura 上班走的比我早，经常买来吃。告诉我好几件有趣的事情。

夫妻俩一人一个摊子，有的时候人多，哪些偶尔路过的人就会随机选一个摊子。可能以为这夫妻俩是竞争关系，所以"选择"后经常是有一队人特别多，后来的人还偏偏选人多的队伍等(估计是以为人多的那个煎饼好吃)，这时候夫妻俩面前人多的那个就会小声的说：排另一个吧，我们是一家的。

有一段时间，连续几天都没看到他们的煎饼摊。后来总算出来了，Laura 趁他们不忙的时候问了一下，原来是被城管把车子收走了。“交了好几百才把车子要回来。"，那个妻子叹口气说。

--EOF--

连续二十几个小时的加班，挺消耗体力的。除了吃了一顿比较饱的晚餐外，还喝了三罐红牛、两杯咖啡、一壶茶、半瓶可乐、吃了若干个小饺子/小包子、两块巧克力、一个苹果、若干块牛扎糖...现在还是饿

这一年算下来大约至少十几个通宵，真是一场艰辛的旅程。

--EOF--

最近做项目稍有点累，每到睡前睡不着，只得看一会儿小说转移一下注意力，缓冲一下压力。用这些空隙时间把《德川家康》的第二部《崛起三河》也看完了。看第一部的时候还是比较费力的，毕竟历史背景一点不熟悉，第二本总算熟悉了一些(毕竟咱也查了好几回维基百科嘛)。

竹千代 --> 松平元信 --> 松平元康 --> 松平家康，这套 13 部又厚又长的大作到了第二本总算出现了”家康“这个名字，战国时代的日本人名字可真挺多的，贵圈够乱，这明显不利于 SEO 嘛。哪像咱们三国时候的人名，如曹操曹孟德，一个用到底，个人品牌。当然，这或多或少说明了日本就那么个弹丸之地，而一个大名的领地基本上也就是相当于一个村或者乡那么大，改了名街头巷尾吼几嗓子大家也就知道了。

说每个大名的地盘小，用数字或许能说明，号称当时最有实力进京、领有俊河、远江、三河的今川义元伐织田信长，出动了多少兵力? 两万五千! 自己的主力仅有五千， 而信长连五千都没，最后用急就章似的集合的千把人偷袭居然得手。这一仗今川一方死了武将 500 多，兵士 2500，这个比例着实让我费解，难道日本人在那个时代就已经掌握了管理学的方法：一个管理者最多只带几个兵，否则沟通上有问题...

相比家康的隐忍, 织田信长狂放更令人神往，的确是那个时代的一个怪才。不过胜今川义元的整个过程在这本书里会让人产生"误打误撞"之感，历史就是充满了巧合，短短几个时辰胜负已分。下一部信长"天下布武”，相信会有更多笔墨给描述信长。

织田信长最喜欢唱的这段《敦盛》词我找到了好几个版本：

人生五十年，
如梦亦如幻。
有生斯有死，
壮士何所憾?

人间五十年，跟下天比起来，如梦似幻，人生一度得生，焉有长生不灭者？

人生五十年(载)，
如梦亦如幻。
有生斯有死，
壮士复何憾

--EOF--

手边有 AIX 以及 Linux 环境，df 算是我用的频率较高的系统命令了。这个小小的命令在不同的环境中差别还是很大的。比如 "-v" 这个参数，在 AIX 上可以配合 -k -m -g 等参数显示可读性更强的信息, Linux 上只是为了兼容 System V 的 df 命令而保留 "-v"。在 Linux 上类似的命令 是 “-B” ，可以接 k 、m、g 等. 如 df -Bg 按照 GB 显示。如果同时维护这样的混合环境，在命令的使用上也要考虑“兼容性”。

以前介绍过 GNU 核心工具，不过没介绍那份有趣的 GNU Core Utilities FAQ，前两天又重新读了一遍。多少有点新内容。比如那个比较经典的问题，“Linux 下 df 与 du 显示的为什么不一样" (我自己就遇到过一次)，在 FAQ 上更新了很有权威性的线索: df and du report different information。

我这里补充一下的是，在比较大的文件系统上，保留给超级用户的数据块也可能会产生混淆。默认是 5%，如果文件系统比较大，这里的浪费还是比较惊人的，需要就实际情况作权衡。这个也会对 df 的显示有影响。如果创建文件系统的时候需要修改，用"-m"参数指定特定的百分数。

虽说差不多每天都在用 Unix ，但是总有无数知识盲点.

--EOF--

Livid 总能搞些让人惊喜的 Web 应用。之前的备受好评的 V2EX 被阻尼后，新开发的大脚社区 也赢得了不少朋友关注。今天早晨 Livid 给我演示了几张截图：大脚准备开放 API了。

查看截图：
1、界面展示
2、样例代码截图

目前 API 主要是针对先前大脚的便签本功能(?)。如果客户能够比较轻松的把便签内容集成到自己的站点或者 Blog 上，那么和 Livid 早前的 个人数据中心 的想法还是有些一致的。

本周应该就能看到这个服务了，Livid 还在继续提高程序的健壮性。至于性能，现在“普通的 1U PC-server，性能大概在 100RPS"。

更多的小道消息：现在每条便签可存储最多 50000 个 UTF8 字符，每个帐号可以存储最多 10000 条 note，”还计划让每条 Note 都支持带中文分词的 $nc->match() 及 Tagging“

有想法，能实现，这两条加在一起就非常难了，Livid 正在做.....非常有意思。算起来，大脚也是国内 Web 2.0 站点第二三个提供 API 服务的了(除了 Yupoo 和豆瓣，还有谁? Updated: Faint ,还有N多)。

--EOF--

从 Greg Linden 的文章看到的数据：Google 的 MapReduce 平均每天处理 20 Petabytes 的数据。每天能跑完 10 万个工作任务。光是 07 年 9 月，就用掉了 11081 个"机器年" ，跑了 220 万个 Mapreduce 任务。这个计算能力是惊人的。

Yahoo! 也用 Hadoop 实现了 Mapreduce , 我个人感觉和 Google 可能还有一段距离。光有计算环境还不行，还要有应用程序来实现功能，Google 已经实现了超过 1 万个应用程序，Yahoo! 有多少呢?

这方面估计微软更没戏了，要是弄个不包括 "Window" 的 Windows 服务器集群估计还能差不多，否则，光是一个视窗要耗费多少计算资源? 如果服务器规模是几万、几十万台，计算能力的浪费是惊人的。微软的对抗计划是 Dryad.

所以说啊，Google 的计算能力仍是独步武林，虽然有不服气的，但有什么办法? 这方面 Google 就是强啊

--EOF--

补充：

更多的数据(来源):

保存表或者相关数据对象统计信息的历史数据是个不错的习惯。万一新的分析(ANALYZE 或者 DBMS_STATS) 过后发现统计信息有问题，急于恢复的时候又找不到备份，是个比较糟糕的事情。

虽然我在维护的过程中很少使用 DBMS_STATS 来收集数据对象统计信息，不过用这个工具来进行统计信息的管理还是很方便的。

首先建立资料库, DBMS_STATS 的具体语法暂且就跳过去了, 毕竟手册上写的更清楚)：

EXECUTE  DBMS_STATS.CREATE_STAT_TABLE ('SCOTT', 'STATTAB','SYSAUX'); 

在 SYSAUX 表空间上创建 STATTAB 用以存储统计信息, 所有者是 SCOTT 用户。

导出统计信息. (在任何可能更改表的统计信息的 DDL 操作之前, 一定要导出统计信息)

EXEC dbms_stats.EXPORT_SCHEMA_STATS
(ownname=>'scott',stattab=>'stattab',STATID=>'foo_20080107');

这里建议手动设定一下 STATID. STATID 命名规则建议用 对象名(SCHEMA名)+ 时间(注意粒度).

至于导入整个 SCHEMA 的信息，一定要慎重再慎重。

在任何可能更改表的统计信息的 DDL 操作之前, 导出(备份)统计信息

EXEC dbms_stats.export_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

恢复该表的统计信息(之前要导出当前的统计信息):

EXEC dbms_stats.import_table_stats
(OWNNAME=>'scott',TABNAME=>'foo',STATTAB=>'stattab',STATID=>'foo_20080107');

为了避免误导，需要说明的是，我只收集表和索引的统计信息。尽量不用 DBMS_STATS 收集统计信息，要问为什么? 去看看 DBMS_STATS 相关的 Bug 就知道了(比如飞龙说的这个问题)。只有在 ANALYZE 力有未逮之时才会考虑用 DBMS_STATS.

这里说的 和 ADDM 无关，建议在熟知 ADDM 之前，最好别用这玩意儿。

--EOF--

这是我的 Oracle 11g 系列的文章之一(这一篇没啥含量，算是笔记吧)。

在 11g 之前的版本中，DBMS_STATS 自动统计收集(Automatic Statistics Gathering)默认的阀值是 10%, 这个 10% 是不可以修改的。这对千变万化的企业数据库来说环境来说，有些死板，如果是个超大的表，默认的 10% 数据也是海量了，会把整个资源占死。Oracle 11g 中，这个属性可以通过修改 STALE_PERCENT 属性来修改, 有全局（DBMS_STATS.SET_GLOBAL_PREFS ）和表级别（DBMS_STATS.SET_TABLE_PREFS）两种。

例子语句:

设定:SQL>  exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',1);
修改为 1％. 范围从 1-100. 
恢复:
SQL> exec dbms_stats.set_table_prefs(null,'EMP','STALE_PERCENT',null);
查询:
SQL>  select dbms_stats.get_prefs('STALE_PERCENT',null,'EMP') from dual;

虽然我很少用 DBMS_STATS 收集数据对象统计信息，不过它的有些用途还真的不错。

Refer: Metalink Note:390737.1

--EOF--

新的一年，抽空管理一下 Windows 里的文件。发现有的小工具用了两年以上了，也顺便推荐一下，是不是有些"火星"我倒真不知道，但总会对有些朋友有帮助的吧?

PathSync

目录文件同步工具。是 Cockos 出品，Cockos 是 Justin Frankel (开发 Winamp 的那个家伙)成立的公司，开发的产品也是和音频有关的。这个小工具估计是他们搂柴火打兔子随便搞出来的，但真是很好用。免费。

Craagle

这东西是干啥的? 搜索序列号或者软件破解工具的。我不是鼓励你用盗版，但如果是学习或者研究的目的.....要问哪里可下载，Google 一下就知道。

WinMD5

Windows 上校验 MD5 值的小工具。下载一些 ISO 文件的时候会用到。否则刻录了一张光盘发现是坏的，也挺闹心不是? 我的 Windows 几乎没有中过病毒，不过黑客、木马这么多，还是要小心别中招，一直想问的一个问题是，国内这些提供下载的站点，为什么不提供软件 MD5 校验值呢?

FairUse4WM

下载了视频文件发现需要 DRM ? FairUse4WM 就是用来破解 DRM 问题的。偶而一用，还真的不错。这工具的名字也挺有意思的，Fair -- 认为 DRM 不公平才开发的。

有啥好东西别藏着，也来推荐几个?

--EOF--

估计有些访问我的 Blog 的朋友已经被本站留言时的糟糕表现烦透了。其实我何尝不烦? 每当发贴子的时候，总要忍受一堆 HTTP 500 错误后才能成功，要多不爽有多不爽。趁着 (mt) 这段时间搞活动，买了一年 Grid Service (lite)。期待迁移完毕后 Blog 稳定性表现能好点。

有朋友帮我买了一台 1U 的服务器，国内有什么好一点的托管商麽? 最好不要被随时拔网线的，拔网线倒也问题不大，最好不要把机器抬走就成。

其实这么折腾来折腾去的，只是希望能有个稳定一点的写字儿空间罢了.

另外，今天也把域名转移的相关资料准备了一下，打算把这个域名也迁移到国外的域名服务商那里。不为别的，在国内一直不太放心罢了，虽然我的 Blog 没啥犯忌讳的内容。原来域名是通过代理缴费的，在这方面我是菜鸟，被鄙视的不轻，不过他们的服务态度还是很好的。

--EOF--

《魔兽世界》的生活意义就是，你是无事可做的傻人，只能坐下来狂按键盘杀虚拟怪物
--著名游戏设计师乔纳森·布罗。他说魔兽世界就像毒品

在《征途》里，我们所做的一切都是为了装备，一切装备为了杀人，一切装备反映了钱，体现一个人有钱没有，在社会上是否吃得开。
某玩家总结《征途》这个游戏

在屎壳郎的国度卖大粪才能成功
网友对《系统》一文的留言

时间管理首要就是把时间花在投资报酬率最高的工作上
--博恩·崔西

现在的墨西哥就像19世纪90年代抢钱大亨横行的美国，只是斯利姆把洛克菲勒、卡内基(Carnegie)和J.P. 摩根(J.P. Morgan)三人集于一身罢了
墨西哥投资家大卫•马丁内兹(David Martinez)评论首富斯利姆

谷子地只是那场炼狱熔炉中的一块铁，不知道自己来自何处，不知道生身父母，人家从谷子地里捡到了他，他的名字就叫了谷子地，侥幸逃生后，活着的目的只是为了讨个说法，有些一根筋。毫无疑问，这样的一根筋能够感动人。

“戴镣铐跳舞”，这题目有些垃圾，不过形容冯小刚的这部电影还是挺适合。相对国内如此严格的电影审查，《集结号》已经属于难得的突破了。很多人都认为冯小刚是个很商业的导演，其实他骨子里还是挺艺术的，只不过接了人家的投资就要赚钱，要赚钱就必然要商业一点，这是天经地义的事情。也算是职业操守吧。

我是在公映前看的，长这么大第一次享受了这待遇。看完了后和同事开玩笑说，这片子拍的，估计要考虑日本市场，所以不能和日本人打，要考虑美国市场，所以不能出现和美军大规模对抗的场景，和国军打倒是问题不大，毕竟台湾市场不大，再说了，即使和国军打，也还有一半市场可以拿。

这部片子的剧情剪辑我觉得比较失败。有些“豹头”+“猪尾”的感觉。

--EOF--

未来是个奇妙的东西，尽管我们喜欢预测，但是我们对未来知之甚少。时间容易嘲讽人，你会发现 06 年的预测 并不是完全没有发生，只是发生的慢一点而已(比如苹果进军手机与 Amazon 崛起)。而在 2007 年初作预测的那些人，其实早就忘了当初说了什么，现在都赶着做 2008 年的预测呢。这是个只向前看的年代。

我从回朔到的几篇文章看，在 IT 技术方面的这篇 “2007年五大突破性技术” 相对比较准确 。"NAND硬盘" 、”托管硬件“、”高级CPU架构“ 这三个很是到位，而 “Ruby on Rails” 我觉得还是高估了，从现在看，仍然是小众玩家手里的东西。至于“超宽带”，在国内暂时别想了，ADSL 不涨价就是好事情了，有了超宽带也恐怕要跑到国外才能用上。

这个技术趋势主要面向国外的，国内今年会有更多覆盖。我相信今年会有更多的笔记本装配上固态硬盘（SSD），“托管硬件”(网格计算/云计算技术）今年在在国内也会有厂商试水。

这篇流传比较广的 08 年 IT 大预测 中，我对 Facebook 还是不看好的，当然对 Yahoo！的预测我完全赞同，肯定是下一个 AOL。

个人觉得这些预测中漏掉的几个(加上国内的)：

• Google 会推出 Gdriver ，而 Google Gear 会在这个产品中扮演一个比较重要的角色。Amazon 最大的对手变成 Google。
• Yahoo! 收购 SixApart。
• Oracle 这个收购大胃王在财务上遭遇滑铁卢。
• 视频网站成为选秀节目最重要阵地，而更多的视频网站集体赴死，没有一家能上市。
• 国内也将开始 Web 2.0 收购战。
• 豆瓣的开放 API 作用不大，但淘宝也会开放 API。
• 国内将出现一个类似 TechCrunch 并具备类似影响力的站点，创办人最好是 keso.
• SNS 站点陷入阵地战。
• SaaS 建树不大
• WiMax 在中国部分城市试点，但是整体举步维艰。

此贴仅供扯淡。新的一年，整点发散思维吧

--EOF--