February 2010 Archives

最近 Apple 和 Adobe 之间因为 Flash 的支持与否，口水仗打的比较热闹。个人愚见，苹果公司做出当前的选择应该不是因为乔布斯要逞一时口舌之快，相信是内部自有 iPhone 以来的长期评估后做出的选择，苹果公司从战略层面甚至会把 Adobe 看作竞争对手而不再是重要的合作伙伴，而谢绝 Flash 入内，是一个非常精明的借口。

之所以说二者是竞争关系，关键字还是在于"平台"。Adobe Flash 是当前业界占有率最广泛的一个技术平台，甚至超过大家想当然的 Java 。根据 Adobe 的统计，Flash Player 占领了 99% 可上网电脑设备，有超过 200 万专业用户在使用，这里的专业用户应该指具备一定开发能力的用户，依托于 Flash 的应用程序数量已经相当的惊人。所以，是否在 iPhone 、iPad 上引入 Flash 的支持，从苹果的角度看，这是平台之战，谁也不想引狼入室。我们设想一下假定 Flash 已经得到了苹果公司的支持，那么 Adobe 可以一转身也建立一个 "Flash App Store" 或者类似的东西，开发者可以用上传的小应用，任何平台的用户都可以下载使用。想想对苹果的冲击会有多大? Adobe 或许还没想好如何也建立一个 App Store ，但不排除将来会染指这一块业务。

苹果公司长久以来不太有"开放"的态度，或者说是"封闭的开放"，最希望通过自己封闭的环境，让用户通过圈下来的地建立一个生态圈子，不想和其它公司一起合作。乔布斯回归后，通过激发用户对 iPod 喜爱与信赖，进而购买使用 iPhone ；通过 iPhone ，进而使用 iPad ；通过 iPad ，再回去使用 Mac 。这是个非常好的封闭循环过程。开放，会丢掉利润，而封闭，才会让苹果公司有更大收益。当然，我也想说的是，对 Flash 的支持友好也的确有可能让 iPad 在某些方面导致平庸，比如性能。与之类比的是 Firefox ，现在速度问题广为用户诟病，而这问题基本由插件导致的，现在 Chrome 尽管足够快，但随着扩展日益增多，必然重蹈覆辙。

现在乔布斯游说内容提供商加入他的 iPad 阵营，而他之所以敢批评 Flash 的不足，也是因为还有另外的技术路线可选，那就是 HTML5 。但是有多少内容提供商会舍弃 Flash 而加入 HTML 5 的阵营，这个还需假以时日才能看清楚。换做另外一家公司，来自用户的呼声可能都会受不了，对于苹果来说，我行我素是一贯的风格，乔布斯一直是个精明的商人。

是否会在 iPad 上看到 Flash ? 将来或许会，但是这要在乔布斯开给 Adobe 的条件都得到满足的情况下才会出现(没错，这两家现在或许已经在谈判桌上了)，这些条件当中，除了解决当前的性能和稳定性问题(这个问题并非原则上的问题)，最重要的是 Adobe 不要与苹果有商业利益上的冲突，苹果一定要得到某种承诺，而这，对于 Adobe 来说，也会是艰难的选择。

--EOF--

注：春节期间构思此文，一直没发出来，后来发现有不少人也持类似观点，澄清一下，并非拾人牙慧。

说起平台，国内 360 安全卫士尽管已经取得了惊人的装机量，进而推的浏览器和网址导航也都立竿见影，但是还难脱"工具" 的影子，还是不能形成技术生态环境，我相信不会有类似 "360 平台" 的产品出来的，不是不想，而是做不到。

Sun(Oracle)公布的 Java 在桌面机有 8 亿。

现在看，这篇文章太初级了，敬请参考 Jobs 帮主对 Adobe Flash 的的檄文：Thoughts on Flash

春节前已经看了一遍这本 《苹果往事》，假期又看了一遍。对于这段苹果公司并不鲜为人知的历史来说，这本书从一个亲历者的视角给 Mac 的诞生加了一大段注解。这也是苹果拥趸者最喜欢看的内容。

彼时的乔布斯，恰似刚受封齐天大圣，自信无所不能，被排挤到 Lisa 项目之外意味着他将来没有权利说这是他设计的产品，所以最想做的事情就是找个项目来证明自己。他对于 "自己参与设计" 的项目无疑是寄予厚望的，也给予了足够的支持，否则这个从概念项目起步的团队也不可能发展起来。对于这个团队的多数人，他们要研发的这个产品，不为名不为利(实际上也只有少数几个人得到了名利)，更多的是创造性工作给自己带来的成就感，什么是激情，或许这就是。

