此为《程序员》杂志投稿。应该刊登在 2009 年第二期。

"预测"不是件容易的事儿，"回顾"就好操作的多。2008 年发生了很多大事，相比之下，数据库技术领域的这些事儿多少有些微不足道。

0) Sun 收购 MySQL

2008 年初第一笔业界大并购，在上一波.com 大潮中 Sun 赚得盆满钵满，在这一波 Web 2.0 大潮中，Sun 还要做 Web 2.0 中的这个"点"(Dot)? 我个人对此并不看好。

这是今年数据库领域的最大的事件，但也仅此而已，一年下来，MySQL 联合创始人 David Axmark 都因为"痛恨每天都要遵守的各种制度"从而离开了 Sun ，而到目前为止也没看到 Sun 针对 MySQL有什么新东西拿出来，倒是狂推预装了各项软件的硬件盒子。前不久发布的 MySQL 5.1 GA 质量更无法让人满意，很多 MySQL 旧将纷纷抱怨，连著名的 MySQL Performance Blog 也不失时机的抛出"MySQL 质量将不再如昔"的论断，大浇冷水。

1) Amazon 推出 SimpleDB

云计算喊了一整年， Amazon 也没闲着，不停地推出新服务。SimpleDB 服务让Jeff Bezos 把手伸向数据库服务，现在仍看不到该服务有大行其道的趋势，但是"提供数据索引与查询的核心数据库功能的 Web 服务" 无疑会逐渐吸引更多潜在的用户。到了年底，Amazon 干脆打出了在一段时间内 SimpleDB 免费的服务来招徕用户，用心良苦。

最近若干分析家下了论断 "未来网络产业将仅剩亚马逊与 Google 两强相争"，的确，Amazon 的技术实力不容小视，在 2009 年相信有更多精彩。

2) 主流存储厂商试水 SSD

让人没料到的是 EMC 作为业界存储领头羊，会率先推出支持 固态硬盘(Solid-State Drives, SSD) 的存储设备，Sun 、HP 等厂商也都不甘落后，纷纷宣布将拥抱 SSD。确实，SSD 的某些特性表现是如此抢眼，很多 DBA 都等着它来解决或者缓解 I/O 问题呢，毕竟这是近年来能看到的最大的硬件领域的突破。"钱能解决的问题就不是技术问题"，可惜，目前光有钱，买回来的 SSD 可能还是解决不了问题。SSD 的可擦写次数问题仍然让很多用户心下狐疑。

相信2009 年会是 SSD 爆发的一年，主流存储厂商都会纷纷推出支持 SSD 的产品。假以时日，SSD 应该不负众望。

3) Oracle 联手 HP 进军硬件领域

今年 Oracle 整体在 DB 方面实在没什么亮点，如果非要说有，那么在 Open World 上亮相的 Exadata Storage Server 倒是值得一提。

微软和 IBM 这一年来尽管都有升级产品推出，但实际上也就是升级产品推出而已，仍看不出什么新生机。其实很多用户已经非常厌倦不停地增加新功能的软件新版本，每发布一个版本不失时机的宣布打破什么 TPC-C 记录之类的事情已经难以引起用户兴奋。如何在廉价硬件上实现大规模平滑扩展是所有的数据库厂商必须要面对的问题。

4）面向列存储的数据库技术

面向列的数据库(Column-Oriented Database)这不是什么新技术，但是非常适合某些数据分析或者统计类的应用需求。常见的RDBMS 都是面向行（Row-Oriented Database）存储的，在对某一列汇总计算的时候几乎不可避免的要进行额外的 I/O 寻址扫描，而面向列存储的DB 能够连续进行 I/O 操作，减少了 I/O 开销，从而达到数量级上的性能提升。

其实在 Google BigTable / Hadoop HBase 中很早就看到这一思想的运用，在过去这一年中，列存储数据库也更多的引起了重视。

5) GreenPlum= MapReduce + SQL

MapReduce ，让很多面向数据分析的 DBA 还是挺眼馋的，GreenPlum 的出现把 MapReduce 和 SQL 有机的衔接起来，给海量数据分析能力带来了新的可能。年末的时候， GreenPlum 又宣布进军中国市场，不知道用户实际接受程度如何。

