关于数据库集群，云计算的胡言乱语(1)

1. jim gray提出的十二点
2. 数据库集群
3. 云计算和xml
4. 分析：云计算或是数据库集群的终结者

前言
    毕业一年多来，都在从事DBMS复制和集群的开发工作。这是一个充满乐趣的工作。与一般的dbms开发相比，复制和集群的开发，更加贴近计算机领域的发展趋势，所面对的都是当今顶级牛人们考虑的问题：如何开发软硬件，将普通的计算机联合起来，构造一个具有可伸缩性能力的系统：通过将新的机器加入到系这个统中，系统的计算和存储性能获得和加入规模成线性比的提升，同时系统具有容错和永不停机的能力？
    问题非常明确，但是牛人们却吵闹异常。他们在不停的制造概念：分布式计算，集群，网格，云计算...，还喋喋不休地得争论它们的好坏。新的结构和软件不断出现：share-nothing, share-disk, DB2 ICE, ORACLE RAC, Google file System, Google Map-Reduce, hadoop...。所有的这些，对于普通的程序员来说，不啻于是一场灾难。牛人们站在各大公司灯光闪亮的新闻发布台上，不断地往程序员已经够混乱的脑子里面塞进更多东西。面对这个不幸的事实，作为一个普通的程序员，我想只能从历史出发，从本质的需求出发，回到问题的本源，来对这团混沌做一番彻底的探究和审视。当然基于我的水平与牛人们相差十万八里这又一不幸的事实，我所做的只能是大胆假设，小心论证。很多的观点，可能缺少理论或证据的支撑，有些想法可能只是夜不能寐导致的大脑短路，或者是早晨起来面对初升太阳的灵光一现。直觉多于推理。当然，随着工作的深入，更多资料的收集，更多的实验，相信能够对这一问题，给出一个牢靠的认识。 
    在此之前，我暂时在这胡言乱语，大伙也胡看乱拍砖吧。