对于 1984 年苹果推出的 Macintosh ，现在来看，或许是那个寓意深刻的广告更为令人津津乐道。当时的 Macintosh 只能算是杰出的电子艺术品，是否是成功的产品很难定论。毕竟从市场表现来看，没有给苹果带来像 Apple II 那样的辉煌。这个产品的推出从某种程度上也间接促成了乔布斯被赶出苹果。 是苹果公司发展历史上的一道分水岭。如果没有当初，或许也不会成就现在的乔布斯。现在的 Mac，其实无法让人等同于 1984 年的 Macintosh...我相信只是有些精神会延续下来...或许这样就已经足够了。

在这本书的最后， 作者 Andy Hertzfeld 感伤 "我所渴望的理想麦金托什团队模式已经消失了，融入了那种我们以前常常取笑的大型组织当中，内部充满官僚障碍及人际摩擦"。曲终人散，这个团队的大多数人都将不再服务于苹果公司。这也是那些非凡团队成员的普遍命运。

阅读这样一本书，对我们更有价值的事情从中学习那些经验和教训，关于人，关于事。让人欣喜，让人心酸。

--EOF--

给我的朋友们，还有这个网站的读者以及Twitter 上的推友：感谢过去一年对我的支持、帮助亦或是鼓励、信任。祝愿大家在虎年（来个更加环保一点的拜年）：

新年快乐！健康平安！

新的一年就要来临，在这新的一年会有哪些奇迹发生？一起来期待并见证吧...

一切高墙都会倒塌，只要我们坚持并坚信。

--EOF--

推荐一首歌，崔健 《春节》

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是"核心系统维护"。

个人之所以比较关注这个事故，是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误，造成宕机"。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 DB2 Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS (End of Service) ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，"民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线"，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

--EOF--

有朋友后续补充到：2010 年 2 月 12 日上午 10:25，民生银行的信用卡网银不可用，返回 HTTP 500 服务器内部错误，网站上并没有相关的维护计划，咨询客服，说是系统维护升级。整个民生的 eBank.cmbc.com.cn 都是无法登陆的状态，看来"维护升级"的不只是信用卡网银，自2月3日以来，不到10天又发生状况。

简要回顾一下 2009 年数据库技术领域。过去的一年，差不多也可以说是过度的一年，数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。

Oracle 收购 Sun，MySQL 前途未卜

Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后，欧盟委员会又开始调查，Oracle 随后抛出一个"十条保证"，眼看着欧盟就要点头，没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动，让 Oracle 头疼不已。Monty 这人多少也有点上纲上线，现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。

没有人会相信 Oracle 会善待 MySQL，谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来，毕竟商业公司就要逐利。但是，也很难说一旦收购完成后 ，MySQL 会在短期内消失，基于 MySQL 众多开源分支以及解决方案也都发展的不错，我相信最终决定权还是在用户的手里。就算没有 MySQL，也没准儿会有 YourSQL 出来的...

尽管口水战还在进行，MySQL 的开发者倒是没闲着，在年底发布了 5.5 第二个里程碑版本，原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本，将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。

而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版，与第一个版本不同的是，这一个版本在 OLTP 方面增强了许多。从这个版本开始，Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上，除了发布 11g 第二版之外，也在做功能上的调整，这一次，面向的是数据中心。

NoSQL 的兴起

这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的：当时还效力于 Last.FM 的 Johan Oskarsson （现在已经投靠 Twitter 了)组织了一个技术会议，话题是关于"open source, distributed, non relational databases"，为了方便一点，想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用，进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化，尤其避免表连接，并且通过一些变通的办法提供 RDBMS 的 ACID 功能（如果需要的话）。

NoSQL 的理念能够短时间内被技术圈所接受，离不开基本的理论支撑：最终一致性、BASE 、CAP 这三大基石；一方面是基于 Key-Value 的数据存储解决方案更加成熟，

所谓 NoSQL ，是针对当前对关系型数据库的过度依赖与运用而言，不要将其当成万能药，也没必要过于激进的推行 NoSQL 的模式。在我看来，NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说，仍属屠龙之技，没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路，我认为不尽然。RDBMS 依然尤其广泛的应用场景，而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。

SSD 被更多企业接受

