数据库选型的五大要素

千里之行，始于足下让知识带有温度。第第2页/共2页精品文档推荐数据库选型的五大要素数据库选型的五大要素

面向品种繁多的数据库产品，如何才干独具慧眼，选中适合自己的数据库产品呢？众所周知，正确的评估、选型与数据库技术本身同样重要。而通常，数据库厂商都会在性能清单和技术基准表中尽量呈现产品最佳的一面，对产品弱点却避开提及或举行遮掩，关于这一点，业界已经是人尽皆知了。其实在选择和评估过程中，首要目标是挑选一款能够满足甚至超过预定要求的技术或解决计划。选型的正确办法将使用户在面向众多产品时，提高其做出最佳挑选的能力。

数据库选型时，必需考虑以下五大因素：

1.开发要求

2.性能/成本

3.数据库运行和管理

4.可升级性

5.总体拥有成本

开发要求

首先，需要清晰自己毕竟想使用什么开发技术。例如，你是要以ADO.NET拜访传统的关系型数据库？还是要以纯面对对象技术构建J2EE应用平台？又或是需要建设XMLWebServices？假如你要实现的是纯关系型的开发典范，那么实际要

使用的受支持的标准（和非标准）SQL功能有多少？

假如你要规划的是面对对象开发策略，那么在原方案里的数据库支持真正的面对对象吗？它是如何支持的？若有需要,

它能同时提供SQL的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直

接支持的。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。

另外，你还需要确定自己的前端技术如何与后端举行“对话”。你的业务规律是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是迅速应用开发（RAD）环境吗？

目前，实现基于关系型数据库的应用可以挑选传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,假如实现的是基于面对对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓

后关系数据库。它所代表的正巧是关系数据库和面对对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象规律操作的平台。它的浮现已经为传统数据库领域带来了冲击，而在面对对象数据库方面更是广受欢迎。

性能/成本

测量数据库性能最常见的办法是TPC基准。TPC明确地定义了数据库计划、数据量以及SQL查询。测量的结果是，在特

定的操作系统上，配置了特定的数据库版本，以及在惊人的硬件条件下，每项事务的成本是多少——其中的事务可以是TPC测试中定义的任何数据库操作。

从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些计划又有多少能精确     反映并回答你在选择技术时所存在的怀疑？第二，全部技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准在更大程度上

反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真切表现。

以笔者多年所见，惟独在真切的环境中举行实际的比较测试才可以判断出数据库的预期性能及评估所需成本。常用的办法包括平衡移植，把本来的数据转移到类似硬件上的另一套数据库，然后以真切的客户端衔接这套测试对象。又或是以数据产生器针对真切的数据模型，建立出浩大的数据量，再以客户端衔接作测试。

这种做法跟试验室中的做法的不同之处有以下几点：第一，实验中的硬件构架跟你预期的计划不会有太大的差别；其次，所测试的事务在宽度和深度方面跟将来方案的也差不太远；第三，假如是硬件条件一样，我们可以直接看出测试对象跟本来计划有着多少差异。

把握了以上结论之后，我们应当可以更精明地为所需的性能投入相应的成本。换句话说，我们将能够更精确     地预测各种数据库的性能与相应的成本。

数据库运行和管理

全部数据库都需要举行管理。数据库管理涉及以下问题：

·操作任务：备份、故障切换、灾害恢复，等等；

·收拾系统：分段、存档；

·拜访控制：定义、监控；

·性能：保持系统在线和优化运行；

·数据库计划变更：更改数据库结构、更新索引、数据库同步。

有些数据库需要比其他数据库投入更多管理资源，业界通常以一家公司必需雇用的数据库管理员（DBA）人数的多少来

做比较，这是由于惟独雇用足够数量的管理员才干在确保系统运行平稳的同时，又能维持数据库的完整性。

因此，在数据库选型时应考虑以下问题：

·产品需要多少数据库管理员？

·他们负责什么？

·什么任务需要停机？

·停机时光会有多长？

·这些任务的困难/复杂程度有多大？

·执行这些任务需要什么技术？

·这些任务如何管理（现场还是远程）？

·现在有哪些工具可以协助完成这些任务？

·全部优化措施都可行/简单执行吗？

