数据库解决方案对比分析

1、数据库解决方案对比分析对于互联网应用，随着访问量的增加，当数据库数据量达到GB以上时将不可避免的面临数据库性能瓶颈的问题，因此在数据存储方案的选择上对应用的性能、后期扩展等方面将会有很大的影响，下面我将从几个角度对目前主流的几款商用数据库和Dbshards + MySql进行对比，为您的选择提供参考。开放性Ø sql server：只能在windows上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。windows9x系列产品是偏重于桌面应用，nt server只适合中小型企业。而且windows平台的可靠性，安全性和伸缩性是非常有限的。它不象unix那样久经考验，

2、尤其是在处理大数据量的关键业务时。Ø Oracle：能在所有主流平台上运行(包括 windows)。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。Ø db2：能在所有主流平台上运行(包括windows)。最适于海量数据。db2在企业级的应用最为广泛,在全球的500家最大的企业中,几乎85%以上用db2数据库服务器,而国内到97年约占5%.Ø Dbshards + MySql：能在所有主流平台上运行(包括 windows)。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。并行性

3、Ø sql server：并行实施和共存模型并不成熟。很难处理日益增多的用户数和数据卷。伸缩性有限。Ø Oracle：平行服务器通过使一组结点共享同一簇中的工作来扩展windownt的能力,提供高可用性和高伸缩性的簇的解决方案。如果windowsnt不能满足需要, 用户可以把数据库移到unix中。Ø db2：db2具有很好的并行性。db2把数据库管理扩充到了并行的、多节点的环境.数据库分区是数据库的一部分，包含自己的数据、索引、配置文件、和事务日志。数据库分区有时被称为节点或数据库节点。Ø Dbshards + MySql：Dbshards + MySq

4、l具有优秀的并行性。DbShards将数据库拆分为独立子节点，多节点通过Dbshards形成一个透明的数据库集群，任何数据操作都可在独立子节点执行也可多节点并行，每个操作在更小的子节点完成，性能更优。安全性Ø sql server：没有获得任何安全证书。Ø oracle：获得最高认证级别的iso标准认证。Ø db2：获得最高认证级别的iso标准认证。Ø Dbshards + MySql：GNU宽通用公共许可证性能Ø sql server：多用户时性能不佳Ø oracle：性能最高， 保持windowsnt下的tpc-d和tpc-c的世

5、界记录。Ø db2：适用于数据仓库和在线事物处理性能较高。Ø Dbshards + MySql：脱离数据库自身性能限制，通过Dbshards数据拆分技术提高数据I/O性能。客户端支持及应用模式Ø sql server：c/s结构，只支持windows客户，可以用ado,dao,oledb,odbc连接.Ø Oracle：多层次网络计算，支持多种工业标准，可以用odbc,jdbc,oci等网络客户连接Ø db2：跨平台，多层结构，支持odbc,jdbc等客户Ø Dbshards + MySql：多层次网络计算，支持多种工业标准，可以用o

6、dbc,jdbc,oci等网络客户连接操作简便Ø sql server：操作简单,但只有图形界面.Ø Oracle：较复杂, 同时提供gui和命令行，在windowsnt和unix下操作相同Ø db2：操作简单,同时提供gui和命令行，在windowsnt和unix下操作相同Ø Dbshards + MySql：操作简单,同时提供gui和命令行，在windowsnt和unix下操作相同使用风险Ø sql server：完全重写的代码，经历了长期的测试，不断延迟，许多功能需要时间来证明。并不十分兼容早期产品。使用需要冒一定风险。Ø Or

7、acle：长时间的开发经验，完全向下兼容。得到广泛的应用。完全没有风险。Ø db2：在巨型企业得到广泛的应用，向下兼容性好。风险小。Ø Dbshards + MySql：长时间的开发经验，完全向下兼容。得到广泛的应用。风险小。可扩展性Ø sql server：sql server版本杂乱，并且微软公司对其旗下产品的升级、兼容策略存在很大隐患，因此sql server扩展性较差。Ø Oracle： Oracle向下兼容，可扩展性强。 Ø db2：db2向下兼容，但收IMB硬件平台限制，可扩展性一般。 Ø Dbshards + MySql

8、：Dbshards不是数据库，Dbshards是大数据库拆分工具，当性能出现瓶颈时使用该工具对数据库进行拆分优化从而提升性能，扩展成本低。成本Ø sql servern 软件成本：企业版在30-40万左右；作为一款商用数据库软件，存在很多不同的版本，造成使用者在选择时的困惑，并对后期升级造成困难（不同版本互不兼容）；n 实施成本：只能在windows平台下进行实施，当应用存在异构环境时，其实施难度将大大提升，甚至会造成额外的实施成本（如为了能在异构环境中安装sql server，需要购买虚拟机软件来安装windows平台），实施局限且成本高；n 维护成本：sql server作为一款