一. jim gray提出的十二点
    计算机科学家们总是能够让梦想照进现实。这些人大脑里面的东西，总能够很快地变成实实在在的IT产品。1970年，E.F.Codd才发表第一篇关于关系型数据的论文，9年之后，oracle便推出了可以商用的RDBMS软件，其实要不是IBM由于自己的IMS卖得太火而不愿转向关系型数据库，这个时间可能还会大大缩短；1997年，google的两位创始人还在鼓捣网页搜索的关键算法, 人们还不太能够想象，可以从互联网海量的网页上精确且足够快地搜索自己想要的信息，10年后，大家都在享受着搜索引擎给生活带来的便利。
    一年一度的图灵奖颁奖礼上，牛人们在收获行业最高的荣誉并笑纳一笔丰厚奖金的同时，也会表达一下对行业未来的一些看法。其中，给我印象最深的是99年Jim Gray的演讲。在演讲中，Gray提出了十二个问题，现在看来，最近十年间出现的几个技术热点，多少跟这十二个问题中有所关系。其中， Gray所说的世界memex存储器，预言google的搜索引擎，file system等技术。而系统的可扩展性，无差错系统，永不down机等问题，对应了以前炒得火热的集群技术，以及现在炒得更热的云计算技术。
    对于可扩展性，Jim Gray认为，将来的计算机系统，应该具备横向的扩展性。也就是说，对于同一类型的计算问题，当计算量和数据量增加，导致单个节点不能够承担过重的负荷，或提供用户期望的响应能力时，可以通过再增加节点的数量来解决问题，而不是购买更计算能力强大，存储能力更大的节点来解决问题。 对于无差错系统和用不down机等问题，Jim Gray提出了两个非常苛刻的要求：构建一个每天可以被上百万人使用的系统，而系统只需要一个管理人员进行管理；确保系统在一百年的时间内至多只有一秒钟不可用。
 
 二. 数据库集群：Oracle一统江湖
    几乎在Gray发表演讲的同一段时间，Oracle和DB2也面临着使自己的数据库产品具有可扩展性，容错和性能上的需求：IT系统越来越被广泛使用，用户的数据越来越多地保存在数据库中，系统访问量越来越大，用户需要系统不间断地工作，升级时用户不想扔掉以前高价购买的硬件设备...。所有这些需求，靠在单节点上运行DBMS已经不能满足。自然，数据库集群应运而生。
    然而，面对同样的需求，Oracle和DB2却走了两条不一样的路线。2001年Oracle发布的集群产品Oracle RAC，采用的是share-disk结构(共享磁盘结构)，所有的数据都只有单一映像，数据库中各节点访问同一份数据，通过数据块交换来传输并共享数据。同时，通过Data Guard技术，配置一个冗余的RAC集群来保证系统的容错性：当主RAC出现故障时，使应用程序切换到冗余的RAC集群来进行访问。而IBM推出的DB2 ICE采用的是share-nothing结构，既不共享磁盘也不共享内存，各个节点单独承担存储和计算任务。用户数据通过划分的方式，均匀保存在各个节点中，为了支持容错性，一份用户数据可分成多份，分别保存在不同的节点上，当一个节点垮掉时，还可以从另外的节点获得垮掉节点的用户数据。除这两家外，MS的sql server集群，采用的也是share-nothing结构，以及数据划分的方式，只不过其对容错性的支持还不够。
    对于share-disk和share-nothing结构这两种结构的优缺点，一开始oracle和db2两家公司莫衷一是，各有各的说法。但是几年过去了，oracle 的RAC集群春风得意，许多客户纷纷采购，RAC方面的培训班，培训网站热闹非凡。今天你打开oracle technology的主页，都能找得到RAC资料的链接。而ibm的db2集群却偃旗息鼓，悄无声息，甚至在ibm developworks上面也没有关于db2集群的技术资料。在http://bytes.com/forum/thread180706.html中可以看到，05年一个哥们打算采购db2 ice集群，为了了解其性能，先在论坛上发帖询问，是否有人安装了db2 ice集群。3年过去了，大伙只帮他找到db2 ice的tpch测试报告，以及一个号称DB@ ICE customer 写的，但现在已经打不开的链接。
    事情为什么会搞成这个样子呢？share-nothing结构的db2 ice，和share-disk结构的oracle rac相比，技术上究竟差在哪儿？
   
    oracle发布的一份白皮书上是这样说的：
    (详见：technical comparison of oracle real application clusters 11g vs. IBM db2 v9.5 for linux, unix and windows)
1. 系统结构
    DB2采用的是share-nothing结构，但是在物理层次上，DB2集群并不是每个节点都有一个单独的磁盘，而是所有节点共享一个磁盘阵列，因此并不是严格意义上的share-nothing。DB2的share-nothing，更多地是指逻辑层面上的,即：每个节点在运行时，拥有并管理磁盘阵列上面的一部分数据。同时，每份数据会连接到多个node，以支持容错。
    Oracle RAC采用的是share-disk结构,所有节点连接到一个磁盘阵列上。每个节点都能够访问所有数据。但是RAC在数据的并发访问上，采用了比传统的share-disk更先进的技术：传统的share-disk结构，两个节点要同时修改一份数据时，需要利用磁盘IO来进行同步，而RAC中采用了Cache Fusion技术，这是一种是一种保证各节点数据缓存的一技术，当要修改某个数据块时，不是直接从磁盘中取取得数据块，而是通过网络从其他节点的数据缓冲区中获取，通过一定的加锁机制，就能够保证数据的一致性。这种技术，避免了需要通过磁盘IO来进行数据同步，提高了系统的效率。
 这种结构，也称之为share-cache结构。
2. 性能
    从三个方面来比较：
