我的同事对于网上流传的四大数据库的比较的回应

显示全部楼层 · 2009-10-9 08:28:00

以下的内容是我同事对于某个客户发过来的数据库的比较作出的回应

>这个东西不知道是谁写的，好多东西纯粹是凭空想象出来的。
>
>四大主流数据库比较
>
>一、开放性
>
>1. SQL Server
>只能在windows上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。Windows9X系列产品是偏重于桌面应用，NT server只适合中小型企业。而且windows平台的可靠性，安全性和伸缩性是非常有限的。它不象unix那样久经考验，尤其是在处理大数据库。
>
>2. Oracle
>能在所有主流平台上运行（包括 windows）。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。
>
>3. Sybase ASE
>
能在所有主流平台上运行（包括 windows）。但由于早期Sybase与OS集成度不高，因此VERSION11.9.2以下版本需要较多OS和DB级补丁。在多平台的混合环境中，会有一定问题。
>
>4. DB2
>
>能在所有主流平台上运行（包括windows）。最适于海量数据。DB2在企业级的应用最为广泛，在全球的500家最大的企业中,几乎85%以上用DB2数据库服务器，而国内到97年约占5%。
>
首先，IT行业的任何人都知道实际上不可能存在着“完美的”软件产品的，包括任何的数据库产品和操作系统产品，任何的软件产品都会存在着或多或少的bug，而厂商都会在发现bug之后及时的提供补丁程序给用户以修复bug。
其次，所谓的“与OS集成度”不知道想表示什么，尤其是不知道SYBASE ASE 11.9.2以下版本会由于"与OS集成度不高"而需要较多的OS和DB级补丁的结论从何而来，实际上有部分SYBASE ASE 11.9.2的用户甚至从开始使用到升级到SYBASE ASE新版本之前
都没有安装过任何的补丁程序，以此一点就足以可以表明ASE11.9.2的稳定性。更何况不要说SYBASE ASE 11.9.2版本了，SYBASE ASE 12.0都已经是5年前的产品了，从11.9.2开始到现在，SYBASE ASE已经陆续发布了12.0、12.5、12.5.0.3、12.5.1、12.5.2以及12.5.3等技术更加进步的重要版本，而且即将在9月份发布最新的15.0版本，此时还在提SYBASE 11.9.2以下版本根本就没有任何的意义。
>最后所谓“在多平台的混合环境中会有一定的问题”更是不知道想说什么，一个MIS系统的数据库服务器在选定之后难道还需要经常更换主机平台？而且SYBASE ASE本身都会支持在任何不同平台间的跨平台数据库备份/恢复，实现了其他数据库产品所不能提供给用户的灵活性。同时SYBASE ASE支持所有的主流平台，甚至包括非主流的SGI、Unixware等，而且在所有的平台上都能够找出很多相应的reference作为参考。>
>
>二、可伸缩性，并行性
>
>1. SQL server
>
>并行实施和共存模型并不成熟，很难处理日益增多的用户数和数据卷，伸缩性有限。
>
>
>2. Oracle
>
>并行服务器通过使一组结点共享同一簇中的工作来扩展windownt的能力，提供高可用
>性和高伸缩性的簇的解决方案。如果windowsNT不能满足需要，用户可以把数据库移
>到UNIX中。Oracle的并行服务器对各种UNIX平台的集群机制都有着相当高的集成度。
>
>
>3. Sybase ASE
>
>虽然有DB SWITCH来支持其并行服务器，但DB SWITCH在技术层面还未成熟，且只支持版本12.5以上的ASE SERVER。DB SWITCH技术需要一台服务器充当SWITCH，从而在硬
>件上带来一些麻烦。
>
>4. DB2
>
>具有很好的并行性。DB2把数据库管理扩充到了并行的、多节点的环境。数据库分区
>是数据库的一部分，包含自己的数据、索引、配置文件、和事务日志。数据库分区有
>时被称为节点安全性。
>
>SYBASE 没有DB Switch这个东西，不知道在说什么。
>
>可伸缩性和并行性首先应该从数据库服务器的内核上来讨论而不是先从多节点的结构上来看，SYBASE ASE完全支持SMP结构，能够在SMP系统中配置生成多个引擎，甚至允
>许在所有引擎之间进行分布式的客户连接。引擎也处理自己的磁盘访问，对增加的用
>户数提供了近似线性的伸缩性。SYBASE ASE的内部并行技术（包括并行查询、并行排
>序和并行实用程序）用于优化SMP环境。为了提高响应速度，多线索和引擎被用于执
>行单个查询。一个并行查询的完成比同样的串行查询快15倍。通过使用适当程度的并
>行技术，并行优化器可达到最快的响应时间。
>
>其次，在多节点并行方面，向来分为两个方向：共享磁盘集群和非共享磁盘集群。以
>下分别予以介绍。
>1.共享磁盘集群
>市场上曾采用共享磁盘集群的产品有DEC公司的Rdb和Oracle，以及DB2 on OS/390。
>众所周知，Rdb已经消失了（后来被Oracle收购），而DB2 on OS/390运行在封闭的大
>型机上，必须依靠大量专门的硬件设备。现在运行在开放平台的只有Oracle一家数据
>库采用这种技术了。
>共享磁盘集群是和DEC的OpenVMS集群一起成长起来的，OpenVMS使用共享磁盘硬件，这样在集群里的任何VAX机都能访问阵列上的任何磁盘块。DEC自己的Rdb数据库采用同样的技术，Rdb被Oracle收购后，该技术也被Oracle采用，Oracle的OPS，最初就是
>为OpenVMS集群编写的，这就是OPS以及后来改进的RAC技术都基于共享磁盘的原因。
>根据Hal Berenson的观点（DEC公司Rdb数据库的开发主管），编写共享磁盘数据库软
>件要比编写一个"不共享"系统的数据库软件的开发周期要短许多。
>Berenson说："对于 Rdb，我们采用了与VMS集群相同的技术。加入集群的最简单方法
>不是对数据库系统进行大的修改，而是在数据库系统里使用相同的缓冲系统、相同的
>I/O机制、和相同的锁定架构，如此扩展之后，不管你在哪个节点上运行，你可以确
>保多个实例彼此不会互相干扰。"
>共享磁盘集群有以下的特点：
>
>a)共享磁盘设计里，不管哪个节点正在写哪个磁盘，都要确保集群里所有的计
>算机有完全一致的、全部共享磁盘的映像。解决这一难题的办法是共享的锁管理部件
>，这个部件可以保证在一个时间内，只能有一个节点写入特定磁盘块。但是这个部件
>特别消耗资源。
>b)在使用共享磁盘的时候，如果一个节点需要一个磁盘块，而这个磁盘块又恰
>好在另一个节点的磁盘缓存里，那么第一个节点一般来说，必须从磁盘上再次读取这
>个磁盘块。
>c)伸缩性是共享磁盘设计中无法克服的问题。Berenson 说："我们在Rdb里发
>现的问题是，我们永远无法线性地扩充集群的规模，你可以把规模扩大到3到4个节点
>，但是超过这个界限之后，系统就无法再继续增长。" 事实上，Oracle的集群技术也
>遇到了同样的问题。
>d)受到操作系统的集群的限制，不能够跨越操作系统的集群。
>
>2.非共享磁盘集群
>Sybase、IBM、Informix、Microsoft等主流数据库产品采用的都是非共享磁盘集群技
>术。
>非共享磁盘集群是指集群中的每台节点都独享自己的磁盘阵列，所有的数据分别存储
>在这些节点上。
>当应用程序需要访问这些数据时，各个节点之间采用一种函数传递（function
>shipping）技术，这种技术把查询划分成查询片断，每个子查询被发送到拥有要查询
>的数据集的节点上。每个节点接着访问所有必需的本地磁盘块，把查询结果发送回
>去。
>非共享磁盘集群有以下的特点：
>a)各节点之间没有任何资源竞争，不需要消耗大量的资源来做锁管理；
>b)"不共享" 数据库更好地利用磁盘缓存，因为在本地缓存和本地磁盘资源之
>间，有一对一的对应关系。如果某个磁盘块正好处于某个集群节点的缓存里，那么可
>以一直从缓存里取得这个磁盘块。
>c)由于网络技术的高速发展，网络带宽越来越大，使得获取远程数据非常便宜
>，不管数据在远端的何处。如果数据在缓存里的话，访问速度甚至比访问本地硬盘的
>速度还要快。
>d)伸缩性不受操作系统集群的限制，可以跨越多个操作系统的集群。
>
>
>
>三、安全认证
>
>1. SQL server
>
>没有获得任何安全证书。
>
>2. Oracle Server
>
>获得最高认证级别的ISO标准认证。
>
>3. Sybase ASE
>
>获得最高认证级别的ISO标准认证。
>
>4. DB2
>
>获得最高认证级别的ISO标准认证。
>
>四、性能
>
>1. SQL Server
>
>多用户时性能不佳
>
>2. Oracle
>
>性能最高，保持开放平台下的TPC-D和TPC-C的世界记录。
>
>3. Sybase ASE
>
>性能接近于SQL Server，但在UNIX平台下的并发性要优与 SQL Server。
>
>4. DB2
>
>性能较高适用于数据仓库和在线事物处理。
>
>Oracle公司特别愿意宣传它在TPC的测试结果。它的测试结果确实非常好。但正是在
>这一测试中，因为Oracle公司为了TPC测试专门开发了很多功能，但这些功能不会发
>布到Oracle真正的产品中去，也对真实世界的业务系统没有任何帮助，因此Oracle公
>司受到多方包括TPC测试机构的指责。
>在国内的实际应用中，有很多客户反映Oracle数据库有性能问题。从这些方面可以看
>出两点：Oracle公司在TPC测试上的弄虚作假；以及TPC测试并不能完全真实地反映真
>正客户和现实世界的需求。
>而Sybase公司并不重视这些理论测试的结果。相反，Sybase投入了大量的人力，踏踏
>实实地配合客户做好开发和系统维护的工作，充分发挥Sybase数据库的处理能力。
>MS SQL Server虽然是从SYBASE SQL Server 4.X版本发展起来的，但是经过10多年的
>发展，SYBASE ASE已经到了15.0版本了，说“SYBASE ASE性能接近于 MS SQL Server
>”的结论不知从何而来。
>
>
>
>五、客户端支持及应用模式
>
>1. SQL Server
>
>C/S结构，只支持windows客户，可以用ADO、DAO、OLEDB、ODBC连接。
>
>2. Oracle
>
>多层次网络计算，支持多种工业标准，可以用ODBC、JDBC、OCI等网络客户连接。
>
>3. Sybase ASE
>
>C/S结构，可以用ODBC、Jconnect、Ct-library等网络客户连接。
>
>4. DB2
>
>跨平台，多层结构，支持ODBC、JDBC等客户。
>
>每个公司都有自己的Native连接方式，如SYBASE的OpenClient、MS OpenClient以及
>Oracle OCI，强制一个数据库产品支持所有的连接方式就是一个笑话。SYBASE
>Jconnect就是JDBC的SYBASE实现方式,名字不同而已。
>
>C/S或者多层结构主要指得是整个应用系统采用的结构，大部分时候C/S结构指得是客
>户端直连数据库方式，而B/S结构指得是瘦客户端(Browser)的所有数据、请求交互是
>跟中间件产品(例如SYBASE EAServer、BEA Weblogic等)发生，与数据库服务器之间
>的数据交互由中间件产品完成，因此我们可以看到任何的数据库产品都没有所谓的仅
>支持C/S或者B/S的说法，只要一个系统中的中间件产品能够使用JDBC或者Native方式
>连接到数据库产品上，就可以实现所谓的多层次网络计算或者多层结构。
>
>
>六、操作简便
>
>1. SQL Server
>
>操作简单，但只有图形界面。
>
>2. Oracle
>
>较复杂，同时提供GUI和命令行，在windowsNT和unix下操作相同。
>
>3. Sybase ASE
>
>较复杂，同时提供GUI和命令行。但GUI较差，常常无法及时状态，建议使用命令行。
>
>4. DB2
>
>操作简单，同时提供GUI和命令行，在windowsNT和unix下操作相同。
>
>SYBASE ASE的GUI管理工具SYBASE Central是SYBASE ASE产品的特色之一，从SYBASE
>10.0到最新的SYBASE ASE 15.0不断进行完善以及新功能的增加，简单易用，对大多
>数SYBASE ASE用户的DBA来说，绝大部分管理功能都可以在SYBASE Central中完成，
>事实上，操作简单的MS SQL Server的图形管理工具的发展基础就是SYBASE Central
>的早期版本。
>更何况，现在的SYBASE Central已经使用的是纯Java语言编写的，完全可以在Unix以
>及Windows等所有平台上运行了。
>套用Oracle公司网站上的一句话“只有外星人才会使用IBM DB2”由此可见DB2的管理
>复杂性。
>
>七、使用风险
>
>1. SQL server
>
>完全重写的代码，经历了长期的测试，不断延迟，许多功能需要时间来证明。并不十
>分兼容。
>
>2. Oracle
>
>长时间的开发经验，完全向下兼容。得到广泛的应用。完全没有风险。
>
>3. Sybase ASE
>
>向下兼容, 但是ct-library 程序不益移植。
>
>4. DB2
>
>在巨型企业得到广泛的应用，向下兼容性好。风险小。
>
>SYBASE ct-library是在SYBASE ASE 12.0之前提供给SYBASE开发人员使用的开发包，
>简单易用，帮助详细，跨平台的移植只需要进行简单的重编译和测试就可以了，不知
>道怎么叫做“不宜移植”，并且，SYBASE从ASE 12.0开始就已经提供了新版本的软件
>开发包SYBASE SDK给SYBASE开发人员使用，同时为了保持对习惯于使用ct-library的
>程序开发人员的支持，一直到最新的SDK 12.5中都还保留了ct-library的支持，也就
>是说，如果开发人员或者用户的旧的使用ct-library开发的程序，即使他现在使用的
>SYBASE ASE是12.5版本，也都可以直接使用新的SDK进行编译和运行。而如果要将使
>用ct-library的开发的程序完全升级到使用SDK，要做的大部分工作不过是测试而已
>，而且工作量是完全可控的。
>
>所谓的使用风险不知道为什么会跟程序可移植性联系在一起，使用风险应该从一个软
>件系统的很多方面进行综合评价，例如架构、开发队伍、业务复杂度、使用产品等等
>，同样，跟没有“完美的”软件产品一样，任何系统都不可能没有风险，大小区别而
>已，而数据库产品在整个系统的风险评估中仅仅占一小部分而已。
>
>IBM昂贵的Mainframe主机系统确实在部分银行中使用，但绝对指得不是IBM DB2。并
>且IBM DB2基本上只在IBM小型机平台上有一些reference，在HP、SUN等其他小型机平
>台上几乎没有任何的成功案例，因为太不稳定。

千问 · 2009-10-9 08:28:00

看来回复是Sybase的员工写出来的了。
简单从易用性上来讲，Sybase的sybase central的确有些不尽人意的地方。而MS SQL Server的管理工具则要好用些。不过说起易用性，好像还没有哪个公司的产品能和MS有一拼。
原文纯粹是在扯蛋，回复虽然有些偏向性，但大部分内容还是可信的。

千问 · 2009-10-9 08:28:00

写的挺真实的。。

千问 · 2009-10-9 08:28:00

sybase central不好用, 但是市场上有很多支持SYBASE的工具啊, dbartisan, rapidsql, dboptimizer就很好用.