Google App Engine 有可能支持 Perl

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

今天看到 Brad Fitzpatrick (就是大名鼎鼎的 Memcached 的作者，现在效力 Google) 在网志中说道，正在利用 Google 著名的 20% 的业余时间为 Google App Engine 增加对 Perl 的支持。

[来源]

还记得时不时的会从中文 Perl 邮件列表里看到有人散布 Perl 过时的言论，其实一个语言过时与否都不重要，关键的是是否有人依赖该语言打造出比较激动人心的应用。如果 GAE 能够支持 Perl ，或许就是 Perl 焕发第二春的时候。从这个角度来说， Erlang 不也是如此么?

提个意见，Google App Engine 啥时候能支持给中国移动发短信? 现在支持 China Unicom，周围没有朋友用联不通的，大家都用移不动的。

–EOF–

MySQL 大企业级应用可行性分析(之二)

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

再说存储引擎

继续上一篇的讨论，记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是，注意各个引擎的锁的粒度。InnoDB 是行锁，锁的实现是依赖于索引的，MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标，其能力很大程度上决定并发能力。

至于 TRANSACTION ISOLATION LEVEL，则是另外一个需要衡量的指标。

老生常谈的，某某引擎适合什么类型的应用，归根结底还是由于其实现的机制决定了引擎的特性。

存储层的解决方案

相信没有人愿意在 MySQL 上用 RAW 设备，很多人几乎就是直接把数据文件放在文件系统上(个人认为，对于数据库这样的应用来说，文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统，单节点的数据存储能力肯定要受到制约–没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障，麻烦就来了。从这个角度考虑，或许 LVM2 是一个可选的方式。

当然，如果把数据文件扔到 SAN 上也还不错。一方面问题是，现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面，很多 MySQL 用户没有 SAN 环境的，数据都是在本地磁盘上。

固态硬盘与 MySQL

前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。相信现在有很多企业需要在 DB 的 IOPS 上寻求突破，SSD 是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

商业支持

现在 MySQL 的背后有 Sun ，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务，如果问题出在存储引擎上，MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。

–思路中断，这是这个系列不成熟的第二篇。如果有第三篇，我倒是想写几点关于 MySQL 的设想。

–EOF–

Oracle CBO 的 _sort_elimination_cost_ratio 参数

连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。

如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询，会发现很多和该参数有关的 Bug ，执行计划的出错特征是也走了索引，但是走了索引全扫描(INDEX FULL SCAN)，如果做 10053 Trace ，会发现有个烦人的 Recost for ORDER BY 步骤，然后就会引到错误的执行计划上。

在 9i 升级到 10g 最容易遇到这个问题(原来好好的，到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发，更多的时候优化器模式是 FIRST ROWS — 这样 Oracle 会尽量消除排序，默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题：

ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5

其它可能的解决办法：对索引里面的排序保持和 SQL 里的 ORDER by 一致。

其实说白了，很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的，因为不具备普遍性，所以在某些版本中作为隐含参数出现。在生产数据库上，个别的时候启用隐含参数倒也不是不行的，只要明白了相应的隐含参数到底是干啥的就成了。

题外话：_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现，倒是感觉和 Oracle 内部代码管理有关，本来应该消除掉的，怎么后面的版本又跑了出来?

目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ，有中文译本：《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。

–EOF–

说说大量列表项的排序展示问题

广而告之： 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

上周五去了一趟淘宝，在淘宝二楼实时展示交易信息的大屏幕前看了一会儿。发现关于商品显示的排序列表是两排，左右排列的。

1 商品名一 2 商品名二
3 商品名三 4 商品名四
5 商品名五 6 商品名六
......
N-1 商品名N-1  N 商品名 N
......

尽管符合从左到右的阅读习惯，看起来感觉怪怪的。前一段时间有不少关于电梯楼层按钮排列问题的帖子(一，二），针对电梯的按钮应该说已经讨论的很好了，但我感觉如果针对 Web 页面上大量列表项的排列显示来说，很有值得商榷的地方。

我再抛一个另外的反面例子，关于百度 Mp3 歌曲 Top 500 的列表展示：

(点击图片看大图或者到 Baidu 站点上体验)

假设 M 行 x N 列的展示，如果 M 很大，而 N 很小，在前面几行过去之后(一般是 N行*N列后)，会发现非常难以定位你要找的歌曲。尤其是越到后面效果越差。如果 M 和 N 都很小，那么相差是不大的(不知道这是什么心智模型? 尤其是对该项的描述也符合 M：N 值很小，比如 Flickr 的图片展示）。

这个其实和电梯楼层按钮排列的问题不太一样：电梯上面只有一个按钮(楼层号)，而 MP3 列表排列项后面还有该项的名字或描述(MP3 名字, 艺术家名字)。需要展示的内容性质和信息量已经变化了。

这只是 UE 门外汉的个人看法。供参考。

–EOF–

BTW, 注意到火车站和机场的公示牌显示倒是挺符合阅读习惯的。