提起 MapReduce ，第一直觉会想起 Google 的 BigTable + MapReduce 经典组合。MapReduce 已经是大规模集群计算"杀人灭口、居家旅行"的必备之物了。而 SQL+ MapReduce 无疑是充满想象力的，意味着 BigTable 可以用 DB 来替代，DBA 们感觉有戏了。
Greenplum 设计初衷是面向大规模数据分析的，能轻松扩展到 Petabyte 级别，通过 Greenplum 的并行数据流引擎能够让程序员玩 MapReduce， DBA 跑 SQL ，可谓两全其美。
类似的思路已经给数据仓库市场带来了一场革命，Greenplum 的间接竞争对手其实应该是 Hadoop 。Teradata 好日子不多了。
--EOF--
Updated: Aster 也是和 Greenplumn 相类似的架构:
有趣的是，MySpace 采用了 Aster ：
数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。
该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。
如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西 ，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ......
从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL --OEL 也在这个框架内。
iDB - the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。
Oracle 的 RAC 集群是 "Share Storage" 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。
实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。
相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?
流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。
这并非一个会让人多么激动的产品。
--EOF--
附加：价格列表
注：此文首发于 《程序员》杂志 2008 年 7 月刊。
"Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏(MMORPG)中。"Sharding" 姑且称之为"分片"。
Sharding 不是一门新技术，而是一个相对简朴的软件理念。如您所知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是：Sharding。
Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
说起数据库扩展性，这是个非常大的话题。目前的商业数据都有自己的扩展性解决方案，在过去相对来说比较成熟，但是随着互联网的高速发展，不可避免的会带来一些计算模式上的演变，这样很多主流商业系统也难免暴露出一些不足之处。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。
Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。
任何技术都是在合适的场合下能发挥应有的作用。 Sharding 也一样。联机游戏、IM、BSP 都是比较适合 Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小。比如IM ，每个用户如果抽象成一个数据对象，完全可以独立存储在任何一个地方，数据对象是 Share Nothing 的；再比如 Blog 服务提供商的站点内容，基本为用户生成内容(UGC)，完全可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的。
这个 "Share Nothing" 是从数据库集群中借用的概念，举例来说，有些类型的数据粒度之间就不是 "Share Nothing" 的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、卖家会分别与其它用户继续进行交易，这样不可避免的两个买卖家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查询，就会跨越更多的 Sharding ，开销就会比较大。
Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用就会非常复杂。对于跨不同DB的事务，很难保证完整性，得不偿失。所以，采用什么样的 Sharding 形式，不是生搬硬套的。
有的时候，Sharding 也被近似等同于水平分区(Horizontal Partitioning)，网上很多地方也用 水平分区来指代 Sharding，但我个人认为二者之间实际上还是有区别的。的确，Sharding 的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库，甚至跨越物理机器的。（见对比表格）
(转载别忘了此图。注明全文来自 http://www.dbanotes.net)
数据 Sharding 的策略与分区表的方式有很多类似的地方，有基于表、ID 范围、数据产生的时间或是SOA 下理念下的基于服务等众多方式可选择。而与传统的表分区方式不同的是，Sharding 策略和业务结合的更为紧密，成功的 Sharding 必须对自己的业务足够熟悉，进行众多可行性分析的基础上进行，"业务逻辑驱动"。
作为风头正劲的 Web 2.0 网站之一的 Digg.com，虽然用户群庞大，但网站数据库数据并非海量，去年同期主数据大约只有 30GB 的样子，现在应该更大一些，但应该不会出现数量级上增长，数据库软件采用 MySQL 5.x。Digg.com的 IO 压力非常大，而且是读集中的应用(98%的 IO 是读请求)。因为提供的是新闻类服务，这类数据有其自身特点，最近时间段的数据往往是读压力最大的部分。
根据业务特点，Digg.com 根据时间范围对主要的业务数据做 Sharding，把不到 10% 的"热"数据有效隔离开来，同时对这部分数据用以更好的硬件，提供更好的用户体验。而另外 90% 的数据因用户很少访问，所以尽管访问速度稍慢一点，对用户来说，影响也很小。通过 Sharding，Digg 达到了预期效果。
现在 Sharding 相关的软件实现其实不少，基于数据库层、DAO 层、不同语言下也都不乏案例。限于篇幅，作一下简要的介绍。
MySQL Proxy + HSCALE
一套比较有潜力的方案。其中 MySQL Proxy (http://forge.mysql.com/wiki/MySQL_Proxy) 是用 Lua 脚本实现的，介于客户端与服务器端之间，扮演 Proxy 的角色，提供查询分析、失败接管、查询过滤、调整等功能。目前的 0.6 版本还做不到读、写分离。HSCALE 则是针对 MySQL Proxy 插件，也是用 Lua 实现的，对 Sharding 过程简化了许多。需要指出的是，MySQL Proxy 与 HSCALE 各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。
Hibernate Shards这是 Google 技术团队贡献的项目（http://www.hibernate.org/414.html），该项目是在对 Google 财务系统数据 Sharding 过程中诞生的。因为是在框架层实现的，所以有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能搞定，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。
Spock Proxy
这也是在实际需求中产生的一个开源项目。Spock（http://www.spock.com/）是一个人员查找的 Web 2.0 网站。通过对自己的单一 DB 进行有效 Sharding化 而产生了Spock Proxy(http://spockproxy.sourceforge.net/ ) 项目，Spock Proxy 算得上 MySQL Proxy 的一个分支，提供基于范围的 Sharding 机制。Spock 是基于 Rails 的，所以Spock Proxy 也是基于 Rails 构建，关注 RoR 的朋友不应错过这个项目。
HiveDB
上面介绍了 RoR 的实现，HiveDB (http://www.hivedb.org/)则是基于Java 的实现，另外，稍有不同的是，这个项目背后有商业公司支持。
PL/Proxy
前面几个都是针对 MySQL 的 Sharding 方案，PL/Proxy 则是针对 PostgreSQL 的，设计思想类似 Teradata 的 Hash 机制，数据存储对客户端是透明的，客户请求发送到 PL/Proxy 后，由这里分布式存储过程调用，统一分发。 PL/Proxy 的设计初衷就是在这一层充当"数据总线"的职责，所以，当数据吞吐量支撑不住的时候，只需要增加更多的 PL/Proxy 服务器即可。大名鼎鼎的 Skype 用的就是 PL/Proxy 的解决方案。
Pyshards
http://code.google.com/p/pyshards/wiki/Pyshards 这是个基于 Python的解决方案。该工具的设计目标还有个 Re-balancing 在里面，这倒是个比较激进的想法。目前只支持 MySQL 数据库。
Sharding 是一项仍处于高速发展中的"老"技术，随着 Web 2.0 的发展，Sahrding逐渐从比较"虚"的概念变成比较"实"的运用思路，开放源代码软件大潮也给 Sharding 注入新的活力，相信会有越来越多的项目采用 Sharding 技术，也会有更多成熟的 Sharding 方案和数据库附加软件涌现。
你的站点 Sharding 了么?
--EOF--
另，本周末我讲参加这个活动：体验基于OpenSolaris的Web/企业应用，做一个题为《设计可扩展的面向互联网应用的MySQL数据库》的简单分享。欢迎杭州朋友光临指导。
一直以来，Paypal 的技术信息都很封闭的，很少能看到披露后台关于信息架构的东西。
Paypal 当前的数据仓库用的是 NCR Teradata ，32 个节点，50 TB 的数据，耗时三年打造。而整个公司投入在 BI 范围上的资金占据全部 IT 投入的 60%。
之前 Paypal 用的是 Oracle 数据仓库的解决方案，旧的 Oracle 数据仓库环境其实类似生产环境 Schema 数据的镜像。从 Oracle 到 Teradata ，不是简单的迁移，而是完全重构了数据模型，对数据重新清洗并提高数据质量。
因为欧美是依赖信用卡的消费习惯，所以 Paypal 面对的信用卡消费欺诈还是很严重的，一度高达 0.25% 的资损(印象中好像有段时间来自俄罗斯和东欧的欺诈特别多)，这可能也是 Paypal 在数据仓库/BI 上投入重金的一个原因(此外还收购了 Fraud Sciences 公司来减少这方面的风险)。
除了有效提供损益报告，Paypal 的数据仓库还必须即时有效的提供的一个指标叫做 "Funny Mix"，代表信用卡资金交易帐务平衡指标与 ACH(自动化清算所，Automated Clearing House) 帐务平衡。
作为对比 eBay 数据仓库环境每天新进来的数据就有 40TB(和Yahoo! 的DW不相上下)，这样的数据量，处理起来的难度还是有一点点的，据说原来技术人员 90% 的时间要花费在数据清洗上，现在也开始用 Teradata 大集中式数据仓库的模式了。
尽管收集 Paypal 的信息非常不容易，但也希望能挖掘出点有意思的东西来。
--EOF--
广而告之： 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 环境的，数据都是在本地磁盘上。
前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破，SSD 是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。
现在 MySQL 的背后有 Sun ，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务，如果问题出在存储引擎上，MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。
--思路中断，这是这个系列不成熟的第二篇。如果有第三篇，我倒是想写几点关于 MySQL 的设想。
--EOF--
连续看到几个和 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--
前两天在上海参加技术研讨，讨论了关于 MySQL 的一些面向企业级应用的思路，今天和几位同事开会，也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路，算是做个备忘。
首先说明一点的是，我不是说 MySQL 没有大企业级的应用，事实上，可以看到越来越多的成功布署 MySQL 的应用，但是，还不够多，还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较"虚"的东西。
由于 MySQL 自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后，建树不大，而该项目带头人 Jim Starkey 前不久又离开了 MySQL，陋屋偏逢连夜雨。
Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非，Sun 从 Oracle 手里把 InnoDB 买回来。
如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。至于 MyISAM ，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM 根本不行。
MySQL 中，在线对表对象做 DDL 操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。
这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的，比如创建索引，可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题：添加了 ONLINE 关键字)
这个看似是个小问题，但实际上却是对很多人最为困扰的。
谢天谢地，MySQL 6.0 后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本 5 而已。
很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷，比如基于时间点的恢复)。
至于另一个常用来衡量 DB 可扩展性的特性：分区，现在 MySQL 已经能够支持了，尽管实现的的确有点晚。而使用 MySQL 的用户，一般都采取 Sharding 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。
因为是整理思路，这算是这个系列的第一篇。
今天 Oracle 公司 Real-World Performance Group 的 Andrew J. Holdsworth 与 Bob Carlin 来阿里作交流。尽管语言沟通上不是很顺畅，还是讨论的不亦乐乎。Andrew 过去也来过阿里巴巴作交流。
Andrew 今天提到了 GATHER_PLAN_STATISTICS ，这已经是短短一段时间第三次遇到这个 Hint 了，上次看到是在 Lewis 的 BLOG：DBMS_xplan in 10g，第二次在 Greg Rahn (也是 Real-World Performance Group 的成员)的 BLOG：Troubleshooting Bad Execution Plans ，以前或许也看到过，可能忽略了。
这个 Hint 在调查执行计划突变的时候非常有用，执行 SQL 的时候收集额外的统计数据。走投无路的时候，或许能用来救急。
另外一个以前忽略的话题是 CARDINALITY 评估错误引起的错误执行计划。事后查了一下，居然还有个 CARDINALITY hint (对，还有个 CARDINALITY Hint! )能直接指定 CARDINALITY 。
一天的讨论学到了两个知识点，已经很不错了. 这一天比较充实的.
--EOF--
下载 PPT : When to Use the Appropriate Database Technology，第二遍阅读的时候，发现这个 PPT 还是很好的。