Jim Gray 在 2006 年的那句名言：Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King ，现在正在被现实所验证。2009 这一年，用户已经开始进一步试水 SSD 产品，包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用，这其中包括阿里巴巴、优酷。

更多的存储厂商已经在高端存储中兼容 SSD ，除了去年的 EMC 尝鲜之外，现在 IBM、HDS 、NetApp 都加入了这一阵营。

随着 SSD 的价格迅速下降，很多存储厂商已经开始调整硬件架构，现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层，在成本与性能之间做一个折衷。

在去年年底的回顾中，我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年"，总体来看，2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。

Amazon EC2 对 MySQL 企业版的支持

尽管我不愿意谈云计算，不过 Amazon 这一年在云计算方面还是做了很大的突破，Amazon EC2 上面现在已经可以跑 MySQL 企业版了，采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择，这比 SimpleDB 可以说是前进了一大步。 这种模式在国内是否可行，考虑到当前内容审查的问题，还有待商榷。

国内 Key-Value 产品

这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离，豆瓣网先作出了不错的表率，发布了 BeansDB 存储系统，这是一个豆瓣风格的 Dynamo 实现，采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。

其它方面

Hadoop 过去一年中没有太大的变化，上了一点规模的网站都在用，快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响 ，不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况，在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事，倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。

有一点要补充的是，假以时日，Open Data 或许也将成为一个趋势。

当然，这份回顾有浓郁的个人色彩，有不同意见请留言探讨吧。

--EOF--

本文发表在《程序员》杂志，不过这里的有些许更新。本文写作时，Oracle 收购 Sun 还没有尘埃落定，现在看起来，一切都变化太快。

前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。

Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。

最近一两年，DDoS 攻击在国内现在更加"流行"而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的...

其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。

--EOF--

BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行...必备...

自从 Oracle 和 HP 推出 Exadata 之后，我就很关注这个产品，之前也写了一篇Oracle Database Machine介绍它。去年，Oracle和SUN合并后，推出了Oracle Exadata V2，相比较上一代产品有几个变化：第一，使用 SUN 的硬件；第二，宣称支持 OLTP 应用；第三，Oracle 11g R2 提供了更多的新特性。

Exadata Smart Flash Cache

Exadata V2整体架构并没有太多改变，换用了 SUN 的硬件，除了采用 Intel 最新的 Nehalem CPU 以外，每台 Storage Cell 更是配置了 384GB 的 Flash，这也是为什么 V2 可以支持 OLTP 应用的关键。

Flash Cache 完全是自动管理，Oracle 会根据数据的访问情况，决定哪些数据放在 Flash Cache 中。所有的数据都是先被写到普通磁盘上，再根据访问情况读入 Flash Cache 的，所以如果 Flash Card 发生故障，数据不会丢失。当然，Oracle提供了方式，可以让用户手动将表或者索引 Pin 在 Flash Cache 中。

在自动管理的方式之外，Oracle还允许用户人工创建flash disks，和普通磁盘一样，这些 Flash Disks 通过 ASM 输出给数据库使用，用户可以把一些访问非常频繁的数据文件放在上面。这些 Flash Disks 不仅仅是 Cache 了，所以 ASM 会在Cell 和 Cell 之间做镜像。如果某块卡发生故障，那么整个 Storage Cell 上的 Flash Disks 会 offline，保证数据不会丢失。

Smart Scan

Smart Scan是 Exadata 最重要的一个功能，它的作用就是把 SQL 放在每个 Cell 上去运行，然后每个 Cell 只返回符合条件的数据给数据库，这样就极大的降低了数据库服务器的负载和网络流量，并充分利用了 Cell 的计算资源和 IO 资源。

传统方式：所有的数据都需要返回给数据库服务器，网络带宽要求高，所有的计算在数据库服务器上完成。

Smart scan：只返回符合条件的数据，减少网络带宽，并充分利用了 Cell 上的计算和 IO 资源。

这里有一点要注意，在使用 Smart Scan 时，每个 Cell 返回给 DB Server 的是结果集，而不再是传统的 Block， DB Server 完成结果集的处理，并返回给客户端。

Smart Scan 如何处理 Join ？

这是我一直想要搞清楚的问题。事实上， Smart Scan 只能处理 Join filtering，而真正 Join 的工作必须在 DB Server上完成，而且Smart Scan 仅适合于处理 DSS 环境的复杂 Join，对于 OLTP 类型的简单 Join，Smart Scan 并不能发挥其优势。设想下面的查询：

