大型数据库系统设计与功效研究.doc

大型数据库系统设计与功效研究 摘要：影响数据库性能是综合性的。包括dbms本身性能、数据库逻辑设计、数据库查询设计及数据库运行环境等。本文分析了数据库性能的影响因素并提出解决方案。从而有针对性解决数据库性能瓶颈因素。 关键词：数据库；索引；自定义函数；tpcc 0引言 数据库特别是大型数据库的执行效率一直是困扰系统用户的最大问题。软件项目在设计时，由于测试用例的数据量很小，很多有关执行效率的问题都反映不出来。但当项目交付使用并运行一段时间后，随数据量增大执行效率将成为突出问题。开发者可能由于服务期已过，也没有精力和兴趣去解决这个“软”性的性能问题。同时执行效率和数据库系统的硬件参数配置和网络参数配置有很大关系，逻辑设计和各种数据库工具的使用将对数据库执行效率将带来确定性的影响。数据库项目设计技巧也会使系统有效避开数据流峰值和瓶颈等不利因素。 本文将对从数据库选型、数据库系统硬件配置、数据库系统结构设计对执行效率的综合影响及相应的量化方式进行研究和分析。 1数据库选型 面对品种繁多的数据库产品，如何才能独具慧眼，选中适合自己的数据库产品呢？正确的评估、选型与数据库技术本身同样重要。通常数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩。其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。选型的正确方法将使用户在面对众多产品时，做出最佳选择。数据库选型必须考虑五大因素：开发要求 、性能/成本、数据库运行和管理、可升级性和总体拥有成本。 首先，需要清楚自己究竟想使用什么开发技术。例如，你是要以ado.net访问传统的关系型数据库？还是要以纯面向对象技术构建j2ee应用平台？又或是需要建设xml web services？如果你要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）sql功能有多少？如果你要规划的是面向对象开发策略，那么在原计划里的数据库支持真正的面向对象吗？它是如何支持的？若有需要,它能同时提供sql的???能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直接支持的。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。 另外，你还需要确定自己的前端技术如何与后端进行“对话”。你的业务逻辑是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（rad）环境吗？ 目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。 测量数据库性能最常见的方法是tpc基准。tpc明确地定义了数据库方案、数据量以及sql查询。测量的结果是，在特定的操作系统上配置了特定的数据库版本，以及在惊人的硬件条件下每项事务的成本是多少——其中的事务可以是tpc测试中定义的任何数据库操作。 从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些方案又有多少能准确反映并回答你在挑选技术时所存在的疑惑？其次，所有技术厂商发布的tpc基准都会超过以前发布的结果。这样，tpc基准在更大程度上反映的是为解决问题而投入的内存和cpu量，而不是数据库性能的任何真实表现。只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。又或是以数据产生针对真实的数据模型，建立出庞大的数据量，再以客户端连接作测试。 这种做法跟实验室中的做法的不同之处有以下几点：第一，试验中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟未来计划的也差不太远；第三，如果是硬件条件一样，我们可以直接看出测试对象跟原来方案有着多少差异。 掌握了以上结论之后，我们应该可以更精明地为所需的性能投入相应的成本。换句话说，我们将能够更准确地预测各种数据库的性能与相应的成本。 2数据库设计 2.1数据模式设计 在数据库逻辑设计过程中，为了保证数据库的一致性和完整性，数据库要按照关系数据库的规范化要求设计。满足这些范式条件的关系模式可在不同程度上避免冗余、插入和更新异常问题。在基于表驱