顺便说一下，GreenPlum 背后的大东家是 Sun。

6) 从 Drizzle 到 Percona XtraDB 存储引擎

MySQL 的生命力不在大公司手中，而是来自开源技术、Web 2.0 网站的需求上。Drizzle 这个"精简 MySQL" 版本的出现多少证明了这一点。Percona XtraDB 存储引擎的推出也值得 MySQL DBA 惊喜。

除此之外，DRBD、MySQL Proxy 与 Memcached 等 MySQL 相关组件的灵活搭配与定制，给用户解决超大规模应用上带来了更大的可能。数据库市场不可能不受经济危机的影响，商业数据库厂商日子要吃紧是可以想见的事情。

7）Hadoop 的生命力

Yahoo! 公司在 2008 年表现不佳，但是 Yahoo! 支持的 Hadoop 项目可是左右逢源，再一次让我们认识到开放带来的生命力。Facebook、Amazon、AOL、阿里巴巴等公司（当然也包括 Yahoo!）都在纷纷构建 Hadoop 集群来解决大规模数据处理与分析问题!。期待在 2009 年 Doug Cutting，这位 Hadoop 项目的带头人不要被 Google 挖角。

N）2009 年会怎么样? 谁知道呢。

--EOF--

后记：这算是 2008 年末的时候数据库技术小观察吧。因为投稿的缘故，现在才发出来。在过去这短时间里，自己一些观点可能也有所变化。如有时间，再做补充或者修订。请注意该文的时效性。

补充：对于 SSD，最近一件重要的事件是 Steve Wozniak 加入了 SSD 厂商 Fusion-IO

Posted by Fenng at 6:43 PM | Permalink | Comments (7)

作者：孙毓波 (AKCMS 作者)

SQLite 是一个类似Access的轻量级数据库系统，但是更小、更快、容量更大，并发更高。为什么说 SQLite 最适合做 CMS (内容管理系统)呢？并不是说其他数据库不好, Oracle、MySQL、SQLServer 也都是非常优秀的 DBS，只不过他们设计目标不同，特性不同，所以只有更适用某个应用场景，没有绝对的好坏之分。

我归纳的中小型站点的CMS的特点如下：

• 1、数据量不超过10万
• 2、日页面访问量不超过10万
• 3、 一部分网站全部生成静态页面，一部分网站实时查询数据库动态访问
• 4、 站长不懂技术，不懂得复杂的数据库维护，只会用 FTP 管理网站
• 5 、个人站点基本上是一个人管理，一般情况下只有一个人在访问后台，没有并发
• 6、 对数据库来说是读多写少，只有在站长访问后台的时候才会写入
• 7、 多运行于虚拟主机，大部分PHP主机均同时支持MySQL，小部分PHP主机需要单独购买MySQL，PHP+MySQL的主机价格较PHP主机价格高。 （以万网为例：最便宜的PHP空间780元，最便宜的PHP+MySQL的PHP空间1150元）
• 8、 多数中小站点的HTTP服务与MySQL部署在同一服务器上

SQLite 的优点在中小网站CMS应用场景下表现突出：

• 1、与MySQL相比，它更彻底的免费，并且没有任何使用上的限制
• 2、非常小巧，PHP5以上版本中无需任何配置即可支持SQLite
• 3、无需单独购买数据库服务，无服务器进程，配置成本为零
• 4、整个数据库存储在一个单个的文件中，数据导入导出备份恢复都是复制文件，维护难度为零
• 5、读速度快，在数据量不是很大的情况下速度较快，更重要的是：省掉了一次数据库远程链接没有复杂的权限验证，打开就能操作

SQLite的缺点在中小网站 CMS 应用场景下被规避：

• 1、并发低 动态访问时当访问量不超过10万PV的时候，SQLite 超过 Access 的并发能力已经绰绰有余；生成静态页后更无需考虑数据库的并发问题
• 2、在大数据量的情况下表现较差 但是中小站点一般情况下数据量不超过10万，而SQlite 在 100 万数据量之下表现还不错，因为省掉了对数据库服务器的远程连接甚至会更快
• 3、写入较慢 默认配置下的 SQlite 的写入速度比MySQL慢了很多，但是 CMS 应用场景的写入操作较少。在插入新文章的时候基本感受不到慢。集中的写数据库操作只有在安装的时候会出现，不过只出现一次，可以忽略
• 4、为已有的表加索引较慢 但是在中小站点CMS中不会有这样的需求，可以忽略
• 5、无法将 MySQL 部署到与前端机不同的服务器上，但是中小站点也没有分开部署的需求