select e.ename,d.dname from emp e, dept d where and e.ename='Jacky' and e.deptno=d.deptno;

假设采用 nested loops join，Smart Scan 只能完成 e.ename='Jacky' 这个条件的过滤，然后将符合条件的 emp 表的数据返回到 DB server，然后由 DB Server 完成 join 的工作，逐条查询dept表 (e.deptno=d.deptno) 的数据。所以 Smart Scan 并不适合nested loop join（我认为 Smart Scan 只有在适合的条件下才会启用），只有 DSS 环境的大数据量复杂join才会发挥出优势。而且 Smart Scan 只能完成filtering的工作，而不能真正完成 Join 的工作，这个与 Greenplum 数据库是不同的（有兴趣可以看我的文章，Greenplum技术浅析）。设想下面的查询（emp和dept都是大表）：

select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;

假设采用 Hash Join ，由于没有任何过滤条件， Smart Scan 只能把两个表的数据全部返回到 DB Server 上进行join操作，不过 Smart Scan 也不是一点用都没有，至少还可以进行 column 的过滤，只返回需要的字段就可以了。

Oracle 的文档中，曾经提到对于一个大表和小表join时， Smart Scan 会采用bloom filter来快速定位（可以看我以前的文章，有趣的 bloom filter ）。方法是把小表build成为bloom filter，然后在每个storage cell上对大表做scan，利用bloom filter快速定位符合条件的结果，并返回给 DB Server 作 join。

Storage Index

存储索引，顾名思义是在存储级别建立的索引，简单的说就是为表中的每一列数据建立一个索引，每个index entry记录一段数据区间的最大值，最小值以及它们的物理位置，文档上说1MB数据对应一条index entry，见下图：

如果我们查询B<2，或者B>8的数据，根据存储索引，我们就可以跳过这些不在min和max之间的数据块，极大的提高了扫描的速度，这就是存储索引的意义。

Hybrid Columnar Compress

首先我们要搞清楚，什么是行压缩，什么叫列压缩。我们熟悉的数据库，如Oracle、MySQL等都是基于行的数据库，就是行的不同字段物理上存放在一起，还有一种是基于列的数据库，就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出：

基于行的数据库，访问一行非常方便，但是由于同一列的数据是分开存放的，如果要针对某一列进行查询时，几乎要扫描整个表才能得到结果。基于行数据库的压缩，称为行压缩。

基于列的数据库，因为同一列的数据物理上放在一起，所以访问一列非常方便，也就是说如果针对某一列进行查询时，不需要扫描整个表，只需要扫描这一列的数据就可以了，但是访问一行的全部字段非常不方便（又是废话）。基于列数据库的压缩，称为列压缩。

Oracle 通常说的 compress 功能（包括11g R2的Advanced compress），都是行压缩，因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table，然后将相同的值放在那里，每行上相同的数据指向symbol table，以此来达到压缩的目的。行压缩的效果通常不好，因为我们知道行与行之间，其实相同的数据并不多。但是列压缩则不同，因为相同列的数据类型相同，很容易达到很好的压缩效果。

行压缩和列压缩都有其优缺点，而Oracle的混合列压缩技术，实际上是融合了列压缩的高压缩比和行数据库的访问特性，将两者的优点结合起来。Oracle提出了 CU 的概念（compress unit），在一个 CU 内，是一个基于列的存储方式，采用列压缩，但是一个 CU 内保存了行的所有字段信息，所以在CU与CU之间，Oracle还是一个基于行的数据库，访问某一行，总是只在一个 CU 内。每个CU由一些连续的block组成，CU header中记录了每一行的各个列在CU中的分布情况，在混合列压缩模式下，一行通常是跨多个block的。

所以说混合列压缩，结合了列压缩和行访问的特点，即可以提供非常高的压缩率，又很好的保证了基于行类型的访问。

Exadata的另一个重要功能是 IO resource management，如果我们在一个 Exadata 上部署了很多个数据库，可以用它来管理 IO 资源，这里就不作阐述了。

目前，我还没有了解到在国内有 Exadata 的应用，而且资料也是比较少的。希望有机会可以真实的测试一下它的性能，我不怀疑他在 DSS 环境下的表现，但是对于 OLTP 类型的应用，是否真的象 Oracle 说的那么强劲，还有待于验证。

-EOF-

稿件来源。