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

第第页大型数据库系统设计与功效研究数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

大型数据库系统设计与功效讨论

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

佳的一面，对产品弱点却避开提及或进行遮掩。其实在选择和评估过程中，首要目标是选择一款能够满意甚至超过预定要求的技术或解决方案。选型的正确方法将运用户在面对众多产品时，做出最正确选择。数据库选型需要考虑五大因素：开发要求、性能/成本、数据库运行和管理、可升级性和总体拥有成本。

首先，需要清晰自己到底想运用什么开发技术。例如，你是要以访问传统的关系型数据库？还是要以纯面对对象技术构建j2ee应用平台？又或是需要建设*mlwebservices？假如你要实现的是纯关系型的开发典范，那么实际要运用的受支持的标准〔和非标准〕sql功能有多少？假如你要规划的是面对对象开发策略，那么在原计划里的数据库支持真正的面对对象吗？它是如何支持的？假设有需要,它能同时提供sql的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但事实上并不是径直支持的。这种非径直的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。

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

目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,假如实现的是基于面对对象技术的应用、又或是数据结构更为繁复

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

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

测量数据库性能最常见的方法是tpc基准。tpc明确地定义了数据库方案、数据量以及sql查询。测量的结果是，在特定的操作系统上配置了特定的数据库版本，以及在惊人的硬件条件下每项事务的成本是多少——其中的事务可以是tpc测试中定义的任何数据库操作。

从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些方案又有多少能精确反映并回答你在选择技术时所存在的迷惑？其次，全部技术厂商发布的tpc基准都会超过以前发布的结果。这样，tpc基准在更大程度上反映的是为解决问题而投入的内存和cpu量，而不是数据库性能的任何真实表现。只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。又或是以数据产生针对真实的数据模型，建立出巨大的数据量，再以客户端连接作测试。

这种做法跟试验室中的做法的不同之处有以下几点：第一，试验

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟将来计划的也差不太远；第三，假如是硬件条件一样，我们可以径直看出测试对象跟原来方案有着多少差异。

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

2数据库设计

2.1数据模式设计

在数据库规律设计过程中，为了保证数据库的全都性和完整性，数据库要根据关系数据库的规范化要求设计。满意这些范式条件的关系模式可在不同程度上避开冗余、插入和更新异样问题。在基于表驱动的系统中,基本表的设计规范是第三范式3nf。但是在实际工作中,对于常常需要执行查询、汇总的列,假如按规范化理论设计确定会增加表的连接操作而降低系统性能,这时可以降低数据库对规范化理论的要求，以便满意实际应用操作的需要。所以合理运用冗余会为查询带来很大的好处，比如常常被查询的汇总数据可以在平常工作中就累加好，不需要到查询时再运用如sum之类的函数。

2.2索引设计

索引即将表数据按索引要求而产生有序的数据副本，这样的查询可以在有序表中进行，提高查询数据的速度,改善系统性能。可是运用索引也会耗费磁盘空间,增加开销,降低dml(insert、

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

update、delete)操作执行的效率。因此设计时应尽量选择有用的索引,在提高查询速度和节约存储空间之间寻求最正确的平衡点。数据库服务器对数据进行访问一般采纳下面的两种方式：索引扫描：通过索引访问数据；表扫描：读表中的全部页。当对一个表进行查询时，假如返回的行数占全表总行数的10%到15%时，运用索引可以极大的优化查询的性能。但是假如查询涉及到全表40%以上的行时，表扫描的效率比运用索引扫描的效率高。在详细运用的过程中，要结合实际的数据库和用户的需求来确定要不要索引以及在什么字段上建立什么样的索引。下面给出一些通用的规章：

①在常常用作过滤器或者查询频率较高字段上建立索引；②在sql语句中常常进行groupby、orderby的字段上建立索引；③在不同值较少的字段上不须要建立索引，如性别字段；④对于常常存取的列应避开建立索引；⑤用于联接的列〔主健/外健〕建立索引；⑥在常常存取的多个列上建立联合索引，但要留意联合索引的建立顺次要根据运用的频度来确定。

聚集索引是指行的物理顺次与行的索引顺次相同的索引。一个表只能有一个聚集索引。非聚集索引是指定表的规律顺次索引，行的物理顺次与索引顺次不尽相同，每个表可以有多个非聚集索引。缺省状况下建立的是非聚集索引，但是在一些特定的状况下建立非聚集索引会极大的缩短查询的时间。有大量重复值、且常常有范围查询〔between，，=，=〕和orderby、groupby发生的列，可考虑建立聚集索引，而对于经常修改的列、或者返回小数目的不同值

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

的这些状况应当避开建立聚集索引。

运用聚集索引的最大好处就是能够依据查询要求，快速缩小查询范围，避开全表扫描。比如要返回2022年10月1日到2022年10月1日之间的数据，假如在日期的字段建立了聚集索引，那么数据原来就是根据日期的顺次排列的，只要找到开始和结尾日期的数据就可以了，可以极大的节约时间。而假如运用非聚集索引，需要查到这个时间段中每个日期对应的位置，然后在依据位置存取数据，明显效率很低。不言而喻，运用聚集索引的优势很明显。一个表只能根据一个固定的顺次来存储数据。因此，在建立聚集索引的时候肯定要和实际查询相结合，看哪个字段对于查询贡献大，而且操作不是很经常。

