数据库选型必读.docxVIP

数据库选型必读作者： 畅享网2005-5-9 10:22:06【我要评论】大中小本文关键字： 相关资源 面对品种繁多的数据库技术，如何才能独具慧眼，选中适合自己的数据库产品呢？众所周知，正确的评估、选型与数据库技术本身同样重要。而通常，数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩，关于这一点，业界已经是尽人皆知了。其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。选型的正确方法将使您在面对众多产品时，提高您做出最佳选择的能力。数据库选型时，必须包括下面的五大标准：1. 开发要求 2. 性能/成本3. 数据库运行和管理4. 可升级性5. 总体拥有成本开发要求首先，您需要清楚自己究竟想使用什么开发技术。例如，您是要以ODBC使用.Net，还是要以面向对象技术使用Java？如果您要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）SQL功能有多少？如果您要规划的是OO开发策略，那么数据库支持真正的面向对象吗？它是如何支持的？使用什么标准？在SQL方面，您需要什么功能？数据库支持这个功能吗？有些关系型数据库虽然声称支持对象开发，但实际上并不直接支持。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。另外，您还需要确定自己的前端技术如何与后端进行“对话”。您的业务逻辑是放在客户机一端呢？还是放在服务器一端？您要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（RAD）环境吗？性能/成本测量数据库性能最常见的方法是TPC基准。TPC定义了数据库方案、数据量以及SQL查询。它指出，在这一数据库版本、平台、操作系统版本，以及这一内存和磁盘技术/容量条件下，每项事务的成本是多少 － 其中的事务可以是TPC测试中定义的任何数据库操作。理论上来讲，这类基准旨在提供不同产品间的比较值，而在现实中，方案定义可能无法准确反映您正在挑选的技术的使用的本质情况。其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。另外，您也可以请求在真实的生产环境中进行实际的比较测试，并且该环境应尽量贴近您自己的生产环境。虽然完完全全复制自己的环境不太可能，但您应该能够据此推断出产品的预期性能。最后，在最终接受产品之前，应该以真实的环境对选中的技术执行实际测试或概念验证，这一点尤其重要。数据库运行和管理所有数据库都需要进行管理。数据库管理涉及以下问题： 操作任务：备份、故障切换、灾难恢复，等等； 整理系统：分段、存档； 访问控制：定义、监控； 性能：保持系统在线和优化运行； 数据库方案变更：更改数据库结构、重新索引、数据库同步。有些数据库需要比其他数据库多得多的管理，它通常以一家公司必须雇用的数据库管理员（DBA）人数的多少来体现，这是因为只有雇用足够数量的管理员才能在确保系统运行平稳的同时，又能维持数据库的完整性。需要问的问题包括： 产品需要多少数据库管理员？ 他们负责什么？ 什么任务需要停机？ 停机时间会有多长？ 这些任务的困难/复杂程度有多大？ 执行这些任务需要什么技术？ 这些任务如何管理（现场还是远程）？ 现在有哪些工具可以帮助完成这些任务？ 所有优化措施都可行/容易执行吗？如果您想创建总体拥有成本模型和确定部署后可能产生的开支，那么这些问题的答案至关重要。可升级性随着对数据库应用软件使用的不断增加，很可能某一时刻当前的硬件配置就不够用了，这时您就需要对硬件进行检查。升级可以朝两个方向发展：垂直升级（使用更大/更多的处理器）和水平升级（使用与当前平台同一规格的更多的计算机/处理器）。在考虑可升级性时，应提出以下问题： 业务逻辑能和数据分离吗？ 业务逻辑能拆分吗？ 数据库能分段吗？ 这些任务执行起来容易吗？ 执行上述任一操作后对性能有什么提升？ 如果当前的配置成倍增长，那么性能也会成倍增长吗？ 升级到所需的数量/容量时有哪些体系结构选可以选择？ 我需要对用户接口前端做哪些更改才能接纳这些不同的选择？这些更改有多复杂，需要什么技术？更改的成本是多少？最后一点，同时也是最重要的一点，这类要求在开发和部署方面有哪些需要注意的事项？虽然所有供应商都声称自己提供的是“具有巨大升级空间”的技术，但最重要的还是您要调查高容量升级所引发的直接、间接及隐藏成本。对“服务器群（Server Farms）”一词相关的技术切勿掉以轻心。总体拥有成本总体拥有成本(Total Cost of Ownership)是您做决策时必须正面解决的一个先决题目。当所有过程都结束之后，您不能只因为技术本身的优势就加以部署。您部署的解决方案创建出来的价值应该超过它的