（1）OLTP应用。
     OLTP类型的应用，性能采用吞吐量（单位时间内完成的事务数）或响应时间（处理一个事务需要的时间）来衡量。
    对于Oracle RAC，提交一个事务，只需要在执行这个事务的节点上写一次日志。如果此节点需要其他节点的数据块，通过 cache Fushion技术，能够很快地通过高速网络连接获得这个数据块，而不需要进行磁盘IO。
    对于DB2集群，提交一个事务，采用两阶段提交方式，从而保证数据的一致性。这样，提交一个事务就需要写两次日志，以及需要在各节点之间传送数据和提交命令。另外，如果db2集群数据库中，有的索引，并没有建立分区列上，那么，对于这些索引的修改，就需要在各个节点上进行。
（2）数据仓库和BI应用。
    数据仓库和BI应用，存储以几何级增长的数据供用户查询。同时也提供用户瞬时请求。工作负荷具有复杂，长时间查询的特点。
    DB2集群：DB2集群在BI上面的性能，取决于数据的划分。
    Oracle RAC：RAC引入了一个并行查询体系结构，它通过权衡当前各个数据仓库上的负载来决定并行的程度。RAC在同时执行多个并行查询时，能够提高大型数据仓库的吞吐量，最大程度的利用了可用的资源。RAC并行查询体系结构能够让负载分布在多个节点或处理器上。这个能力使得它能够在尽量让查询在本地执行，减少节点间的通信，从而提高查询性能。Oracle是唯一一个能够利用多节点能力来提供并行查询技术的数据库。
（3）负载均衡的实现。
    DB2集群不能够很好的划分工作负荷，因为DB2工作负荷的划分决定于数据分区。为了划分工作负荷，管理员需要了解数据分区的细节。而且随着数据分别的变化，数据分区需要重新划分。
    RAC不需要划分数据。RAC基于连接池技术提供一个更加动态的方法。1. RAC包含一个负载平衡顾问来监视数据库中的工作负荷，并且提供将负荷放在何地的建议。2. 具有实现事务最优吞吐量的能力，通过JDBC implicit Connection Cache和ODB.net连接池等技术来实现智能化的负载平衡。
3. 可扩展性
    oracle rac的cache fusion技术能够保证，rac集群系统的性能，和系统内节点的规模具有线性比。
    而db2集群的性能，不仅取决于节点的规模，还要取决于数据能否被有效划分。
    在oracle rac中增加一个节点非常容易，在不中断rac工作的前提下，只需要安装新节点的软硬件，以及修改系统的参数即可。
    为db2集群增加一个节点的操作比较繁琐。与rac相比，还需要重新定义数据分区，在各节点之间重新分派数据等。
4. 易部署性
    Oracle RAC比IBM DB2拥有更好的易部署性。
    Oracle RAC，对应用程序提供与单机Oracle数据库一样的视图和操作。应用程序从单机移植到集群时，不需要做任何修改，标准的Oracle的数据管理工具也能够应用RAC集群上。所有的SQL语句，包括DDL语句，数据的一致性约束，数据的备份，恢复操作，对于单机Oracle和Oracle RAC都是一样的。只要你搭建好了RAC集群系统，你就很很容易的通过Oracle 11G企业管理器将应用程序移植到RAC集群。
    与此相反，在DB2上，将应用程序从单机版本移植到DB2集群上面将是一个复杂的任务。为了利用DB2集群的优势，你需要对数据进行划分。DB2集群的性能好坏，取决于你是否正确地划分了数据，使得在做查询的连接操作时，连接操作只需要在单个节点的数据上进行，如果连接操作需要涉及到多个节点的数据，那么DB2集群的性能将大大降低。但是，现实生活中，一个系统可能有成百上千张表，使用DB2集群，你就得首先对所有这些表的数据分别，进行精确的分析，然后定义划分列，对数据进行划分。当应用程序有改变，表的结构改变时，你又得重新分析和划分数据，则将是一件非常痛苦的工作。虽然IBM DB2 V8以来，提供了Design Advisor来帮助管理员进行数据划分，但是绝大多数情况下，这些工作还是需要DBA来手动完成。
