下班后去南瓜同学的创业办公室拿票。这个我五一不出去了，准备二号三号两天去参加这个首届杭州·西湖现代音乐节。说是"现代音乐节"，其实几乎清一色的民谣歌手。
"叶蓓的深呼吸将在午后的阳光中浸透西湖天地的大草坪，小娟米汤般醇厚的声音将在杭州的暮色中响起。还有久违的老狼..."，狗屁，狗屁宣传文案! 去你的叶蓓、小娟、没听说过的朱七甚至老狼，老子只听周云蓬，万晓利就好了！ 如果说更多希望听的，将会是王娟+虎子、姜昕、苏阳。
南瓜同学手里还剩下少数几张 2 号下午的票，还是 8 折的，如果有感兴趣的朋友可以在豆瓣上联系一下他或者是在我这里留言。我个人认为，2 号下午这几个歌手是最值得一听的。尤其是周云蓬，一个人就值回票价的。
另外，南瓜同学最近在打造一个很前卫的音乐网站。预计不久后即可新鲜出炉，现在他也在继续找 UI 主管和 C++ 程序员。我在他那里还顺手牵羊拿了一张与人乐队的首张专辑《遇事拘谨》(淘宝有售)，收获颇丰。
生活在杭州，生活在现场。西湖天地地图。
--EOF--
今天随公司团队活动蹭饭。和以往项目庆祝之类的饭局不同的是，这次是为了实习生团队毕业的庆祝。
看着朝气蓬勃的这群新鲜人，挺有感慨。自己也曾经和他们一样，毕业后满怀憧憬地杀入职场。只是到第一家单位报到的时候可没这些准同事这么幸运了。当时可没听说什么"职场融入"，也没有什么"馒头(Mentor)"，两眼一抹黑。公司的总经理当着我的面，称呼我的部门经理，"钱总"，害得我"钱总"、"钱总"的喊了好长时间。对我来说，一直都认为这是一个比较失败的职场开场白...
放眼看去，现在同事当中， 80 后越来越多。其实大多数 80 后和 70 后没啥差别的，自己当年的困惑他们肯定也有，能和他们多做点沟通、多做点分享还是比较有意思的事情。
遇到好多好学的家伙，每每和他们一聊就是半天。我开玩笑说，和刚毕业的新同事交流其实我挺怕的：最怕问问题我回答不上来；如果能回答的话，担心回答错了；回答错误不要紧，最怕回答错误被对方指出来。
--EOF--
在我国当前的语境下，"官僚"是不折不扣的贬义词，"技术官僚"这个词在某些时候能算中性词，根据维基百科，指各级机构中大量拥有专业背景的中高层阶层的俗称。本文所指的"技术官僚"毫无疑问是贬义词，指那些造出"国标馒头"或与之类似诡异事物的家伙。
在一家大型技术公司里或是大型项目中，如果说不要低估蠢人的力量，那么更应该防备技术官僚的负面作用。如何避免自己成为技术官僚?
第一,不要总说那些"正确的废话"。比如，同事发了一封邮件，详细的描述了一下某个技术细节的可行性，而技术官僚的回复类似： "这件事非常重要，非常有意义，感谢某某同事......" 大家都知道的重要事情，就不要总跑题去强调了。
第二, 不要把太多的精力耗费在开会上。尽管很多公司认为人是最宝贵的资源，却往往看不到人的最宝贵资源是时间。很多人之所以是技术官僚，就在于他们把会议当成了休息时间......
第三,不要任何事情都和竞争对手看齐。思考，不要盲从。有的时候，对方那么做，可能是不得以而为之，而你亦步亦趋，恰恰是没有创造力的体现......
可能技术官僚的特点还有好多，先从这三点克服吧。
以言说抵抗技术官僚，或避免自身成为技术官僚的一种有效方式是，寻找合适的时机，向老板及其同僚庄严宣布：你们都在放屁! (Hutuworm 对这段话有全部贡献)
--EOF--
继续我的学习笔记之旅。Flickr 的 DBA Dathan Pattishall 在前几天的 MySQL 大会上分享了 Scaling Heavy Concurrent Writes In Real Time (Record every Referral for Flickr Realtime) ，其中介绍了 Flickr Stats 的设计经验。国内好多 Web 站点其实也在设计类似的功能，只是不知道细节罢了。
字段 数据类型
Path_query Varchar(255) PK
Domain Varchar(50)
Owner Bigint
When Date
Object-ID Bigint
Object-Type Tinyint
Counts and stuff Various ints May be some keys
主键是字符串，开销太大。其他的索引如果做主键，也比较大。当表大小超过内存的时候，插入速度很慢，I/O 能力也上不来。
数据预处理，通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type，这个统计信息很容易抽象到一个数据对象，这个索引的设计也在于此。
另外补充一点，利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理，耗费的存储空间只为原来地 25%，这是个很有趣的技巧。
对于海量的数据，以一个礼拜为间隔，水平分割。按照不同的数据力度每周一个表，每年一个全局表，再加上一个汇总表。数据量越大，InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。
所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列，每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。
总体的服务器规模过去 介绍过，对专业版用户的数据是永久保留的，而普通用户则只保留几周，为节省空间，采用 MyISAM 引擎，当用户转为专业版时，迁移数据。
补充一下，抓取 URL 是用的 curl 。最后，这篇 PPT 在线观看。
--EOF--
补充一张图：
这是该功能的 UI 设计。
公司团队活动，集体观影。笑翻，没想到李连杰、成龙联手，喜剧效果直逼星爷。
打斗固然精彩，冲着李、成两位，票钱也不冤枉。必需要说的是，台词超经典。举一个例:
天行者："我们是不是不能走出沙漠了?...我都快要冻死了"
默僧(李连杰)慢慢转头(深沉地)："不要忘了呼吸"
鲁彦(成龙)喝的那个长生不老药...绿色液体...看到那里我禁不住脱口而出，"好像雪碧"
最后的玉帝，演出效果和《食神》里面那个梦遗大师颇有神似之处。问天行者要实现啥愿望(这不就是按照上帝的功能来整嘛)，"我只想要回家"，玉帝长出一口气说道:"那我就放心了"。
--EOF--
今天是世界读书日。不说技术这些无聊的东西了，晒一下今年以来在卓越亚马逊上的购书清单。
* 德川家康/第六部双雄罢兵
* 山南水北
* 漫长的告别
* 乡土中国--故园徽州
* 德川家康--第五部.龙争虎斗
* 大败局（修订版）
* 激荡三十年--中国企业(下)
* 鹿鼎记(共5册新修版)/口袋本金庸作品集
* 激荡的百年史（插图珍藏本）
* 汪曾祺谈吃
* 德川家康4：兵变本能寺
* 乌合之众：大众心理研究（最新版本）
* 抗战时代生活史
* 中国古代文化常识（插图典藏本）
* 痛风的诊断与治疗/临床常见病症诊疗丛书
* 银元时代生活史
* 魔鬼经济学
* 德川家康3：天下布武
看来这段时间就和《德川家康》较劲了。另外比较喜欢韩少功《山南水北》的恬淡。《银元时代生活史》传递出来的生活趣味也很有意思，和去年看过的《侠隐》有的一比。
发现自己对书的评语基本上分"好看"与"不好看"，如何好看? 有趣，如何有趣? 好看...
--EOF--
过去写过很多关于 eBay 数据平台架构的帖子，过去eBay 的信息架构里 DB 都是采用 Oracle 的，大多数 DBA 朋友也都知道 eBay 在 Oracle 方面的技术搞得非常好。这次的 The 2008 MySQL Conference & Expo 披露出来的信息，eBay 在 MySQL 上做了很大胆的尝试，eBay Personalization Platform 就是用 MySQL 打造的。Sun 当然不会放弃这个大好的宣传机会(这两家在技术上的合作一向也比较多)，所以年度最佳应用给了 eBay (一同获奖的还有 Virgin Mobile France 和 Facebook )。
面临的应用场景：客户端 Cookie 最大 4K，如果要传递更多定制化信息就不好搞了。作为电子商务站点，肯定有要为用户提供更具有关联性的商品信息的业务需求，这样就要跳出原有的窠臼。通过数据库集群来存储类似的信息就是有必要的，但 eBay 原有 Oracle 数据库上的压力已经很大。
eBay 采用 MySQL Memory Engine 做数据库 Cache 层解决方案(如果纯粹用 Memcached 类似的方案也不太适合的，读写比例接近)， eBay 工程师 Igor Chernyshev 对内存引擎做了质的改进，而这些改进是开放出来的(Mysql-heap-dynamic-rows 项目，对 VARCHAR 列的内存开销算法做了革命性的改进)。另外一个 Patch 扩充了并发能力，一台普通的 Sun 4100 上能支撑 20000 个并发连接。每秒钟处理 13000 个 TPS，读写各半。25 台机器组成的集群，每天支撑 40 亿次的读写请求，为每个用户传递的定制数据平均大小 40 K，从 4K 到 40K ，足够多的定制信息可以存储了。
架构示意图(来源)：
这个个性化平台系统虽说关键，但是存储的数据并非不能丢失的。这也是 eBay 大胆采用 MySQL 的一个考虑因素吧。
MySQL 更大规模部署时代似乎来临。
--EOF--
在中国农业银行杭州的一个营业网点做了一回比较糟糕的上帝。
具体的需求场景：我有一张在吉林省办理的的农行金穗卡，在杭州要给杭州一家公司的账户转一笔款。
办理的过程遇到种种不快，尽量忍了。先说拿到的回执是"银行卡取款业务回单"，上面的交易类型是"现金取款"。手续费扣了 100 元人民币。这个 100 块还是超过我的预料的，这毕竟是同行异地转帐而已嘛，这个 100 元怎么产生的，为什么交易类型是"现金取款"呢?
先是咨询了农行的一个业务人员，她第一次告诉我收费标准是按照 1% 来收，封顶是 300 元人民币。可这样无论如何收 100 元是不对的，然后让我去找值班经理。值班经理爱搭不理的给我打印了一份收费标准的文件看，上面是 2003 年的收费办法 ，写着异地取款的标准，而且告诉我这个情况就是属于异地取款，可是那个文件上写着收费是按照 1% 的，而且没有封顶。
你们收费是严格按照这个标准执行的? 对呀！说这个文档我可以拿走么? 该经理立刻变了脸色，不是都给你解释了么? 这是我们的内部文件，保密的，你不可以带走。只是个收费标准有什么好保密的? 那好，我拍几张照片总可以的吧? 用手机把关键的那一页拍了下来。
我回来上网查询了一下农行借记卡的收费标准，发现至少 2005 年与 2007 年各有一次费用调整。而我这个业务，我的理解应该属于"异地卡柜台转账支出"，而不是"异地卡柜台现金取款"（只有这个费用才对得上)。同事告诉我说，假设农行"定义"这个"转帐" 只限于卡与卡之间，你也没辙。
我第二次回到农行，要问个清楚。还是找到那个值班经理。对方见我有备而来，似乎也感觉有些难缠。我直接问她我的需求是不是应该属于"异地卡柜台转账支出"呢? 对方答"是"，我说那为什么柜台人员不给我选择这个业务类型，而选择费用更高的呢? 对方答不出，于是说现在现在可以给我重新办理。我说那是不是银行操作员开始的时候操作类型是选择错的？甚至是有意错的? 这时候给我办理转帐的业务员冲她喊了一句："是对公的转帐"。然后这个值班经理立刻就改口了，说刚才给我办理的方式就是正确的，农行统一都是这么办的。要先把我的钱取出来，然后再汇款，所以有个"现金取款"的业务操作。"你确定? 刚才的谈话我录音了啊..." 旁边有个更刁的营业员插话，"录音非法，咱告他"，那值班经理想了想，"你还是和我们的主任说吧"。
主任也是个女的，相比之下态度还算不错，问了半天到底是怎么回事，最后告诉我农行借记卡的转帐就是卡与卡之间的转，如果是个人对公，就不是所谓的转帐，然后就给我解释什么银行内部是怎样的，各省之间又是怎么回事，什么总行上面的规定之类的，我算是"补习"了一下财务知识，可是这和我有什么关系?
我问如果办理一张本地卡先把钱转过来，然后把钱转到该对公账户上，费用也不超过 100 (办卡的费用加上转款的50块而已)? 这之间的成本差异跑那里去了呢? 而且，既然存在这样成本更低的途径为什么柜台人员收费的时候也不询问一下用户的意见，收费之前为什么不告诉客户? 客户直到最后才知道被扣了 100 元； 再者说来，收了 100 元，出示发票总是天经地义的吧? 请提供发票。
最后银行"让步"说，可以按照我说的方式办理，不过要先把这笔交易撤回，撤回方法呢，根据农行的业务规则，要收款方出示支票才可以...今天还有 15 分钟，如果你找收款方要支票，今天重新办理这笔业务来得及...说了一大通，可这不同样是不可能的任务么? 我要确定的是这个收费依据是根据什么来的，是不是正确的收费途径，又不是非要省这个几十块钱。简言之，我的这个需求就是"转帐"嘛! 那里有明文规定这不是"转帐" ? 给出标准即可。
从最开始的给客户出示陈旧的收费规则，不敢让人把收费标准拿走，到最后暗示类似的业务有更为优惠的操作方法，甚至答应用户可以重新业务操作......我个人严重怀疑农业银行的对类似业务的收费方式存在猫腻。服务不规范暂且不说，对于具体业务的定义绝对存在歧义，偷换概念，什么是店大欺客?
算算每个类似的操作多收 40 元，每天全省有多少类似的操作，加起来来要多收多少钱呢?
以前看到不少朋友发一些所谓的通过银行的"省钱"手段，好像沾了银行多大便宜似的。作为用户，有权利享受更低的费用政策，而银行这种给用户添加操作障碍、黑箱操作敛财的方式和吸费电话本质区别在哪里?
--EOF--
MySQL 爱好者关注的 2008 MySQL Conference & Expo 落幕后，很多文档都能看到了。今天读了一下这篇 Scaling Out MySQL: Hardware Today and Tomorrow。感兴趣的朋友也不防下载下来研究一下。
用什么样的硬件做 MySQL ，真不是三言两语能说清楚的。不过该讲座中还是能总结出来几点关键点的。
首先如有可能就选择 64 位CPU，这样才可以安装 64 位操作系统，有了 64 位操作系统才能利用好更大的内存。如果非要抬杠的话，不是 64 位芯片也可以安装 64 位操作系统，也就是 Intel 的 EM64T 的解决方案(这也是文档中没提及的) 。
我个人倒是比较喜欢 AMD 64 位 CPU 的，物美价廉，性能也不错。
注意： MySQL 在多核上的 Bug 问题。
第二点是尽可能配置比较大的内存，当然，只配置内存如果 MySQL 参数配置有问题，还是摆设，如何设置各个引擎的 Cache 相关参数，够写一本书的了。
现在市场上内存是越来越便宜了。我个人的感觉内存降价的程度比 CPU 和硬盘都夸张很多。所以，考虑到人力越来越贵，内存越来越便宜，配置服务器的时候就别太吝啬了。
国内用 MySQL ，绝大多数都是直接仍在本机磁盘上的。这个磁盘的选择要慎重一点点。尽量选择 15K 而不要 10K 慢速磁盘，大多数数据库的磁盘问题都在速度上，如果只在磁盘上多花费 30%的钱而能得到总体性能的 30％收益，那么还是值得的，而容量多数情况下不会出现问题，现在的硬盘容量就是一个大。
至于选择什么类型的磁盘，SCSI 与 SAS 都可选，SATA 倒是够便宜，特定的应用再考虑吧。
这三板斧看是简单活，但是实际的应用场景下可未必就能做出更优的选择。最简单的东西也有人不知道不是?
--EOF--
热热闹闹的 The 2008 MySQL Conference & Expo 还没落幕，一个不那么和谐的小道消息传了出来并被最终确定：Sun 计划对 MySQL 进行"选择性开源"，某些企业级的新特性源代码将不再开放。
谁知道 Sun 葫芦里卖的什么药，看家宝 Java 都开源了，在 MySQL 上还保留什么呢? 能否成为更受人尊敬的公司，还要看气度。这点上，Sun 始终扭扭捏捏。
一心要做 Web 2.0 中的这个 Dot 的 Sun，看来又要做活雷锋了，不过这次似乎是要帮助一下竞争对手 PostgreSQL。
--EOF--
一个很有意思的技术嫁接。Pythian 发布了一个 MySQL 插件，通过该插件，Oracle 10g 的 Enterprise Manager Grid Control 能够用来管理 MySQL 。
在 Oracle 10g 刚发布那会儿，EM 的地位在整个链条中倒是挺重要的，几年下来，似乎并没有占领多少市场。我个人觉得这个工具挺"重"的，倒是很少看到有 DBA 用这个工具。
尽管这个 MySQL 插件应用场景可能不多，但这还是第一次看到第三方给 Oracle EM 带来扩展能力。
比较关注即将召开的 The 2008 MySQL Conference & Expo，Sun 收购 MySQL 之后第一次大规模亮相，能带来什么? 新版本的特性基本了解了，还有呢?
Updated: InnoDB Plugin 1.0 for MySQL 5.1 也需要关注一下。
--EOF--
刚在邮件列表里看到通知，AWstats 发布了 6.8 Beta 版。
和上一次更新相比，新版本增加了特性不多：
Added OnlyUsers option.
Can show a full list for extrasection.
Can track RPC request.
如果要定制跟踪额外的访问信息，Extrasection 总是绕不过去的。还没测试这个版本，倒是希望这部分内容的配置能更清晰容易一些。
值得一提的是浏览器数据库的更新与 Patch 几乎都是中文搜索引擎与 Web 应用的爬虫相关，据我所知车东同学做了不少这方面的工作。
BTW: AWstats 堪称中小站点分析日志的不二之选。尽管这样，前段时间还是看到有些公司居然不了解这个好用的工具，嗯，推广之。
--EOF--
我算得上是 Movable Type 的忠实用户。这两年来，WordPress 快成为 独立 Blog 的标准配置了，MT 可以说每况愈下。自从升级到 MT4 之后，明显感觉 Blog 性能糟糕了很多，每一次发文章都要与 HTTP 500 错误战斗半天才能成功，读者留言也非常费劲，有段时间非常灰心丧气，都不想继续写下去了。如果说 MT 3 之前是与 SPAM 战斗，到了 MT 4 就完全是折腾性能问题了。虽然 MT 4 之后的每次小版本发布都宣称性能上有很大改进，实际表现总是欠佳。
一些常规的 MT 优化技巧 其实作用都不大，我还把 MT 用的数据库索引分析了一遍，删掉了好几个价值不大的索引，虽然不是无用功，但也解决不了问题，因为瓶颈根本不在 DB 这里。大多数 Movable Type 用户的应用场景是在 Dreamhost 上，在这个环境里要想找到应用的瓶颈还真的是个技术活。缺乏 Profiling 工具不说，如果调用某个命令消耗了资源稍微过份一点，立刻被系统 Kill 掉。
其实 MT 的设计思想还是很不错的，大部分页面都 Build 成静态页面，减少对数据库的压力。一般来说，这比 WordPress 频繁调用数据库的方式(当然 WP 是可以起用 Cache 的)，应该在性能上有更好的表现才是。问题是 Dreamhost 对每个用户提供的硬件资源其实是很差的，尤其是磁盘 I/O 。我的所有页面加起来也不过几千个，如果只是访问静态页面或是数据库其实问题都不大的，麻烦出现在构建页面或者是遇到留言行为的时候，MT 会调用若干个磁盘上的模版文件，加上 Perl 本身的系统开销，消耗的资源就到了 Dreamhost 的极限，然后进程就被无情的 Kill 掉了。估计是用户群抱怨太多，从 MTOS 4.1.1 版本开始总算有了一个性能框架 专门用以分析性能问题(并且号召用户提供性能数据以便协助解决性能问题)。启用了一段时间后，收集到的 Log 响应时间典型是这样的：
MT::Template::build[Comment Response]=0.60070
MT::App::Comments::run=28.24320
Total=28.85665
或许在 I/O 不错的系统上，表现会好吧。Dreamhost 上文件都是放置在 NFS 上的，而且众多用户共用一个系统，只能将就一下。
今天看到 4.15 的改进中，已经可以 Cache Template Module 了。甘愿作小白鼠，升级。盼望这次能有效解决特定应用场景的性能问题。不过开启了性能 Log 看了半天，效果并非很显著，
后记：
通过Cache提升MT基于Tag搜索的速度，只在第一次构建需要的 Tag 时候会占用平时一样的系统资源。再次搜索时，开销大大降低。"抱怨的同时要有解决办法"。
--EOF--
炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流，逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。
任何一个成功的站点都有一套最合适自己的 Cache 策略。
Note：这个层次图画的稍微有点问题，不是严格从上到下的。
Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。
Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。
APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。
Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。
Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。
为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: "Languages's don't Scale, Architecture Scale"。
从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。
(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)
--EOF--
上周六第一次进健身房。运动前，教练先给我进行了一下体能测试，结果我的结果是"虚弱"，需要大量增加肌肉。在跑步机上快走了一会儿，加上一阵小跑，出了点汗，感觉还不错。
今天冒着大雨又去了，差点浑身被浇透，可见心有多诚，还是在跑步机上折腾，不算太累。争取达到崔健说的"一周三次跑步加上一次游泳"，总算有时间梳理一下自己的生活了。
另外准备投入更少的时间在网上，纽约时报报道的那几个倒下的 Blogger 让人警醒。身体好才是正经事，前一段时间，家里亲人生病，心里闷了好久。有的时候光有钱也换不来健康。
--EOF--
自从 MySQL 被 Sun 收购后，相信很多对该收购不放心的朋友会转而看好 PostgreSQL 的前途。虽然比较大的 Web 2.0 站点数据库方案基本都采用 MySQL ，不过也有用 PostgreSQL 并且跑的不错的。今天看到 Skype Plans for PostgreSQL to Scale to 1 Billion Users 这个帖子，对 PostgreSQL 在大型网站应用上的部署算是有了一点了解。
Skype 在数据库上的横向扩展能力以 PL/Proxy 为基础的。其实几乎所有部署 MySQL 的站点也都在考虑 Scale Out (相比 Scale Up) 的扩展方案，也有 MySQL Proxy 这样的产品推出来，只是看起来还不够成熟。PL/Proxy 的设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发，示意图如下：
PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。（虽然随着服务器越多，通信的开销越大，但只要不大于某个规模，似乎还不足以成为比较大的问题)
随着数据总线层的水平扩展，连接池的问题就凸显出来。Skype 在连接池上的解决方案是采用 PgBouncer，PgBouncer 极大地增强了 PostgreSQL 的连接数扩展能力。顺便说一下，"池"有三种级别：Session 池、事务池、语句池。
Skype 另外开发了一套工具包： SkyTools 来进行数据库的维护，主要是解决数据的复制与队列以及失败接管问题。
整体看下来，围绕着 PostgreSQL 的解决方案其实蛮成熟的。BTW，看起来挺适合阿里旺旺的 :)
--EOF--
从一种 DB 转到另一种 DB 的最初阶段，往往要找自己原来熟悉的工具。拿我自己来说，算是有点 Oracle 的经验，有时被问及 MySQL 优化的东西，就希望找到 MySQL 上类似 Oracle 等待接口或是 SQL Trace 之类的工具，多少有些路径依赖。
Slow Query Log 是 MySQL 的基本 Log 之一。这个优化思路基本上是用 SQL 执行时间 作基准(类似 Oracle 基于等待的优化思想。另外，在 MySQL 中我还没发现根据 逻辑 IO 作基准的方法，这样对于存储层的性能控制就有些不好入手)具体如何操作我就不赘述了。默认情况下，在产品环境中如果临时决定起用该特性是影响可用性的。另外，旧一些的版本时间粒度相对比较大(最小 1 秒钟)。可以通过 Microslow Patch 来解决这个问题(粒度可以到百万分之一秒)。这个 Patch 在开发测试环境也很有用武之地，有些公司的线下开发环境数据不能达到产品环境的规模，如果也把眼光放到抓取执行时间大于 1 秒钟的 SQL 无疑会漏掉很多潜在的问题语句。
在 MySQL 5.0 之后，利用 --log-queries-not-using-indexes 参数可以抓到未使用索引的慢查询。为什么 SQL 没有使用索引，这恐怕是开发 DB 应用的朋友要问的最常见的问题之一。
关于 Slow Query Log 的分析，MySQL 自带有 mysqldumpslow 分析工具，除此之外，也有包装的更好(?)一点的开源工具，比如 MyProfi，以及 Mysql-log-filter。
Sun 收购 MySQL 之后，相信很多人都会对 Dtrace 能否集成到 MySQL 比较感兴趣。其实原来就有人利用 Dtrace 来分析 MySQL 性能问题。不过这个方式门槛还比较高，也没有形成比较清晰的方法论。
网上关于 MySQL 优化的文章汗牛充栋，我这篇就当是读书笔记吧。
--EOF--
Oracle 对 PHP 的支持一直是不错的(只是国内好像 PHP + Oracle 的开发并不多)。 Oracle 11g 中的新特性数据库驻留连接池(Database Resident Connection Pool，DRCP) 对 PHP 应用进一步扩展带来了一种可能。
这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。
Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个...还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。
--EOF--