9、商用软件，其配套的操作工具同样也是商用软件，因此，其产生的并不仅仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；n 扩展成本：对于互联网应用，尤其是云平台集成第三方应用，融合多语言环境是必须面对的情况，而sql server对于第三方和多语言的集成和兼容都需要大量商用软件的支持，因此在平台扩展时同样会造成成本的蔓延。Ø Oraclen 软件成本：企业版在30-40万左右； n 实施成本：Oracle是一款庞大而复杂的数据库软件，操作复杂、难度高，其对实施、维护人员的要求非常高，也就造成了实施、维护的人力成本高昂；n 维护成本：Oracle作为一款商用软件，其配套的操作工具

10、同样也是商用软件，因此，其产生的并不仅仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；并且维护人员成本高；n 扩展成本：Oracle按CPU个数进行收费；当性能出现瓶颈需要版本升级或更换、增加硬件时就必须根据CPU数量购买Oracle授权（企业版一颗CPU授权价格在30-40万左右，最普通的一台服务器CPU数量在两颗以上，也就是说每增加一台服务器Oracle成本将至少增加60万以上），成本将成倍增长。Ø db2 n 软件成本：企业版在60-70万左右； n 实施成本：db2是IBM一款常用于企业应用的数据仓库软件，操作复杂、难度高，其对实施、维护人员的要求非常高，也就造成

11、了实施、维护的人力成本高昂；n 维护成本：db2作为一款商用软件，其配套的操作工具同样也是商用软件，因此，其产生的并不仅仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；并且维护人员成本高；n 扩展成本：IBM在设计db2时专门为其配套一款商用工具PB，因此其在扩展时需要特定专业人才方可实施，有一定局限（中国PB程序员属于小众群体，比较少），扩展成本较高。Ø Dbshards + MySql n 软件成本： 一套40万；n 实施成本：dbShards是一个数据库拆分工具，具有数据库无关性，因此实施成本更低；n 维护成本：作为一款工具具有友好的操作、管理界面，同时安久具有专业

12、的售后服务团队，维护成本更可控；n 扩展成本：作为一款工具软件，其主要作用是拆分数据库，提高数据访问性能，并不会随着数据库的增加而增加，这样从整体上降低了扩展的成本。兼容性Ø sql server：面对复杂应用，需要多数据库集成时，集成能力弱。Ø Oracle：面对复杂应用，需要多数据库集成时，集成能力强。Ø db2：面对复杂应用，需要多数据库集成时，集成能力较强。Ø Dbshards + MySql：Dbshards具有数据库种类、版本无关性，并且支持多语言（Java、C等），因此面对复杂应用，需要多数据库集成时，集成能力最强。什么是DbshardsD

13、bshards不是数据库，Dbshards是大数据库拆分工具，是一套完整的针对大访问量、高并发应用，提高数据库访问性能的数据库优化、加速方案；其核心思想是“share noting，shard erveything”，专业服务、解决数据库水平拆分、解决数据库扩展难题。Dbshards的作用Dbshards的基本思路为“share nothing，shard everything”（“零共享，全拆分”）。这个思路揭示了数据库水平拆分技术的定义：数据库水平拆分将大量行数据按照特定的拆分策略，将数据分别存储于不同的数机器上。每个数据表存储在独立的数据库或者服务器中形成独立的分区，这些分区协同工作，如

14、同一个未被拆分的数据库一样响应所有的用户请求。下图给出了一个实际环境中运用Dbshards的原型系统。数据库拆分就是将大数据库拆分成若干个小数据库Dbshards通过数据库水平拆分技术突破了系统I/O瓶颈，解决了数据库扩展（database scaling）这个行业难题，使得其能够同一时间内响应超量用户请求。不同于传统的数据仓库等技术，Dbshards通过将独立的主机组建为一个透明的数据库集群，使用户请求被均匀分布到各个节点进而实现快速响应。这样的“零共享”架构可以通过最小化单机处理量来缩短联机事物处理的响应时间，进而提高系统整体的可扩展性。 基于既有的经验，我们认为，数据库主要面临下列难题：