5. 可靠性
    一个集群系统应该具备高可靠性。而高可靠性建立在对计划内的停机（设备检修，维护等）和非计划的停机（断电，操作故障等）的有效处理。
（1）非计划的停机处理
    Oracle RAC与IBM DB2相比，对非计划的停机处理有以下优越性：
    1. 对于磁盘故障，RAC具有磁盘自动管理技术（ASM）。ASM通过本地镜像机制，来将各磁盘数据拷贝到一个有一系列共享一个磁盘控制器，称之为失效组的磁盘设备中。这样，当某些磁盘出现故障时，就能够从失效组中恢复出数据。而DB2只能依靠操作系统来处理磁盘故障。
    2. RAC还具有Fast-Start Fault Recovery技术和Fast application Notification技术。使用Fast-Start Fault Recovery技术，可以缩短高负载数据库的重启时间，保证系统在要求的恢复时间内启动。而Fast application Notification技术，则可以保证在很短的时间内，通知用户连接系统出现故障，并将用户连接切换到其他活动的节点。
（2）计划内的停机处理
    计划内的停机指由于数据修改或系统变化而导致的停机。一般发生在数据维护或系统维护时。在一个全球企业型里，计划内的停机对操作造成的影响不亚于非计划的停机。
    因此，处理计划内的停机的最好办法就是：保证不出现计划内的停机。
    Oracle RAC通过Oracle Clusterware和Oracle ASM可以保证，集群系统在升级或者打补丁时，让升级和打补丁操作，自动而且渐进地在各个节点进行，而不需要让集群停止服务。同时，对于操作系统的升级，只要操作系统的型号是经Oracle认证过的，使用Oracle RAC通过Oracle Clusterware和Oracle ASM也可以让操作系统进行自动和渐进式的升级。
   
    从以上论述可以看出，db2采用的share-nothing结构，在理论上，有利于进行真正的并行计算，有利于横向扩展。但是，db2没有考虑到关系型数据的结构和关系运算的特性——关系运算需要大量的连接，选择操作。然而实际应用中，却很难真正做到连接操作不需要涉及其他节点数据，只在本节点的数据中进行。更为重要的是，对关系型数据进行划分的操作，是不能自动化的。需要手工进行。当系统规模很大，表的数量一多，手工对表进行划分，将是一件非常痛苦的事情。特别地，数据划分必须定义划分列。但是往往有些表可能没有主键，或者没有适合划分的列，此时只能在每个节点上保存这种表的全部数据，而在各节点间维持数据的唯一性，肯定会大大降低数据库的性能。
    而Oracle RAC采用share disk结构，所有节点共有一份数据，使得数据的一致性很容易维护，从而使得用户部署，系统扩展和故障处理非常容易；引入了share cache结构和cache fusion这些关键的设计和技术，使得节点获取数据块的速度很快，不会造成性能瓶颈，相对于db2集群来说，虽然由于数据没有被划分，导致理论上的并行计算的效率不高，但是对于关系型数据来说，其实际性能却并不逊色于DB2。反而DB2集群在实际应用上，对于关系型数据，需要处理索引不包含分区列，事务必须进行两阶段提交这样的问题，其实际性能，有时候不如Oracle RAC。
    如此说来，我们对目前Oracle RAC集群春风得意，DB2 ice黯然神伤的状况，基本上就能够理解了。

三 云计算和xml
    虽然数据库集群之争，oracle笑道了最后，却不一定能笑得最好。IBM几年来一直在鼓吹的两项技术：XML数据库和云计算，很有可能，通过改变用户使用习惯的方式，颠覆oracle RAC所建立的巨大优势（玩不过你，咱就改变游戏规则）。
（这个以后再写）。