索引有助于提高检干脆能，但过多或不当的索引也会导致系统低效。由于用户在表中每添加一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。所以说，我们要合理运用索引体系，特别是对索引的创建，更应精益求精，使数据库的性能得到更好的发挥。

创建索引可以依据查询业务的不同分为两种:单一列索引和联合索引。单一列索引就是指在表的某一列上创建索引，联合索引是在多个列上联合创建索引。两种索引比较结果如下：

①索引所占用空间:单一列索引相对要小；②索引创建时间:单一列索引相对短；③索引对insert，update，delete的影响程序:单

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

一列索引要相对低；④在多条件查询时，联合索引效率要高。索引的运用范围:单一列索引可以涌现在where条件中的任何位置，而联合索引需要按肯定的顺次来写。最末要留意，对数据量大及运用经常的数据库需要是要用索引优化器来优化索引。

2.3查询设计

从大多数系统的应用实例来看,查询操作在各种数据库操作中所占据的比重最大。很多程序员在开发数据库应用程序时,只着重用户界面的华丽,并不重视查询语句的效率问题,导致所开发出来的应用系统效率低下。因此,如何设计高效合理的查询语句就显得特别重要。

(1)正确地运用索引

正确运用索引可以大大提高查询效率,在条件子句中应尽量考虑有用索引的运用。例如,在同学登记表中,假如创建学号为单列索引,那么查询语句的where子句中应运用学号这个索引,使之成为有用索引。

(2)模糊匹配的避开

like关键字支持通配符匹配，技术上称为正那么表达式。但这种匹配特别耗费时间，尽量避开运用模糊匹配。

(3)子查询合并

子查询合并是将某些特定的子查询重写为等价的多个表的连接操作。子查询合并的作用在于能使查询语句的层次尽可能地减削,从而可提高查询的效率。子查询合并的一般规章为:①假如外层查询

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

的结果没有重复,即select子句中包含主码,那么可以合并其子查询,并且合并后的select子句前应加上distinct标识；②假如外层查询的select子句中有distinct标识,那么可以径直进行子查询合并；③假如内部子查询结果没有重复元组,那么可以合并。

(4)运用临时表优化查询

在涉及相关查询的某些情形中，构造临时关系可以提高查询效率。

3数据库系统配置

3.1硬件系统配置

数据库服务器中最重要的配置参数有内存、cpu和网卡。目前影响最大的是内存。尽可能把数据放入内存，比临时从硬盘中调入内存来的要快的多。假如内存太小，小会造成数据在内存与硬盘之间的经常调入调出，假如内存的占用率超过50%,那就要考虑是否要扩大它。在内存足够大时，系统可以考虑在每天的初始运行时，将数据预装入内存也是一种行之有效的好方法。

3.2功能模块配置

系统无论是c/s架构还是b/s架构。数据信息的系统处理时间都是由三部分组成：数据库服务器处理时间；网络传输时间；客户端处理时间。所以解决系统性能的关键点就在于如何使得这三个时间的总和最小。

在系统中数据库服务器的配置和性能往往是最高。但它的工作也最繁重，要同时应对假设干用户的操作恳求。同时我们留意到有些系

数据库特别是大型数据库的执行效率一贯是困扰系统用户的最大问题。软件项目在设计时,由于测试用例的数据量很小,许多有关执行效率的问题都反映不出来。

统工作可以放在客户端处理，也可以由数据库服务器处理，但怎样安排才好呢？这要详细看系统各组成部分的性能。

(1)如客户端功能弱而数据库服务器技能强，那么有些问题就可以用触发器、自定义函数和视图等形式交给数据库服务器去处理。这样不仅可以减轻客户端压力还带来系统可维护性好的好处。

(2)反之，如客户端处理技能较强，而数据库服务器压力过大的话，有些诸如触发器要完成的工作可以有客户端来完成，如数据验证、自动编号生成、数据统计等这样一些工作可以交与客户端来完成。

(3)充分兼顾网络传输时间。目前的网络特别是互联网络，其流量压力越来越大,峰值越来越经常。为平衡客户端与数据库服务器的工作，有时会将一些半加工的数据在网络上传输，这些数据往往数据量就很大，给网络环节带来压力就大。假如只能传输处理结果而不传输中间数据，这样数据传输时间就最少，但这样平衡客户端和数据库服务器的工作又比较难。所以要详细状况详细分析，充分兼顾网络传输时间对系统的影响。

4数据库性能测试

目前常用的数据库基准性能测试工具是tpcc。关于它的运用方法这里不再赘述。当系统的性能下降以后，我们要分析下降的现象及产生缘由。常见的有：①原本好好的，突然变得很慢；②工作高峰时比较慢；③