过去挑选数据库时，由于别无他选，大部分项目经理、信息主任在考虑问题时已经不再看重以上因素，理由是不管选哪一品牌的产品，他们还是要长时光地付出同样昂贵的维护及管理费用。而目前市面上浮现的一些新的数据库为行业带来了一定的冲击，除速度和处理能力之外，更重要的是，为信息主任们分担了大部分繁杂的工序，过去一些必定的管理和优化操作，现在全自动完成，已聘请的人力资源可改而投入单位里其他岗位，制造更大的价值。

可升级性

随着对数据库应用软件使用的不断增强，很可能某一时刻当前的硬件配置就不够用了，这时你就需要对硬件举行检查。升级可以朝两个方向进展：垂直升级（使用更大/更多的处理器）和水平升级（使用与当前平台同一规格的更多的计算

机/处理器）。

在考虑可升级性时，用户应首先回答以下问题：

·业务规律能和数据分别吗？

·业务规律能拆分吗？

·数据库能分段吗？

·这些任务执行起来简单吗？

·执行上述任一操作后对性能有什么提升？

·假如当前的配置成倍增长，那么性能也会成倍增长吗？

·升级到所需的数量/容量时有哪些体系结构可以挑选？

·我需要对用户接口前端做哪些更改才干接纳这些不同的挑选？这些更改有多复杂，需要什么技术？更改的成本是多少？

·最后一点，同时也是最重要的一点，这类要求在开发和部署方面有哪些需要注重的事项？

虽然全部供给商都声称自己提供的是“具有巨大升级空间”的技术，但最重要的还是你要调查高容量升级所引发的直接、间接及躲藏成本。对“服务器群（ServerFarms）”一词相关的技术切勿掉以轻心。那些好的数据库所带来的机遇应当基于它所支持的各种主流的操作系统平台，以及研发多年成熟和稳定的网络分布式数据缓冲技术，确保在垂直升级时不用对应用程序做任何修订，更可在不影响日常业务运作的状况下，实时调节服务器群的规模。

总体拥有成本

总体拥有成本(TotalCostofOwnership)是你做决策时必需首先面向的问题。作为一个专业的决策人员，不能只由于

单项优势(如软件价格）就加以采用，所部署的解决计划创建出来的价值理应超过它的成本。

目前的困难在于许多成本和优势都是无形的，因此难以量化并且难以测量。不过，在对评估的各个产品举行TCO审查时，一定要将数量和客观的估量值包括在内。否则不仅对产品的状况把握得不够完整，还有可能导致结论不够全面，从而产生负面结果。需要考虑的一些成本和优势如表1所示。

表1数据库选型中的成本和优势

下面我们来举例说明，假如我们需要在数据库A和B之间举行挑选。在考虑TCO的前提下，我们应当做如表2所示的计算。

表2数据库A和B的TCO计算

从表面上看来，数据库A价格廉价、实施的成本也相对地低一些。但要达到预期的服务水平，硬件和维护的成本却要高无数。相反，数据库B售价昂扬、实施时的风险高一点所以成本也高无数，但由于它的技术水平比较高，相对的硬件和维护成本就要低无数。结果是，数据库B的计划，长远来讲反而更有利。通过以上的假设，说明假如通过TCO审查，我们能更全面地看到事实的真相。

为什么要用关系型数据库而不用非关系型数据库。

1、对于增删改查操作，关系型数据库和非关系型数据库的性能开销基本全都，由于全部表的数据量都十分小，小于百

万级，由于在千万级数据量以下，关系型数据库只要设置了索引，都是十分快的。

2、在性能方面全都的状况下，非关系数据库的缺点在于无法支持动态衔接查询应用，即sql中的join操作，或者说是join效率不如关系型数据库高，另外也不支持分组(group)和统计操作(count/sum/avg等)，在业务系统中存在大量的join操作，比如，报表打印、银行缴费对账、员工、机构、角色、交易、科目、字典等复杂应用都涉及到大量关联，

所以非关系型数据库在这些处理方面不如关系型数据库灵便和性能高，编写的代码可读性和茁壮性也较低。

3、关系型数据库的管理工具，比非关系型数据库的管理工具更丰盛，也更完美。对于数据库的DBA维护而言，关系型

数据库的批量更新、导入、导出、备份、优化等方式和资料都丰盛，对于开发人员的入门门槛，关系型数据库也比较低。

4、关系型数据库的进展历史和稳定性要超过非关系型数据库。

5、既然在性能全