15、1) 难题1:快速响应。保证服务器的快速响应以满足大量用户发送的实时请求，尤其当存在大量数据库写请求的时候;2) 难题2:可扩展性。对于数据库服务器而言，本身的I/O瓶颈是服务器扩展中的一大难题;3) 难题3:高可用性。无论是定期的服务器维护还是意外的宕机事件，需要有严格的故障切换机制来保证数据库服务无中断的同时没有数据丢失；为提高数据库的性能，Dbshards严格遵守了数据库的基本原则。实践这些原则也是保证数据库高性能的唯一途径：1) 原则1：数据库越小，数据库响应越快；2) 原则2：数据库越大，数据库响应越慢3) 原则3：始终保证数据库小型化。Dbshards基于“零共享，全拆分”的思路将

16、关系数据按照特定的拆分策略按“行”拆分，并将其分别存储于多个具有相同数据模型的数据表中。每个数据表存储在独立的数据库服务器中作为独立的数据库节点，这些节点协同工作，构成一个数据库集群系统。对于用户而言，这样的系统就如同一个未被拆分的中央数据库一样透明。  图形1给出了一个基于Dbshards搭建的4节点数据库集群架构。应用服务器（AS）上运行Dbshards/Client客户端实现对数据库集群的访问（Dbshards提供各种语言的数据库驱动，包含C，Java，PHP，Python以及Ruby）。每个数据库节点（S1-S4）运行一个独立的数据库（如MySQL），每个数据库有相同的数据模

17、型（Database/Table），系统通过Dbshards备份代理（Dbshards replication agent）和Dbshards查询代理（Dbshards query agent）实现协同工作。数据拆分策略根据具体应用场景、数据库的架构、数据表的定义而定。在这个示例中，我们采用了用户的ID（Customer ID）作为拆分的关键字（Key），采用了取模算法（modulus）来决定含有特定用户ID的行数据该存放到哪个分区服务器中去。Dbshards如何解决难题1：根据数据量，最大化独立数据库服务器的可用CPU和内存等硬件资源。传统的中央数据库将所有的数据存储于同一台服务器上，所有的

18、数据访问请求被响应时共用了同一台机器的CPU和内存等硬件资源。这样的架构会产生大量的硬件资源竞争，降低系统性能。Dbshards的创新在于将相对繁忙、数据量大的数据库拆分为一些小型的分区，将每一个分区部署于独立的服务器上。这样一来，单位数据访问请求的响应可以使用更多的CPU，内存以及硬盘等硬件资源，使得数据库系统整体性能得以提高。对于数据库而言，当数据量增加时，索引以及需要缓存的数据容量会不可避免的递增，这样会直接导致各种数据库查询请求的处理性能下降。基于Dbshards的数据库集群架构这个问题可以得到解决。参见图形2的数据库写操作性能分析结果。 图形2展示了MySQL数据库写操作基

19、于Dbshards的“零共享”集群架构实现了线性的扩展。试验中，通过在亚马逊EC2环境中将"数据库分片"从1台扩展到4台，数据库的写操作效率从2000 INSERT/秒提高到10,000 INSERT/秒，实现了高于400%的增长。在数据库的读操作处理中，通过Dbshards技术可以实现更明显的超线性扩展。Dbshards如何解决难题2：基于各种数据库水平拆分策略将大型的数据库拆分为小型数据分区。    当应用的负载超过单服务器的处理能力时，数据库的性能会受到直接的影响，通过水平拆分横向扩展数据库可以有效的解决这一问题。Dbshards提供基于

20、C、JDBC等标准的数据库驱动，可广泛应用于PHP/Python/Perl/Ruby等开发框架，进而简化采用Dbshards需要的更新操作，尤其不需要重写相关的数据操作代码。Dbshards如何解决难题3：设计中充分考虑可能存在的任何系统错误，通过实时的连续备份策略确保数据的准确性，一致性和可用性。Dbshards复制备份技术是一套完整的针对商业数据库产品的备份技术解决方案。该技术通过采用“带外复制”（Out-of-Band Replication）的异步方式实现高速稳定的数据备份，提高了系统的实时可用性，降低数据操作和数据迁移的延迟。该方案广泛适用于MySQL，Postgres等商业数据库。

21、 如图形3所示，在“带外复制”的执行过程中，每个待处理的写操作事务被并行提交到 “主数据库”（primary database）以及“主数据库备份代理”（primary replication agent）。在主数据库执行该事务将数据写入主数据库中之前，“主数据库备份代理”将该事务发送到“次级数据库备份代理”（secondary replication agent）让其将相同的写操作提交到次级数据库。这样的执行流程保证了任何一个写操作事务同时存在于至少两个数据库服务器上，即便主数据库宕机，我们也能通过次级数据库迅速恢复数据，保证数据库的可用性。为了保证更高的可用性，Dbshards还