综上所述：在中小站点 CMS 的应用场景下 SQLite 能最大限度的降低建站成本，降低维护难度，又很好得规避了自身的缺点。所以我认为未来支持 SQLite 的 CMS 系统一定会大行其道。

--EOF--

Fenng 注：这是网友来稿，转载请注明本文作者。刊载此文不代表我赞同文中所有观点。其实，我觉得 Berkeley DB 或许也不错。另外，如果一个 CMS 日访问量小于 10 万，通过一些 Web 前端优化，后端的压力就会非常之小。

Posted by Fenng at 8:53 AM | Permalink | Comments (16)

RAID(Redundant Array of Independent Disks)，是现在 SAN 存储的非常核心的概念，可能很多朋友都熟悉的。这里介绍一个比较旧的新词：RAIDb 。所谓 RAIDb 也就是 Redundant Arrays of Inexpensive Databases (Db)。

RAIDb 其实是和 Sharding 技术概念有些地方是相通的。如果看概念上的验证还可以看 MySQL DRBD 的解决方案。 这个概念似乎较早见于 C-JDBC 的设计说明，不过近年来也被一些新的解决方案所引用。(比如sequoia）。

RAIDb-0

表级别. 类似数据库的分区，但 RAIDb-0 是不同表之间，RAIDb-0 不提供容错机制。RAIDb 控制器是整个 RAIDb 的核心。这一组件决定 RAIDb 的可靠性、可用性。

RAIDb-1

DB 的镜像或者复制。也是至少需要两个后端 DB 节点。具备容错机制。和 RAID-1 类似，写操作会慢一点。因为是全复制或者镜像，所以对存储空间的需求是比较大的。

RAIDb-2

部分复制，算是前两种方式的折衷。

RAIDb-1-0

RAIDb-0-1

示意图乍看起来是一样的，RAIDb-1-0 与 RAIDb-0-1 的主要差异在控制器(controller)上。

RAIDb 概念把数据库水平切分的思想抽象出来一个很好的模型。旧瓶装新酒，只要调制合理。

--EOF--

Posted by Fenng at 3:38 PM | Permalink | Comments (3)

封装业务逻辑:存储过程

在商业数据库软件的实践方式上，利用存储过程封装业务逻辑是非常通用的做法(也有很大一部分原因是 IT 架构演化造成的)。MySQL 5 之后也支持存储过程，如果要把 Oracle/DB2 等的就有逻辑迁移到 MySQL 当然不是容易的事情。最好的办法可能是：不在存储过程上动脑筋，在应用层想办法。

谁是"推手"?

让我们回过头来，看看当年 Linux 与 FreeBSD ，为什么 Linux 走入企业市场，而 FreeBSD 仍然算非主流。最为主要的一个原因是 Oracle 选择了 Linux 而不是 FreeBSD ，从而带给 Linux 极大的机会。如果说 Oracle 是 Linux 成功背后的推手，那么今天的 MySQL 推手在哪里? 云计算? 前一段时间可能还不能看的很清楚，不过经济危机倒有可能会给 MySQL 带来大规模部署的可能，如何 省钱，是现在很多企业必须要考虑的问题。。

可裁减的 MySQL

类似 Drizzle 这样经过精简后而用户某种特定应用的形式，相信能够在一些企业内部运用，并且成为主体架构的有效补充。

关于 ZFS

这里可能要修正一下之前的某些看法，在存储层其实 ZFS 是个不错的途径。ZFS 可发挥的空间不小，只是看什么时候能够在 Solaris 系之外的操作系统上跑起来。

用户学习成本

相比其他商业数据库软件，MYSQL 总体学习成本更低，但如果深入到架构层并非易事。至少国内目前仍然大量缺乏 MySQL 好手。如果 Sun 能在 MySQL 的技术推广上继续深挖，相信会有一大批技术人员投入其中。当然，一个企业采用 MySQL 与否，还要看很多因素。但起码要能改变 MySQL 技术人员"很山寨"这个固定的思维模式。

结语：如果非要写个结语的话，还是觉得 MySQL 下一步能有多大的成就，要看 Sun 如何对待这个宝贝。买椟还珠的事情常有。

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

--EOF--

Posted by Fenng at 6:33 PM | Permalink | Comments (15)

提起 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 ：

Posted by Fenng at 6:48 PM | Permalink | Comments (5)

数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。

Exadata Storage Server 架构分析

该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。

如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西 ，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ......

从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL --OEL 也在这个框架内。

名词解释：iDB

iDB - the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。

InfiniBand

Oracle 的 RAC 集群是 "Share Storage" 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。

实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。

HP Oracle Database Machine

相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?

结论

流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。

这并非一个会让人多么激动的产品。

--EOF--

附加：价格列表

Posted by Fenng at 12:27 PM | Permalink | Comments (7)

注：此文首发于 《程序员》杂志 2008 年 7 月刊。

从 Shard 到 Sharding

"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 的应用场景

任何技术都是在合适的场合下能发挥应有的作用。 Sharding 也一样。联机游戏、IM、BSP 都是比较适合 Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小。比如IM ，每个用户如果抽象成一个数据对象，完全可以独立存储在任何一个地方，数据对象是 Share Nothing 的；再比如 Blog 服务提供商的站点内容，基本为用户生成内容(UGC)，完全可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的。

这个 "Share Nothing" 是从数据库集群中借用的概念，举例来说，有些类型的数据粒度之间就不是 "Share Nothing" 的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、卖家会分别与其它用户继续进行交易，这样不可避免的两个买卖家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查询，就会跨越更多的 Sharding ，开销就会比较大。

Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用就会非常复杂。对于跨不同DB的事务，很难保证完整性，得不偿失。所以，采用什么样的 Sharding 形式，不是生搬硬套的。

Sharding与数据库分区(Partition)的区别

有的时候，Sharding 也被近似等同于水平分区(Horizontal Partitioning)，网上很多地方也用 水平分区来指代 Sharding，但我个人认为二者之间实际上还是有区别的。的确，Sharding 的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库，甚至跨越物理机器的。（见对比表格）

(转载别忘了此图。注明全文来自 http://www.dbanotes.net)

Sharding 策略

数据 Sharding 的策略与分区表的方式有很多类似的地方，有基于表、ID 范围、数据产生的时间或是SOA 下理念下的基于服务等众多方式可选择。而与传统的表分区方式不同的是，Sharding 策略和业务结合的更为紧密，成功的 Sharding 必须对自己的业务足够熟悉，进行众多可行性分析的基础上进行，"业务逻辑驱动"。

Sharding 实现案例分析：Digg 网站

作为风头正劲的 Web 2.0 网站之一的 Digg.com，虽然用户群庞大，但网站数据库数据并非海量，去年同期主数据大约只有 30GB 的样子，现在应该更大一些，但应该不会出现数量级上增长，数据库软件采用 MySQL 5.x。Digg.com的 IO 压力非常大，而且是读集中的应用(98%的 IO 是读请求)。因为提供的是新闻类服务，这类数据有其自身特点，最近时间段的数据往往是读压力最大的部分。

根据业务特点，Digg.com 根据时间范围对主要的业务数据做 Sharding，把不到 10% 的"热"数据有效隔离开来，同时对这部分数据用以更好的硬件，提供更好的用户体验。而另外 90% 的数据因用户很少访问，所以尽管访问速度稍慢一点，对用户来说，影响也很小。通过 Sharding，Digg 达到了预期效果。

现有的 Sharding 软件简介

现在 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 各自会带来一定的开销，但这个开销与集中式数据处理方式单条查询的开销还是要小的。

这是 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数据库》的简单分享。欢迎杭州朋友光临指导。

Posted by Fenng at 9:05 AM | Permalink | Comments (10)

一直以来，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--

Posted by Fenng at 10:10 PM | Permalink | Comments (4)

广而告之： 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--

Posted by Fenng at 10:24 PM | Permalink | Comments (5)

连续看到几个和 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--

Posted by Fenng at 8:36 AM | Permalink | Comments (1)