22、支持通过“流备份代理”将数据实时的以并行流（parallel streams）的形式写入其他的从数据库或存储系统，如MonetDB。Dbshards的优势Ø 业内第一：Dbshards是业内第一款毋须或仅需对代码进行少量修改即可对现有应用及数据库进行拆分的软件。应用通过Dbshards连接多个数据库（子库），而数据基于一个或多个拆分策略进行分区。Ø 兼容性：Dbshards适用于各种关系数据库和非关系型数据库，例如：Oracle、SqlServer、MySQL、 PostgreSQL、Mongodb。Ø 可扩展性：用户可以根据负载的增加，添加机器以提高性能

23、6; 高可靠性：Dbshards有自动fail over机制，满足用户7*24小时在线服务拆分后的数据库有如下优势：Ø 较小的数据库更易于管理。生产数据库必须进行全面的管理：定期备份、数据库优化和其他常规任务。使用一个大数据库的话，如果仅就完成操作所需的时间而言，实现这些日常任务非常困难。常规表与索引优化可以持续到几小时或几天，某些情况下会导致定期维护变得不那么灵活。通过拆分的方法，每个单独的“子库”可以单独维护。这样，管理更为简单，可以并行执行多个维护任务。Ø 较小的数据库速度更快。拆分的扩展性是显而易见的，它通过在网络中跨子库和服务器的分布式处理得以实现。还有一个较不明

24、显的事实是，每个子库库因其较小的尺寸从而在性能上胜过单个大的数据库。每个子库都有自己的服务器，这样内存和磁盘之间比率大为提高，从而减少磁盘的I/O。这样带来的后果是更少的资源争夺，更优秀的联接操作的性能，更快的索引搜索，以及更少的数据库锁定。因此，不仅拆分后的系统可以扩展到更高级别的容量，而且单个事务的性能也得到了提高。Ø 数据库拆分能够降低成本。大多数数据库拆分方案可以从成本较低的开源数据库中受益，甚至可以从“工作组”版的商业数据库中受益。此外，拆分数据库在商用多核心服务器硬件上工作的很好，而这种硬件的花费远低于昂贵的高端多处理器服务器和昂贵的存储区域网络（SAN）。在许可证、软件

25、维护和硬件投资上节约的综合成本是非常可观的，相比其他解决方案，有时可以节约70或者更多。选择dbShardØ 跨子库事务数据库拆分的其中一个挑战就是如何解决多子库写操作的事务。如，一个按用户拆分的在线游戏，当出现玩家彼此挑战的活动事务时，就需要在不同的库执行写操作。Dbshards直接由数据库驱动支持跨子库的事务，对于特定事务性的SQL语句，为所有子库保持单个事务。这对于应用是透明的。一旦应用发出执行指令，驱动采用专利申请中的复制技术（见Dbshards/复制版）来确保事务在所有受影响子库分发的完整可靠性。Ø 多语言/框架支持Dbshards 为Java应用提供JDBC驱动

26、，兼容所有主流的持久性API及框架，包括Spring JDBC及Hibernate。Dbshards提供本地兼容MySQL的C驱动，替代libmysqlclient，兼容所有主流的脚本语言，包括 PHP, Python 及Ruby ，同时兼容常见的ORM框架，如PDO及 Django。Ø 动态查询拆分Dbshards驱动检查每一个SQL语句，并自动确定执行查询的子库，而需要对现有应用代码的修改则很少。Dbshards为Java应用提供JDBC驱动，为C语言应用或脚本语言（如PHP, Python, Ruby 及Perl）提供本地C驱动。Ø 子库提示有时，应用可能选择覆写Db

27、shards驱动默认的拆分行为。此时，可以在SQL前加条注释，通知Dbshards驱动如何拆分查询。Ø 虚拟子库随着应用逐渐吸引用户而流行，更多的子库可能需要加入， Dbshards将子库键（如，用户id）映射为虚拟子库编号。 虚拟子库的编号是固定的，而且通常相对比较大（类似100或1000）。Dbshards维护虚拟子库与物理子库之间随时间而改动的映射。如，假设有100个虚拟子库，表 user 通过用户ID取模拆分，那么用户ID 1234将映射至虚拟子库34，然后这个映射关系固定。应用可能使用2个物理子库，其中虚拟子库1-50位于物理子库1，虚拟子库51-100位于物理子库2。将来，数据库可以轻松重新拆分为4个子库，其中物理子库1包含虚拟子库1-25，物理子库2包含虚拟子库26-50，以此类推。Ø