存储优化（精选九篇）
存储优化 篇1
本文结合在实际工作中使用Oracle数据库开发信息管理系统的经验和体会, 着重讨论了Oracle数据存储优化的问题。在MIS (Manage Information System) 信息管理系统中数据的录入存储是很常用的操作。完成数据的录入存储功能通常的做法是直接使用标准的SQL中的Insert语句。如果是批量的数据录入就逐一地执行Insert插入语句。为提高系统的效率, 本文通过创建存储过程, 并定义简洁的数据结构用于系统间参数传递以达到优化的目的。通过优化前后实验数据的对比, 可以发现此项工作具有较高的实用价值。
1 Oracle访问接口OCI
OCI (Oracle Call Interface) 是由头文件和库函数等组成的一套Oracle数据库应用程序编程调用接口。它可用于访问O-racle数据库底层的API。OCI的接口API是完全针对Oracle数据库设计的, 它提供完整的功能集, 能够访问所有的Oracle数据库功能。除了瘦JDBC驱动器外, 其它访问Oracle的接口调用都将被分解为基本OCI调用。OCI支持数据类型、调用约定、语法和大量诸如C、C++、COBOL和FORTRAN等第三方语言。因此OCI接口允许通过使用不同语言定义的本地过程或函数调用, 对Oracle数据库服务器进行访问以创建应用程序。尽管Oracle己经提供了自己的ODBC API驱动程序, 但它仍然鼓励用户优先使用OCI。因为OCI经过优化, 能充分利用Oracle中的高级特性。程序员通过Oracle的OCI函数调用能够快速有效地开发Oracle数据库应用程序。
OCI具备以下特性: (1) 通过有效使用系统内存和网络连接提升系统性能; (2) 在两层客户/服务器或多层环境里使动态会话和事物管理保持一致性; (3) N级验证; (4) 全面支持使用Oracle对象访问外部数据库的应用程序开发; (5) 无须额外的硬件投资, 应用程序就能满足与日俱增的用户和请求服务的需求。
同时, OCI允许使用主程序设计语言操纵Oracle数据库里的数据和模式。OCI以动态连接库 (DLL) 的形式提供了一个标准的库来访问和检索函数。OC1库在运行时能够链接到使用任何高级语言开发的应用程序里。
本文讨论的数据存储过程就是通过Oracle的OCI和DB-Express访问数据库的。
2 标准SQL执行过程的分析
标准SQL的执行过程是由应用程序提交SQL语句到A-DO组件, ADO通过相应的驱动程序、数据源、登陆验证信息等与后台Oracle相连, 并将SQL语句提交到Oracle数据库。Oracle收到SQL语句后, 再编译、执行。如果是查询语句还要返回记录集。此过程可通过图1得到直观体现。
应用程序逐一的执行Insert SQL语句, 执行一条语句的时间:T1
T1=2*TN+TC+TE
其中TN表示该语句在网络上单程传递耗时,
TC表示该语句的编译时间,
TE表示语句的执行时间。
执行n条语句的时间:TA
TA=2n*TN+n*TC+n*TE
优化的目的是缩短用户的等待时间, 即降低TA, 为此问题可转换为降低2n*TN、n*TC和n*TE这三个参数。
3 存储过程的设计
针对参数2n*TN, 由于TN的大小是由网络环境决定的, 所以主要是降低它的系数, 即减少与后台数据库的交互次数。为达到这一目的, 本文使用存储过程, 将多条记录的信息存放到一个字符串作为存储过程的输入参数。这样可以有效的减少与数据库交互的次数。由于数据库中的存储过程是定义在后台数据库上, 已经预先编译成功, 编译时间减少, 所以第二个参数n*TC也会明显的减小。对于参数n*TE, TE会有所增加 (语句变的复杂) , 但是n会明显的减小, 所以对第三个参数也有优化。综上所述, 本文在后台数据库上设计了一个存储过程。其过程为: (1) 接收参数, 该参数是包含所有录入数据信息的字符串; (2) 启动循环, 从字符串中提取操作、数据表名、列名信息; (3) 从参数字符串中提取待录入一条信息, 组装成插入语句; (4) 调用O-racle的一个包的内部函数执行该插入语句; (5) 是否提取完毕所有信息, 是否转到 (3) , 是是结束循环; (6) 捕获异常, 做出响应处理, 结束。
该存储过程需要一个输入参数, 同时为了保证参数的可解释性和高效性, 该输入参数要有固定的格式, 类似于网络通信中桢的结构要求。定义参数结构如图2所示:
实现此存储过程需要用到Oracle的一些重要的包和函数, 例如Oracle中负责处理SQL相关的操作的包DBMS_SQL, 此包中有如下三个常用函数:
(1) DBMS_SQL.PARSE () 函数:用于对SQL语句进行解析; (2) DBMS_SQL.EXECUTE () 函数:用于执行解析过的SQL语句; (3) DBMS_SQL.CLOSE_CURSOR () 函数:用于关闭游标, 意味着执行的结束。
4 实验对比
为检验优化方案的性能, 本文做了两个应用测试程序。一个采用常规的方法完成批量数据的录入, 另一个利用存储过程完成批量数据的录入。常规方法的编程实现就是在一个循环中对逐条数据的提交。而基于上述存储过程和参数结构的编程实现主要是对存储过程的调用。存储过程调用的方法有很多, 本文采用在PL/SQL块中调用存储过程的方法, 其调用过程如下:
在存储过程的实现过程中, 由于输入参数类型Varchar2的长度限制 (该类型可容纳最大的字符数是2000个) , 所以当调用该储存过程插入较多数量的数据时, 需要分次提交。本文根据测试数据的长度, 设置一次提交80条数据。因此上文中提到的三个参数的系数会明显减小, 是从n减小到n/80, 如果n/80不是整数还要加1。
测试应用程序的界面如图3。
为得到有效的测试数据, 此实验完全不考虑其它因素的影响。其它因素包括索引、约束、表中数据量。因为在有索引的时候, 插入数据的同时还要更新索引信息。在有约束的时候, 插入数据之前要校对约束信息。在表中已有数据量很大时, 插入数据不是直接插入到数据文件的尾部, 如果中间有空闲的物理块, 数据会插入到其中, 这样就增加了查询空闲物理块的时间。以上三个因素都会降低插入数据的速度, 所以测试数据不考虑这三个因素, 因此每次测试前都需要清空数据表。
采用上述两种方法, 对每批量的数据作三次实验, 计算平均值, 结果如表1所示:
通过以上数据可以发现, 常规方法录入50条数据, 其耗时是使用存储过程的7.3倍。录入100条数据, 其耗时是使用存储过程的5.3倍。录入200条数据, 其耗时是使用存储过程的5.3倍。录入500条数据, 其耗时是使用存储过程的5.3倍。录入1000条数据, 其耗时是使用存储过程的5.27倍。录入2000条数据, 其耗时是使用存储过程的5.36倍。
5 结束语
通过对常规的录入数据方法的分析, 将提高系统效率的问题转化为优化3个参数的问题。分别编程实现了基于常规方法的批量数据录入和基于存储过程的批量数据录入。通过测试数据发现使用存储过程和定义的数据结构在完成批量数据录入方面, 其执行效率明显优于常规方法。
参考文献
[1]Benjamin Rosenzweig.Oracle PL/SQL by Example.Prentice Hall PTR.
[2]Bill Pribyl.Learning Oracle PL/SQL.O'Reilly.
WIN技巧：虚拟化优化分层存储 篇2
IT 管理人员需要什么来有效地部署、管理和优化分层存储呢?他们需要许多具有各种功能和价位的不同存储系统(很可能来自不同的厂商)，这些系统能够进行分层从而满足不同数据类型独特的和动态的需求。
虚拟化:不仅仅是从物理迁移到逻辑
在IT 管理人员尝试整合不同存储资产(很可能来自多个厂商)以供多个系统和应用使用的过程中，他们面临的第一个挑战就是使服务器和应用程序管理员远离物理配置、重新配置和管理存储资源的复杂性。
应对这些挑战的存储解决方案必须在一个阵列的物理端口、特定磁盘组的数据块和服务器及应用程序需要访问的卷或文件之间引入逻辑提取层(通常称为虚拟化)。
除了基本服务外，存储系统供应商还必须提供底层硬件，这些硬件能够大规模扩展虚拟化解决方案的可伸缩性和灵活性，同时又不牺牲可用性或增加管理开销，
通用数据复制:一致的数据移动和恢复
数据复制是突破现有存储系统限制、进行快速数据移动所必需的关键功能。数据复制功能的部署，连同卷管理的虚拟化，使数据移动、保护和恢复获得了重大改进。IT 管理人员可以更有效地利用已安装的系统，将其作为二级存储来重用DD可以将这些二级存储系统用于本地快速恢复以及固定数据的长期存储，又不牺牲系统的完整性，这样可以大大降低系统总成本。
最重要的是，还可以跨不同存储系统创建一致的数据复制和恢复策略。这样的一致性降低了管理成本，同时在对不同类型企业信息的持续数据保护方面提供了重大改进。
逻辑分区:调整存储以满足动态需求
目前在真正有效的分层存储解决方案中受到较少重视，但终将会被证明至关重要的第三个关键性能是逻辑分区。分区最初是为大型机而开发的，目前也用于许多大型Unix 系统，能够为许多不同的应用任务实现动态且高度可调优的处理资源分配，使IT 管理人员能够最大限度了利用处理器资源，同时仍能确保关键应用在高峰负载时具有所需要的处理能力。分区功能将成为未来几代存储系统必须具备的一个功能。
云同步系统优化云存储 篇3
据刘海峰介绍，云同步也是一种云存储服务，是以客户端软件的方式交付用户使用，它包含同步、备份、共享、发布四大功能。该公司研发的云同步软件采用独特的算法和网络优化技术，在较低网络带宽情况下，能够快速同步大量的文件和数据，同时使用独有的重复数据删除技术，将磁盘需求量降低90%以上，同步数据可以保留无限版本。
此外，云同步软件能够满足数据长期保存、随时可用的核心需求；能够面向企业和运营商定制开发；侧重在数据安全保护方面，重点解决数据传输、数据安全和隐私保护等问题，将数据管理权、控制权从运营商转移到用户。在任何移动设备上安装同步终端软件，就可以在任何地方、任何时间，将数据安全地同步到企业内部数据中心或者云计算中心，甚至是家庭存储设备上。
基于存储共享的数据流查询优化技术 篇4
随着数据库技术的飞速发展和广泛应用, 许多应用领域均出现了一种称之为数据流 (data stream) 的新型数据形式。例如对网络进行监测时的数据包、对股票进行分析时的股票信息、通信公司的通话记录、传感器监测到的各类数据等等。在这些应用中, 部分或全部数据都是以一种连续的流的形式实时到达, 与传统的数据库中的数据相比, 具有以下特点: (1) 数据流中的数据是无界的。 (2) 数据流中的数据是实时到来的。 (3) 数据流中的数据是按序流过的, 对数据只能进行顺序的访问, 系统无法控制数据元素到达顺序。 (4) 由于在有限的存储空间内无法存储无限数据流的全部数据, 因此数据流中大部分的数据在处理后被丢弃了, 数据流上的查询多数只能得到近似的查询结果, 而数据库上的查询则可以得到精确的查询结果。 (5) 系统只能保存数据流全部数据的一个有限子集或统计数据, 并随着数据流上新数据的到来不断进行更新, 这种更新的频度取决于数据流中数据到来的速度, 因此数据流应用对查询处理具有很高的实时性要求。
由于数据流和传统数据库的较大差别, 使用传统的数据库技术无法完全解决数据流的对内存需求无界、连续查询、近似查询等问题, 因此对数据流技术特别是数据流查询技术的研究已成为信息处理与数据库领域的热点和前沿。针对数据流查询优化问题, 分析了数据流查询处理的基本过程和查询共享模型的特点。设计了一种基于共享队列的二级索引作为数据流中间结果的存储结构, 并相应地提出了一种数据流存储共享的迁移算法。
1 数据流查询与优化
数据流上的查询与传统数据库中的查询有许多共同之处, 但有两个明显的区别。
第一个区别是一次查询和连续查询。数据库中的查询主要是一次查询, 而数据流上的查询则更多的是连续查询。如果一个查询提交后, 系统根据当前数据集合的快照给出查询的结果, 则称这样的查询为一次查询;如果查询随着新数据的到来而不断的返回查询结果, 则称这样的查询为连续查询。连续查询注册到系统中后, 除非用户明确的撤销该查询, 否则随着数据流上新数据的到来, 查询将不断的返回查询结果。相对于一次查询, 连续查询具有长期运行的特点。
第二个区别是预定义查询和即时查询 (Ad hoc query) 。预定义查询是在数据流中数据到来之前定义, 该查询注册到系统后, 主要针对数据流后续到来的数据计算查询结果;而即时查询是在数据流已经开始的情况下在线提出, 可能需要参考已经到来的数据, 而这些数据在数据流管理系统中已经被丢弃, 系统只能通过提取和组织流过数据的概要信息来支持即时查询, 因此即时查询一般只能得到近似的查询结果。
目前, 数据流查询处理技术已经成为当前数据库领域新的研究热点, 国外许多数据库研究者正在从事数据流查询处理技术的研究, 并取得了一些研究成果。比较有代表性的项目包括STREAM、Telegraph和Aurora。STREAM是斯坦福大学数据库研究组的一个项目, 其目标是实现一个通用的数据流管理系统, 研究内容涵盖了数据流查询处理的各个方面, 如资源管理、近似查询处理、数据流查询语言的定义等方面。Telegraph是美国加州大学伯克利分校的研究项目, 主要是基于自适应的查询处理技术来处理连续查询, 其中的Tuple Routing和Group Filter技术可以实现多查询操作算子的共享, 有效降低了查询处理的内存开销。Aurora是布朗大学、布兰代斯大学和麻省理工学院三校联合研究的传感器网络中的数据流的查询处理问题。Aurora采用操作符――队列的执行方式, 主要研究查询操作的调度策略、负载脱落技术以及查询结果的QoS等方面的问题。
相对于庞大的源源不断的数据流中的数据元组, 计算机的处理资源 (例如CPU计算资源、内存资源等) 显得十分有限, 如何合理有效地利用有限的系统资源来处理无限的数据流, 并得到尽可能精确的结果, 是提高数据流查询处理效率的主要问题之一。
查询优化技术是解决这一问题的重要途径之一, 可通过合理进行查询调度、实现查询共享等方式加以实现。查询共享主要是通过对查询过程中的重复性操作和存储空间进行适当优化, 在保证数据处理质量的前提下, 提高系统的处理效率, 降低系统的处理成本。
本文主要研究在进行数据流查询过程中, 对相似的中间查询结果如何进行存储共享, 以减少存储空间的占用。针对数据流查询存储共享, 设计了一种基于共享队列的二级索引作为数据流中间结果的存储结构, 并相应地提出了一种数据流存储共享的迁移算法。它在保证对数据流元组的数据进行有效存储、快速索引的前提下, 也为数据共享情况下的迁移提供了一定的灵活性。
2 数据流查询共享
2.1 数据流查询处理的基本过程
CQL语言是目前关系型数据流管理系统中主要的查询语言, 它是从数据库的SQL语言演化而来的。对涉及到连接和聚集等操作的数据流来说, 它们需要两个数据流中的元组全部到来后再进行查询, 这些操作在数据流系统中称为阻塞操作。阻塞操作需要扫描数据流上的全部数据, 而数据流元组是源源不断进入到系统中来的, 是无限的, 阻塞操作永远得不到输出结果。显然, 阻塞操作不适用于数据流的查询处理。解决的方法通常是针对概要数据结构进行查询或对无限的数据流进行抽样, 将查询数据范围限制在一个有限的区间 (滑动窗口) 内查询, 这种查询只能得到近似的查询结果, 是一种近似查询。因此, CQL语言保留了SQL语言的查询语法和关键字, 同时针对数据流增加了两个新的关键字Rows和Range, Rows后接数字n, 表示截取最近到达的n个元组进行操作;而Range后接时间t (时间戳) , 表示截取最近t时间内的元组进行操作, 通过这种方式对数据流进行限流处理。下面以一个简单的实际例子为例, 说明数据流查询处理的过程。
在某通信公司系统中, 设系统中有多个数据流表示实时通话过程中的数据, 其中有帐户信息流、通话信息流, 两个数据流可简单描述如下:
帐户信息流S1 (序号No, 通话号码account, 通话费用fee, 帐户余额balance, 通话时间time)
通话信息流S2 (序号No, 主叫方号码source, 被叫方号码destination, 交换机号switchno, 通话时间time, 通话时长seconds)
如果管理人员想查找通过1号交换机进行通话且通话费用大于100元的通话记录, 采用近似查询, 则需要在S1流的近20000个元组、S2流的近两小时范围内, 做关于S1流通话号码和S2流主叫方号码的连接操作, 要求S2流的交换机号等于1, S1流的通话费用大于100, 则该查询语句为:
Select S1.account, S1.fee, S1.balance, S2.destination
from S1[Rows 20000], S2[Range 2 hour]
Where S1.account=S2.source and S1.fee>100 and S2.switchno=1
在数据流查询中, 查询是连续进行的, 因此未经处理的查询很可能会比经过优化后的查询耗费更多的资源。对于上面的查询语句, 可以进行以下的预处理:
(1) 对查询语句进行词法、语法分析, 使其转变为计算机可以识别的语言。这个步骤跟数据库查询中基本相似。经过这个步骤, 系统已经可以根据识别的查询语言对数据流进行操作。但为了提高整体查询效率, 还需要进行下面的转换工作。
(2) 对查询语句进行转换, 去除嵌套型子句, 使语句变为仅含有投影、选择、连接和聚集的非嵌套简单查询, 避免了一些冗余的查询操作。
(3) 依据数据库系统查询优化的相关理论进行查询的优化操作, 调整操作符的执行次序, 使其变为操作次数最少的, 即根据查询的需要在查询中插入投影操作符, 过滤掉不需要的属性, 并将选择、投影等减少元组个数和元组字段数的操作尽可能前移, 从而使不符合查询条件的元组和字段在查询前期就被系统过滤掉, 减少操作的元组数和字段数。
(4) 根据转换和优化后的查询语句, 系统生成语法查询树, 即用机器语言表达用户查询计划的树型结构, 如图1所示。在这棵查询树中, 有两个顺序窗口操作符O1和O4, 分别对到达系统的数据流S1和S2添加元组时间戳, 并获取固定数量的元组, 然后选择操作符O2和O5分别对两个数据流中的元组进行过滤, 获得交换机号为1且通话费用高于100的元组, 投影操作符O3和O6分别对S1流和S2流中查询用到的属性进行投影, 使S1流和S2流中的元组数量均明显减少。然后, 再用最少数量的元组通过连接操作符O7进行资源开销较大的连接操作, 最后通过投影操作符O8得到符合查询要求的属性集合, 得到最终查询结果。
最后, 对于查询语法树中每个节点, 也就是每个操作符, 系统需要为其分配存储和计算资源, 并对操作符进行调度, 得到动态查询结果。在上述例子中, 查询中系统分配资源情况如图2所示。
在图2中, 每个存储队列表示系统为每个操作符所分配的中间存储器, 类似滑动窗口, 用tmn表示;每个圆圈表示操作符, 用On表示。系统中的数据流S1和S2进入系统后, 直接存储在队列tm1和tm5中。操作符O1从tm1中获取数据, 进行处理, 并将结果保存在tm2中。以此类推, 每个操作符在处理时, 均从前一个队列中取得数据, 将结果输出到下一个队列中。而连接操作符O7对tm71和tm72中的元组进行连接操作, 输出到存储区tm8中。最后处理结束的元组存入存储区tmo中, 并最终作为查询结果输出。
2.2 数据流查询共享
数据流查询处理是以查询操作符为基本单位的。进入系统的每个元组必须经过所有的查询操作符后, 方能输出查询结果。因此, 每个元组在等待相应查询操作符处理时, 会被存储在相应的查询操作符队列中。在有些情况下, 这些队列中的元组数是大致相同的。例如, 投影操作符仅是将元组的相应属性组成新的元组输出到下一个查询操作符的等待队列中, 元组的个数并没有改变。对于选择率接近于1的选择操作符 (这里的选择率指通过该操作符执行后输出元组的个数与输入该操作符元组个数的比值) , 经过其处理的元组的构成和处理前没有太大变化。而在一般的数据流查询处理过程中, 这些构成相似的中间处理结果将会被分别存储并处理, 浪费了系统的存储空间。同时, 在存在多个查询语句的数据流管理系统中, 会存在对于相同的数据流中间存储结果进行处理的多个操作符, 而这些操作符多半是选择或投影操作符, 因此其查询处理过程也有很大的相似之处。因此, 如果能将这些相似的结果采用共享的方式进行存储, 不仅能够节省系统的存储空间, 而且能够提高系统的处理效率。因此, 查询共享研究的目标就是如何对数据流查询处理中的相同或相似部分进行查询共享或存储共享, 以达到一次处理、多处获益的效果。
在设计查询共享模型时, 需重点考虑和解决以下几个问题: (1) 发现共享, 即如何从系统的数据流查询条件和存储结构中发现那些适合于共享处理的元组, 比如元组是否具有相似的中间存储结构和相似的查询操作符; (2) 共享的结构和算法设计, 即设计相应的数据结构和算法, 完成数据流相关结构共享的要求; (3) 相关处理, 即如何处理好数据流查询中共享部分与非共享部分的连接, 从而在数据共享的情况下保证数据流查询处理的有效性和执行速度。
目前典型的数据流管理系统STREAM系统和Aurora系统中, 都有一定的数据查询共享的应用。STREAM系统在查询处理中为每个查询操作符分配了临时处理区, 用于存储操作符所需要处理的元组。基于各个操作符处理区元组的相似性, STREAM系统设计了共享大纲的内存共享方式, 并在此基础上, 实现了共享与独占相结合的元组管理方式。Aurora系统在内存管理时引入了队列共享的机制, 给每个操作符维护处理元组在队列中的头和尾指针, 使得数据流为多个操作符共享。这些系统中共享的元组通常通过索引的方式进行存储, 可以保证数据检索的速度, 但通常会出现数据迁移不够灵活的问题。由于数据流系统中数据流动频繁, 因此数据的迁移会不断进行, 如果因为数据的共享而增加迁移的开销, 也会影响系统查询处理的效率。
3 数据流存储共享设计
3.1 存储共享模型
针对上面的分析, 以队列为基础, 采用共享队列的二次索引方式来实现数据流元组的存储。它在保证数据一次索引的前提下, 同时为数据共享情况下的迁移提供了一定的灵活性。该数据队列的引用方式如图3所示。
图3中, S1～S4分别代表不同的数据流中间结果存储队列, 通常这些队列中含有一些相同的中间处理元组。如果将这些元组直接存储在这些中间队列中, 则相同的元组可能会在多个中间队列中重复出现, 浪费了有限的存储空间。因此, 考虑将元组统一存储在队列S中, 而S1～S4只存放和维护这些元组在队列中的索引。
为解决数据迁移的灵活性问题, 在元组队列S和中间结果存储队列S1～S4之间又增设了一个中间索引地址队列S′。在S′中存储队列S中元组的地址, 而S1～S4中只存储指向S′中这些地址的指针。这样, 当进行数据迁移时, 仅需要改动S′队列中的内容, 而不需要频繁地变更队列S1～S4中相同的内容。
通过数据流队列S和相应地址队列S′互相索引, 既可以实现数据迁移时元组的地址在S′中的动态改变, 而且操作符控制的数据中间处理结果队列通过对S′地址的索引完成, 从而间接索引到S队列中的元组, 使得数据迁移具有了一定的灵活性。
3.2 数据迁移算法设计
定义如下变量:指向元组的指针q, q′, 共享元组队列首地址S;共享元组索引地址队列首地址S′;临时指针p。
首先定义如下函数:
GetTupleReference (q) :用于获得q指向元组的引用计数。
GetTupleAddress (q) :用于获得q指向的元组在S′队列中地址索引的地址。
Copy (q, q′) :将q指向的元组内容复制到q′中。
具体的数据迁移算法如下:
q = NULL, q′=S;
for (;GetTupleReference (q′) !=0;q′++) ;//跳过紧凑排列的有效元组
for (q=q′;GetTupleReference (q) ==0;q++) ;//找到无效元组后的第一个有效元组, 并初始化q
while (q!=NULL)
{
Copy (q, q′) ;
P=GetTupleAddress (q) ;*p=q′;
for (;GetTupleReference (q′) !=0;q′++) ;//寻找下一个无效元组的位置
for (q=q′;GetTupleReference (q) ==0;q++) ;//寻找下一个有效元组位置
}
在算法运行过程中, 需要根据中间结果队列对元组的引用情况进行引用计数, 当计数减至0或者元组时间戳超时表示元组可以被抛弃, 需进行复位操作。数据迁移由系统每隔一定的时间进行, 将进行复位操作后的元组删除, 同时将有效元组做紧缩处理, 同时更改队列S′中的地址内容。
4 结束语
本文针对数据流查询优化设计的共享队列二级索引存储结构, 能够通过索引的方式将相同的存储中间结果集中存储, 从而减少了系统的开销;同时利用中间索引地址队列间接索引数据队列中的元组, 又使数据迁移具有了较大的灵活性。
参考文献
[1]Babcock B, Babu S, Dater M, et al.Widom.Models and issues indatastream[C].Proceedings of 21st ACM Conference, Madison, Wisconsin, USA:2002:1-16.
[2]Babu S, Munagala K, Widom J.Adaptive Caching for ContinuousQueries[C].Proceedings of ICDE 2005, April 2005:118-129.
[3]金澈清, 钱卫宁, 周傲英.流数据分析与管理综述[J].软件学报, 2004, 15 (8) :1172-1181.
[4]Avnur R, Hellerstein J M.Eddies:Continuously Adaptive QueryProcessing[C].Proc.Of ACM SIGMOD Conference, 2000:261-272.
[5]袁锋, 宋宝燕, 武珊珊, 等.数据流查询处理中一种共享的分级窗口维护策略[J].小型微型计算机系统, 2005, 26 (12) :2227-2232.
[6]Terry D, Goldberg D, Nichols D, et al.Continuous queries over ap-pend-only databases[J].SIGMOD Record, 1992, 21 (2) :321-330.
[7]MAIER D, TUCKER P A, GAROFALAKIS M.Stream data manage-ment[M].Berlin:Springer-Verlag, 2005.
[8]GOLAB L, OZSUMT.Issues in data stream management[J].SIG-MOD Record, 2003, 32 (2) :5-14.
[9]ARASUA, BABCOCK B, BABUS, et al.Characterizing memory re-quirements for queries over continuous data streams[J].ACMTransOn Database Systems, 2004, 29 (1) :1-33.
[10]杜威, 邹先霞.基于数据流的滑动窗口机制的研究[J].计算机工程与设计, 2005, 26 (11) :2922-2924.
优化的低存储NAF标量乘算法 篇5
椭圆曲线加密[1,2]是目前流行的加密算法,相比于其他的公钥密码算法,它具有密钥的长度更短,安全性更高,加密速度更快,存储空间更少,带宽要求更低等优点,已广泛应用于数据传输中的加密和解密、密钥交换、数字签名等诸多方面。椭圆曲线加密的核心运算是标量乘法,消耗大量的运算时间,直接决定了椭圆曲线的加密效率,影响了整个椭圆曲线加密系统的性能。本文介绍了非相邻的NAF标量算法,分析研究了基于窗口的NAF标量乘算法,该算法需要额外的空间存储预计算的结果来换取运算时间,提出了低存储滑动窗口NAF标量乘算法,减少了预计算的结果,缩短了滑动窗口标量算法预计算的运算时间,以至减少了算法总体的期望运算时间。同时,有效地降低了存储空间,优化了滑动窗口标量乘算法的性能。
1 NAF标量算法
1.1 标量乘法概述
椭圆上的一点G与随机的一个大整数K的乘积,Q=KG= G+G+…+G,一共有K个G相加,称这样的运算叫做椭圆上的标量乘法[3]。标量乘法是椭圆曲线加密中最基本的也是最消耗时间的运算;因此,提高标量乘法运算速度是提高椭圆曲线加密效率的关键。通常情况下,标量乘法的实现方法都是基于对随机的大整数K进行一定的转化操作,目标是尽量减少点加运算的次数。NAF算法[4]是效率最高的一种优秀的标量算法。它类似于二进制的编码,主要是通过对K编码进行优化,目的是减少比特位中为1的比特值的数量以减少点加的次数。滑动窗口法减少点加的方法是通过直接跳过比特值为0的比特位。
1.2 NAF表达式
设G=(x,y)是安全椭圆曲线上的一点,若该曲线所在的基域的特征值大于3,则点-G=(x,-y);若该基域的特征值等于2,则-G=(x,x+y)。所以,如果在对随机的大整数K编码转化时用带符号的表达形式,必定会减少点加的运算次数。设K的比特长度为l,则
NAF表达式的计算方法[6]和二进制的表达式计算方法十分相似,都是对大整数K不断地除以2,得到的余数可以是0,1或者-1,直到最后除尽为止。
输入:随机的大整数K,输出:Kj-1,...,K0。其中,Kj={0,1,-1}。
NAF表达式计算流程图如图1所示,利用以上的流程图计算:K=31 NAF(K)=100 001-。其中1-代表-1。
2 基于滑动窗口的NAF标量乘算法
NAF标量乘算法运行所需要的时间主要由倍点和点加这两个运算操作的时间决定。倍点运算的时间主要是由NAF表达式中比特位的长度决定,点加运算的时间则是由NAF表达式中比特值为非零值的个数决定。基于滑动窗口的NAF算法[7]主要是通过将NAF表达式中的多个1合并,减少点加的次数以提高点加运算的时间,但是,同时也增加了预计算和占用了存储空间。
该算法是一种动态地查找窗口的方法,它的基本操作是先设置一个固定窗口值,然后从左到右逐位查找,若遇到的特征值为0则直接倍点,然后跳过,直到遇到的特征值为非零值时才开始从最大窗口查找,若在最大窗口下查找的最后一位为0,则向内收缩,直到遇到非零值则停止查找。这样可以跳过两个连续的窗口之间的连续0位,直接进行倍点运算。
在滑动窗口算法中,首先要进行预计算,并存储预算法的值。根据椭圆曲线求逆的定义,当特征值大于3时,G=(x,y),则- G=(x,-y),所以只需要预计算正数部分。同时由于窗口的大小可以在最大窗口值与1之间动态地变化,为了节省存储空间,我们可以只对窗口内的奇数值进行计算。我们对大整数K进行NAF编码,利用滑动窗口算法进行运算。具体的算法描述如下:
输入:窗口值w,大整数K,点G。输出:Q=KG。
(1)预计算:对于任意的i={1,3,5,…,{2[2w-(-1)w]}/3-1},Gi=iG。
(2)赋值i=l-1,Q=0。当i≥0时,重复执行以下操作:
(2.1)若Ki=0,则t=1,u=0;
(2.2)否则找到最大的t≤w的t,满足u=(Ki,…,Ki-t+1)为奇数;
(2.3)Q=2tQ;
(2.4)若u>0,Q=Q+Gu;
若u<0,Q=Q-Gu。
(3)i=i-t,重新转到(2),判断i。
算法的流程图如图2所示。
性能分析:运行时间方面:该算法期望的运行时间是以下两部分运行时间之和:
(1)预计算的期望时间:决定于预计算的最大值X={2[2w-(-1)w]}/(3-1),预计算最大值需要(X-1)/2次的点加和1次倍加。即1D+{[2w-(-1)w]}/(3-1)A。
(2)主运算的期望时间:(l-1)D+{l/[w+
v(w)]-1}A。
其中:v(w)=4/3-(-1)W/(3*2W-2)[8],表示0在窗口移动的平均长度;A表示点加运算;D表示倍点运算。
存储空间方面:该算法预计算的存储空间:(X+1)/2,即{[2w-(-1)w]}/3个。
3 低存储的NAF标量算法
基于滑动窗口算法不管是在存储空间上还是在运算效率上都优越于其他的标量算法。但是滑动窗口技术需要额外的空间存储预计算值,窗口越大,预计算值就会越多,占用的存储空间就会越大。鉴于以上的问题,既要保持滑动窗口运算效率又要尽量少的减少预计算值的存储空间,我们提出了一种低存储滑动窗口NAF标量乘算法。该算法的基本操作是:利用滑动窗口的技术在按照最大窗口查找时,窗口在向内缩的时候,如果在缩到一半的时候还可以继续向内缩进,则不再继续向内缩进的操作,直接进行一次倍点和一次的点加操作后,向后移动一位继续按照最大窗口查找。这样,在预计算的时候只需要计算和存储2/w到w窗口之间的预计算值即可,减少的存储空间。
输入:窗口值w,大整数K,点G。输出:Q=KG。
(1)预计算:对于任意的i={[2w-(-1)w]/3-1/2…{2[2w-(-1)w]}/3-1},Gi=iG。
(2)赋值i=l-1,Q=O。当i≥0时,重复执行以下操作:
(2.1)若Ki=0,则t=1,u=0;
(2.2)否则找到最大的w/2<t≤w的t,满足u=(Ki…Ki-t+1)为奇数。若找不到,则令t=1,u=1。
(2.3) Q=2tQ;
(2.4)若u>0,Q=Q+Gu;
若u<0,Q=Q-Gu。
(3) i=i-t,重新转到(2),判断i。
(4)输出Q。
算法的流程图如图3所示。
性能分析,运行时间方面:低存储滑动窗口相对于滑动窗口,假设窗口大小为w,减少了{1,3,5,…,2(w/2)-1}预计算时的点加和倍点的运算时间。提高了与计算的效率,降低了算法总的期望运算时间。
存储空间方面:假设窗口大小为w,滑动窗口需要存储窗口w内的所有预计算点,低存储滑动窗口只需要存储w/2到w窗口内的预计算点,减少了{1,3,5,…,2(w/2)-1}个存储空间,提高了存储空间的利用率。数据分析如表1所示。
4 总结
椭圆曲线密码体制是目前最流行的一种公钥密码体制,标量算法是决定椭圆曲线密码体制执行速度的关键因素。本文通过对基于滑动窗口的NAF标量乘算法进行了简单的介绍,从算法的运行时间和存储空间两方面考虑,充分利用了NAF算法对大整数编码时的优越性和滑动窗口技术,提出了一种改进的标量算法即低存储滑动窗口NAF标量乘算法。实验证明,优化后的NAF标量乘算法减少了{1,3,5,…,2(w/2)-1}个预计算值的计算时间和存储空间。
参考文献
[1]姚剑波,张涛.抗侧信道攻击的安全有效椭圆加密算法.计算机应用研究,2012;29(12):4639—4643
[2]陈熹,祝跃飞.一种高效安全的椭圆曲线标量乘算法.计算机工程,2012;38(18):103—106
[3]李忠,彭代渊.低存储需求的快速标量乘法算法.计算机工程,2012;38(4):137—139
[4]沈学利,张龙华,姜丽.NAF标量乘算法的改进.计算机仿真,2010;2(27):316—319
[5]王细萍,谭文学,潘梅森.商务安全中随机窗宽的椭圆标量乘快速方法.计算机工程与设计,2011;32(9):2957—2960
[6]陈军,赵建民.抗能量攻击的新标量乘算法.计算机应用与软件,2012;(4):137—139
[7]蒋洪波,尚春雨,冯新宇.NAF算法的改进.科学技术与工程,2012;12(19):4663—4666
存储优化 篇6
关键词：软件定义网络,Openflow协议,资源复用,流表,优先级
0引言
为应对现有互联网体系架构复杂度高、可扩展性差、对硬件设备依赖性强和虚拟化能力弱等问题,SDN(软件定义网络)技术应运而生。SDN是一种新型网络创新架构,它实现了网络流量的灵活控制,为核心网络及应用的创新提供了良好的平台。现有的SDN技术都以实验和论证为主要目的,在有限的实验性网络中,SDN所暴露出的最大问题就是容量问题[1,2]。近年来,网络流量呈爆炸式增长,全球网络总容量已迈入Zettabyte级别,若不解决容量上的问题,SDN技术的进一步发展将受到很大制约。
本文针对这一问题简要介绍了Openflow的流表结构,在分析了现有流表存储结构的基础上,提出一种流表存储的优化方案,以达到在相同资源条件下尽可能多地管理数据流的目的,通过软件的手段直接扩大了一台Openflow交换机的容量,具有较高的应用价值。
1Openflow流表结构分析
当前SDN的主要代表是以Openflow协议为核心。标准化组织ONF(开放网络基金会)正在进行Openflow的标准化工作,Openflowv1.3.1是目前已经发布的最新版本。
图1所示为Openflowv1.1版本中定义的流表表项结构[3],基本的流 表表项包 含三部分,其中MatchFields(匹配字段)包含一组用于标识流的字段 ,Counters包含一组计 数器 ,Instructions包含一个或多个操作。
图2所示为Openflowv1.3.1中定义的流表表项结构[4]。由于在Openflowv1.1中,新增的匹配项使MatchFields的长度达到了一个新高度,基于今后的扩展性等方面的考虑,在v1.2之后的版本中将MatchFields修改为一 个可变长 的字段,每个OXMTLV(Openflow可扩展匹配字段的类型、长度、值结构)最长可达259个字节。ValueField(值域)可配置为带掩码的形式,当其配置为带掩码时,匹配域的长度会变为不带掩码时的两倍。虽然新版本的Openflow节省了一定的开销,但其消耗的存储空间依然较大。
由图1和图2可知,Openflow作为SDN的主流技术之一也存在一些问题。首先,标准中关于转发流表的设计,由于需要的流表存储空间巨大,在具体硬件设备上实现困难很大。Openflow标准在演进过程中,MatchFields中的字段是逐渐增加的,这使得流表的规模越来越庞大[5],按Openflowv1.1标准定义的匹配字段就达356位[6]。尽管在Openflowv1.2之后的版本中引入了TLV结构的匹配项以及掩码[7],但当存在掩码时,值域的长度会变为不带掩码时的两倍,流表所需要的存储空间依然十分巨大[2]。
此外,Counters和Instructions需要的存 储空间也很大。而且,由于网络中很多流的转发行为相同,如果每个 流表项都 包含Counters和Instructions的全部内 容,存储空间 浪费很大。在Openflow中引入组表[7]和计量表[4]之后,现有的资源将会更加紧张。
实际应用中,流表的存 储常常用 价格昂贵 的TCAM(三重内容寻址存储器)来实现,因此,精细高效的设计更为必要。流表中条目的字段也在不断增加,随着网络规模的扩大,流表的规模将会呈指数增长,实现的硬件成本也会很高。
针对现有技术中存在的缺陷,本文提出一种基于资源复用的Openflow流表存储优化方案,并在该方案的基础上提出一种计算流表关联度的算法,以达到在同样硬件条件下存储更多流表表项的目的。
2方案的流表关联度算法
本算法基于本文提出的优化方案。为使表项的复用程度最大化,硬件资源的利用率尽可能高,待增表项并不会直接合并至与待增表项最相似的表项,而是先计算出与已存表项的关联度,然后再将待增表项与关联度最大的表项合并。结合Openflow流表结构做出的更改,本文提出一种基于新增Mask值和Range值的新算法。该算法的目的在于计算新增表项与已有表项的关联度时,获取与新增表项关联度最合理的已有表项,从而保证流表项合并时的效率和准确性。
首先计算待增表项Ai中某一具体匹配项Mi的掩码。将Mi与流表中已存表项Bi的对应匹配项Ni进行异或运算Li= Mi^Ni,对Li从最高位为“1”的比特开始依次向后统计比特位,将比特位的个数Xi记为掩码部分的Mask值。比较Mask值与一个可配置掩码最大值Max,若计算得到的值大于掩码最大值Max,则算法结束,匹配度Z =0。
之后计算待增表项Ai中某一具体匹配项Mi的范围值。将Mi与流表中已存表项Bi的对应匹配项Ni 做减运算并取绝对值得到范围部分的Range值Yi =|Mi-Ni|。
虽然流表的范围更大时涵盖的表项更多,但范围过大可能会导致非预期的转发行为,如转发了流表中未定义的数据包。基于这种考虑,算法中引入正态分布作为范围值的权值,在涵盖范围内取一个较为折中的值,以避免合并后的流表范围过大导致判定范围过广的问题。将Ni与Li做与运算,并将所得值转为十进制,得到μi;将Li也转为十进制,记为σi;根据以上两值生成正态分布Y~(μi,σi2)。将Yi 代入该正态分布中,最终计算出Yi的权值:
对Mask值、Range值与权值 之积求和,,即得到该匹配项的关联值。
最后,对流表项中所有的匹配项的关联度求和,得到待增流表项Ai与已存流表项Bi的关联度,即,对所得值取整。至此,算法结束。
所得新表项用Mask加Range的方式表示新增表项的匹配值。
新表项=已有表项+已有表项 &Mask+ Range。
图3所示为本文流表的表项关联度示例图。图中省略了源IP和目的IP以外的其他字段,并假定待增表项与给出的几个已存表项(已存表项1~已存表项4)的转发行为相同。图3中,已存表项1与待增表项无法用一个公共表项表示,因此两者关联度为0;待增表项的源IP的最后一位与已存表项2可借助于范围用一个公共表项表示,并且该字段范围值可用1比特表示,因此Range值为1,且两者最后两个比bit不同,掩码为0x00000003,因此Mask值为2,执行以上算法,得到关联度为2;依次类推,可得出已存表项3与待增表项的关联度为24;已存表项4与待增表项的关联度为5。待增流表最终会与已存表项3进行合并。
执行本算法后,原本会新增的表项与已有的表项合并,节省了流表的存储空间。
3Openflowv1.3.1中优化流表存储
方案
首先在Openflow流表基础上设计流表,如图4所示。在Openflow流表的表项中增加了MaskID字段和RangeID字段,为所述MaskID或RangeID设定一个特定值(如0xffffffff),用于表示不需要掩码值或范围值的情况,这样极大地保证了表项复用的效率。 从MaskID可索引至Mask表,从RangeID可索引至Range表,Mask表的表项长度和Range表的表项 长度均与Openflow流表中MatchFields的长度相同,Mask表的表项表示流表中每个MatchFields的掩码,Range表的表项表示流表中每个MatchFields的连续范 围。并且将Counters和Actions/Instructions两部分内容从流表表项中移出,即流表的表项中不直接存储计数器、操作/指令信息,仅存储能 检索到Counters、Ac-tions/Instructions两部分的索引,计数器、操作/指令在其他表中存储。
转发设备收到增加表项的命令后,遍历当前流表中已存在的表项,分析待增表项与每个已存表项的相关性,找到与待增表项关联度最大的已存表项,将该已存表项与待增表项合并后写入流表,然后删除该已存表项;若两者相关度为0,该待增表项作为新表项在流表中创建。其详细流程如图5所示。
创建新产生的表项后,需要将新表项写入流表,Openflow交换机才能根据新定义的规则进行数据流的转发。首先获取合并后的表项以及优先级,若该已存表项的优先级为最低,则找到一个优先级低于该已存表项优先级的空表项,将合并后表项的内容写入该空表项,清空该已存表项,并修改该空表项的优先级为该已存表项优先级;否则,找到一个优先级可以设置为该已存表项优先级,但是查找顺序在该已存表项查找顺序之后的空表项,将合并后表项的内容写入该空表项,其优先级为该已存表项优先级,最后清空该已存表项。
4实验结果及分析
本设计使用专用的Openflow交换机实验平台进行验证,该平台基于FiberHomeS5800系列交换机,该型交换机的运行内存为256 Mb,CPU主频为600MHz,开发环境为vxWorks-Tornado2.2.1,集成了笔者编写的Openflow协议。控制器使用华为的开源SDN平台PofController-1.1.4,运行在WindowsXPSP3之上。根据交换机平台和控制器目前支持的功能,使用源MAC、目的MAC、源IP和目的IP四种匹配字段,即协议中定义的OFPXMT_OFB_ETH_DST、OFPXMT_OFB_ETH_SRC、OFPXMT_OFB_IPv4_DST和OFPXMT_OFB_IPv4_SRC四类匹配类型。
如图6所示,在交换机资源初始化时预先在交换机中生成50项流表。当不执行本方案时,50项流表均存储在TCAM中,并占用大量资源。此时运行流表合并的函数,流表进行自动合并,流表项由之前的50项变成现在的16项,TCAM中所消耗的资源大大减少,新增的Mask与Range表项并不存储在TCAM而是RAM中,有较大的扩展性。通过柱形图可以直观地看到,原本在TCAM中占用的大量资源,被分散到RAM中。而指令和行为的类型没有变更,对已有的转发行为不会造成影响。
5结束语
存储优化 篇7
互联网时代的Web系统在企业中的大量应用,随之而来的数据高速膨胀,使得海量数据的处理和检索问题变的异常复杂。要存储和处理海量信息,不仅需要有高速的网络基础设施,还需要处理海量信息的计算和存储平台,为了能高效可靠的存储和处理PB级的海量数据,对数据的存储计算及检索优化技术应运而生。
1 分布式数据存储
在分布式数据库中,由于数据的分布和冗余,使得查询处理中需要考虑站点间传输数据的通信费用,所以除了考虑CPU代价和I/O代价之外,还应该包括数据在网络上的传输代价。即总代价=CPU代价+I/O代价+通信代价。因此,分布式数据库进行分布式设计时,一个重要原则是使数据和应用程序实现最大程度的本地性,这样就可以使应用数据尽可能地本地化,以减少通信开支。对于建立在各场所的分布式数据库,不需要过分进行限制,但也必须要有规范的设计要求。
(1)硬件规范,必须支持局域网乃至Internet的包括声音,文字,图像的交流,支持IE或Netscape浏览web界面,支持开放性数据源的建立。
(2)数据库形式规范,原则上Access、Paradox,甚至文本文件都可以进行数据传输,但必须保证自己有开放式数据源的特征及关系继承的特征。
(3)域的统一和分类、分科的统一,数据库在各个分布场所必须有统一的域结构,以确保给用户提供完整统一的视图,科目分类的命名必须要求规范,以确保查询和统计工作的准确性,在方便工作的条件下,可以不要求唯一确定的主关键字。
数据库服务器级,就是利用多台数据库服务器对数据进行存储。首先来看案例:我国目前有13多亿人口,现在要开发一个系统,能够根据身份证号检索出该人的详细信息。对于这种海量数据的系统,最有效的方式就是从数据库服务器级进行数据的分类存储。如:我国居民身份证是由18位数字或字母组成,这些数字和字母都有实际意义,其中的前6位是行政区划码,可以把不同行政区划的公民信息存储到不同的数据库服务器上,同时在系统中建立一个字典表,如表1所示。
当输入身份证号码时,首先根据其前4位来检索其行政区划,然后再连接到其所对应的数据库服务器进行检索。
这种方式带来的查询结果是最高效的,数据存储与查询的优化速度可以提升到10的次方级以上。
2 动态表
通常情况下,数据库中的表是固定的。但有时,在系统的实际运行过程中通过动态生成表却能对大数据量的存储与检索起到不错的效果。例如,要为某大学开发学工系统,系统要能够对学生的日常操行进行记录。在系统中必然要有一张表来记录学生的日常行为,而问题是对于上万人的大学,每天将有上万条的记录,而这些信息起码要保存4年,数据将达到10000(人)X 300(天)X 4(年)=12000000条,如何能够快速检索出其中某个学生的操行记录呢?
在系统开发中,可以采用动态表的形式来提升数据的检索效率。具体做法是,系统中存在班级信息表,结构如表2所示。
改进后的表3中添加了一列,叫做【操行记录表】,该列是在添加班级信息时动态按照命名规则生成的,同时在数据库中,也添加了一张表,即对应的操行记录表,该表用来保存该班级的操行信息。对于一个近万人的大学,假如每个班级按照50人核算,那么动态表的应用就把操行记录表的数据量缩小了近200倍,检索效率也提升了近百倍。
3 索引
索引是关系数据库中非常重要的对象,但大家往往忽略了索引对数据检索的影响,这种影响在大型的或复杂的数据库中尤为明显。
下面将通过实际的数据检索来给出实验结果。测试的环境为:主机HP Compaq 6515b;内存:2G;操作系统:Windows xp;数据库:Microsoft SQL Server 2008。
首先,创建如图1所示数据表。其次,向表中插入100万条数据记录。然后,通过如下SQL语句对检索效率进行测试。
(1)索引对比
当采用默认索引执行上述SQL检索时,耗时为373ms;当为pubdate列添加一个非聚集索引时,耗时为156ms;当将默认的聚集索引删除,同时指定pubdate为聚集索引时,耗时为123ms。
虽然三种检索的耗时都没有超过1秒,但从结果可以发现第1种方式的耗时几乎为后面第2种方式的2倍还多,而第3种方式最短。
分析:同样的SQL检索语句,由于第1种方式下,虽然指定了id为主键,创建了一个聚集索引,但由于检索中并不根据id编号进行检索,所以该聚集索引等于没有;而第2种方式时,为pubdate列创建了非聚集索引,其检索用到了索引,从而提升了检索效率;而第3种情形,为pubdate列创建聚集索引,而聚集索引是一种物理存储与逻辑存储一致的索引方式,故其检索效率进一步得到了提升。
(2)组合索引
首先,在pubdate、publisher两列上创建组合索引,然后执行如下SQL语句。
执行检索共耗时1033ms,然后,对进行索引修改,还是为pubdate和publisher创建组合索引,但顺序调整为publisher、pubdate,然后执行检索共耗时16ms,几乎为0。
分析:虽然都是在pubdate和publisher上创建的组合索引,但由于第一次的前导列是pubdate,但在查询中并没有用到pubdate列,所以组合索引没有被使用,而第二次的前导列是publisher,检索用到了索引,大大提升了效率。
总结一下,索引使用需要注意以下几点:
①聚集索引是很宝贵的,一定要用到最合适的列上;
②经常同时存取多列,可考虑建立组合索引;
③组合索引要尽量使关键查询形成索引覆盖,其前导列一定是使用最频繁的列。
4 查询语句优化
通常,检索只要能够检索到数据即可,而忽略了语句写法不同对效率的影响。总的说来,在进行检索时,应遵循的基本原则是尽量避免全表扫描。具体的来说就是需要注意以下几点:
①尽量避免在where子句中对字段进行null值判断;
②优先考虑在where及order by涉及的列上建立索引;
③尽量避免在where子句中使用!=或<>操作符;
④尽量避免使用or来连接条件;
⑤尽量避免在where子句中对字段进行表达式或函数操作。
5 结束语
根据分布式数据存储、动态表、索引、查询语句优化等4个方面对海量数据的存储与检索分析得知,四者的有效结合可以极大的提高数据的存储与检索效率。因此,在实际应用中,系统设计人员可以将这四者有机的结合起来,使之与IT系统部署在一起,从而能高效处理海量数据与检索查询。
参考文献
[1]Tom White.Hadoop:The Definitive Guide.O’Reilly Media,Inc.2009.
[2]田颖,许鲁.分布式文件系统中的负载平衡技术.计算机工程.2003.
[3]Sun Microsystems,Inc.Lustre File System:High-PerformanceStorage Architecture and Scalable Cluster File System.www.sun.com.2007.
[4]陈晓明.分布式数据库分片关系变换查询优化[J].电子设计工程.2011.
[5]陈殿伟.基于Hadoop的虚拟筛选海量数据存储及结果处理的设计和实现[D].兰州大学.2012.
存储优化 篇8
近年来,随着大数据处理技术的快速发展,对大数据的存储和调度成为大数据信息处理的关键。随着人们对分布式数据库的逐步关注、深入研究与常态化应用,采用分布式级联数据库进行大数据存储成为大数据处理应用的重要方向。研究大数据的分布式级联数据库优化设计,将在云存储和大数据智能信息处理等领域具有较高的应用价值[1]。
通过对数据库存储结构和数据访问技术的优化设计,提高数据库对大数据的存储和调度控制能力。传统的数据库存储采用堆栈列表控制方法进行大数据存储,随着存储量和干扰的增大,导致数据库的调度和访问准确性不高。在数据库访问中,目前主要有基于语义信息特征提取的数据库访问技术、基于词频特征分布的数据库访问技术和基于关键字的数据库访问技术等[2,3]。其中,文献[4]提出一种基于语义数据集特征提取的数据库优化设计方法,以实现数据库的优化存储和大数据处理。首先找出两个最不相关的语义数据集合,考查词频准确性和样本记录数量之间的关系,通过有向图模型设计方法,提高数据库的调度和访问指向性能力。但是该方法计算开销较大,收敛性不好[5]。针对上述问题,本文提出一种基于大数据存储区域自动筛选的数据库优化存储和访问技术,首先进行数据库中数据分布存储模型设计和数据结构分析,采用模糊C均值聚类算法进行大数据的存储区域优化聚类,提高数据聚敛能力。采用滤波算法进行数据库中的干扰滤波处理,对滤波输出的数据进行存储区域的自动筛选控制,实现数据库存储空间优化,提高数据库访问的指向性和配准性。最后通过仿真实验进行了性能测试,得出有效性结论,展示了较高的应用价值。
1 预备知识及数据库中大数据存储数据结构分析
1.1 数据库中数据分布存储模型设计
为了实现对大型网络级联数据库的优化设计和存储访问控制,首先采用分布式存储调度方法,对大型网络级联数据库的存储数据采集结构进行存储数据的数据结构分析,再用有向图表示云计算环境下大型网络级联数据库的数据分布存储模型,如图1所示,以此为基础进行数据的存储结构优化设计[6]。
1.2 数据结构分析与信息流时间序列分析
在上述构建了数据库中数据分布存储模型的基础上,为了实现对数据存储区域的自动筛选和访问控制,进行数据库结构和数据信息流时间序列分析及信号模型构建。求大型网络级联数据库存储数据每类样本的模糊神经网络控制的隶属度函数,先求得隶属度函数的特征采样均值,Kj为第j类样本符合K个分配因子的带宽,并抽取数据库访问特征序列的相空间模糊度点集作为数据库访问控制训练集的聚类中心S,取其最大值si作为资源带宽差值控制的第一个聚类中心,采用自适应波束形成进行特征采样和资源访问控制,假设访问控制函数为:
在数据库访问过程中,假设时间函数为一个非线性的时间序列,得到数据库访问过程的不确定干扰项为:
其中,U为数据库访问控制中的特征采样数据论域。这里采用粒子群算法进行数据库的访问时间序列分析,粒子群在搜索过程中经常会陷入局部最优解,采用混沌映射方法,带领粒子逃离局部最优解,混沌映射的状态空间更新迭代过程为:
依据混沌映射搜索的最小积分准则,当粒子群在搜索过程中簇的中心点收敛到数据库的资源聚类中心时,求得数据库的资源聚类训练集的功率谱密度函数作为特征,进行特征提取和时间序列分析,得到数据的特征向量为:
通过上述处理,实现对大型数据库数据结构和信息流时间序列的分析,为实现数据库的优化设计奠定基础。
2 大数据存储区域自动筛选及数据库优化
在上述进行了数据结构分析和信息流时间序列分析的基础上,进行数据库优化设计改进。提出一种基于大数据存储区域自动筛选的数据库优化存储和访问技术,采用模糊C均值聚类算法进行大数据的存储区域优化聚类,提高数据聚敛能力。模糊C均值聚类算法的实现过程如下,对大型网络级联数据库存储数据的结构特征优选的C均值聚类中心为:
式中hi(t)表示特征子集Si(i=1,2,…,L)的变异参数,计算数据库中作业运行队列的调度时长响应函数为:
式中,h′i(t)为S(t)数据库数据进行模糊C均值聚类的定期扫描算子,采用模糊C均值聚类得到输出的数据库聚类中心矢量为:
式中,对大数据特征调度的噪声干扰为:
为了实现对聚类输出大数据的干扰抑制,需要采用数据滤波算法进行数据滤波,采用滤波算法进行数据库中的干扰滤波处理,并采用IIR滤波器进行数据干扰滤波,滤波器的设计结构函数为:
对滤波输出的数据进行存储区域的自动筛选控制,采用模糊遗传算法,计算得到大型网络级联数据库的存储数据在云存储空间内的时域特征状态响应函数表达式为:
其中,数据库优化存储的大数据自动筛选控制的激活因子为:
通过上述算法改进设计,实现数据库优化存储的调度控制。
3 仿真实验与结果分析
为了测试本文算法在实现数据库优化存储中的性能,进行仿真实验。仿真的硬件CPU为Intel®CoreTM i7-2600,采用Matlab仿真工具进行数学仿真。大型网络级联数据库存储数据的云存储节点分布在均匀线列阵存储区域,存储数据的数据格式为vmdk、exe等。进行大型网络级联数据库存储数据的原始信息采集,大数据特征采样频率为21kHz,存储数据的频率范围为12~24kHz。根据上述仿真环境和参数设定,得到大数据存储区域的采样输出如图2所示,采用本文方法进行存储区域自动筛选后的输出如图3所示。
由图3可见,采用本文方法实现数据库存储空间优化,可提高数据库访问的指向性和配准性。仿真结果表明,利用该方法进行数据库优化设计,对大数据的存储和调度性能都有较大改善。
参考文献
[1]周涛.基于改进神经网络的电力系统中长期负荷预测研究[J].电气应用,2013,32(4):26-29.
[2]耿忠,刘三阳,齐小刚.基于非合作博弈的无线传感器网络功率控制研究[J].控制与决策,2011,26(7):1014-1018.
[3]张磊,王鹏,黄焱,等.基于相空间的云计算仿真系统研究与设计[J].计算机科学,2013,40(2):84-86.
[4]文天柱,许爱强,程恭.基于改进ENN2聚类算法的多故障诊断方法[J].控制与决策,2015,30(6):1021-1026.
[5]余晓东,雷英杰,岳韶华,等.基于粒子群优化的直觉模糊核聚类算法研究[J].通信学报,2015(5):74-80.
存储优化 篇9
网络系统在运行过程中会产生大量的系统日志、应用日志、安全日志和网络日志,这些日志包含着关于网络运行、安全及状态的数据。随着采集日志的大规模增长,现有的存储系统硬件成本高,扩展能力差,数据并行访问效率低,难以满足网络安全设备联动系统的需求。因此,提供一种更高性能、更低成本、更好可靠性的易于管理的存储平台,才能够帮助该系统用尽可能低的成本应对日益增长的数据存储需求。
HDFS采用主从式架构设计模式(master/slave),一个名称节点(Name Node)和若干数据节点(Data Node)构成HDFS集群[1]。HDFS的这种单名称节点的设计极大地简化了文件系统的结构,然而也因此引发了HDFS的小文件存储效率低的问题。HDFS设计之初的目的是存储大量的大文件,所以需要采用分块策略先将每个文件分块,保存机制是每个文件都占用一个或多个块。因为HDFS中的每个目录和文件的元数据信息都存放在名称节点的内存中,如果系统中存在大量的小文件(指那些比HDFS数据块(默认为64MB)小得多的文件),则无疑会降低整个存储系统的存储效率和存储能力。然而,在网路安全设备联动系统[2]存在着大量的小文件。大量的小文件存在于云存储系统中无疑会降低整个系统的I/O性能。针对这一问题,本文提出云存储中小文件的合并处理方法,以提高小文件的存储效率,提高整个系统的I/O性能。
2 整体方案优化设计
文件的优化方案主要包括4个部分:数据预存储节点的功能设计,小文件合并方案,小文件索引结构的设计以及小文件合并过程的整体设计。
2.1数据预存储节点功能设计
数据预存储节点是在HDFS架构的基础上新增的节点,它位于客户端与名称节点和数据节点之间,主要实现对存储的文件进行预处理,根据文件大小,判断是否属于小文件,对于小文件主要完成存储前的合并,生成索引以及小文件检索时的文件分离等功能。增加数据预存储节点之后,在数据存储的过程中,数据的流向由从客户端直接到数据节点变成了由客户端先到预存储节点再到数据节点。
2.2小文件合并算法设计
当客户端写入小文件时,首先根据小文件的类型对数据预存储节点进行分组。然后分别将每个分组中的小文件合并成大文件,此时,生成相关小文件索引信息及元数据信息。最后将合并后的文件和相关的元数据,按照原HDFS写入文件的方式一同上传至HDFS中,其中第二类元数据信息由数据预存储节点进行存储,第一类元数据信息由名称节点进行存储,数据节点存储合并成的大文件[3]
当客户端需要读取某个小文件时,从名称节点获取小文件所在大文件的元数据信息,然后从数据预存储节点获取第二类元数据信息,从数据节点获取小文件所在的大文件,并在接口中将大文件解档为若干小文件,并将这些小文件缓存在客户端。
为了便于算法描述,对算法里的符号进行定义:File[type][MD5][key]——缓冲区中待合并的文件;type——日志文件的类型(1:主机日志;2:sort日志;3:防火墙日志;4:交换机日志);MD5——文件的MD5 值;fi——要合并的第i个文件;xj——合并第j类文件个数。
分组合并算法描述如下:
(1)初始化,定义一个三维数组File[type][MD5][key],type初始化为1,key值初始化为文件的大小;
(2)读入缓冲区的所有文件大小,更新数组File[type][MD5][key],根据文件的类型更新数组的type值,初始化i=1;
(3)采用冒泡排序,分别将数组File[i][MD5][key]从大到小进行排序。首先判断File[i][MD5][key]的大小,如果所有文件的总大小大于64M,开始进行合并,否则退出程序,i++,等待下次分组合并调度;
(4)从最大的文件fi开始分组。如果放入文件fi后,此类文件的总大小小于64M,则存放下一个文件,从数组中把文件fi的记录删除,循环这个过程,直到所有的File[i][MD5][key]文件都合并到一起;
(5)计算每类文件合并后的大小,文件大小达到63M的调用HDFS命令将文件上传到HDFS上,大小小于63M的文件,再从缓冲区中查找文件进行装入,返回(2);
(6)上传成功;
主要是考虑到用户的访问效率,算法中采用将同类日志文件进行分组,无论从写入小文件,还是从读取小文件方面,都能大大提高HDFS的性能:首先减轻了名称节点的负担,在读取小文件方面,不用连接数据节点读取,减少文件读写的I/O操作,节约大量数据传输时间,极大地节省了网络通信开销,降低了HDFS的访问压力,提高客户端访问文件的速率和性能。
当用户删除数据时,把合并后的文件取回数据预存储节点,进行分解,删除指定文件,再与缓存区中已有的文件进行合并。
用户查询文件时,需要对HDFS索引进行查询,同时也需要查询缓冲区里面的文件。
2.3小文件索引结构的设计
在小文件合并之后,仅仅根据名称节点中存储的元数据信息不能检索到小文件,为了提高检索效率,需要为所有小文件构建相应的索引,使用户能够通过索引快速的检索到小文件。小文件索引信息是在小文件合并成大文件之后生成的,保存在数据预存储节点中,通过此类元数据信息,再结合名称节点中的第一类元数据信息,才能正确找到小文件的存储位置。所以小文件的索引信息对于后期的小文件检索极其重要,其中要包含小文件的一些重要信息:File_name类型为String,表示小文件名称;File_size类型为int,表示小文件大小;File_type类型为int,表示小文件类型;Merge_file_nam类型为string,表示小文件合并成大文件后的名称;File_offset类型为int,当前小文件在合并文件中的偏移量;time类型为long,表示文件的写入时间;If_use类型为bool,表示文件是否存在。
2.4小文件合并过程的整体设计
大致流程如下:
当需要写入文件时,首先将数据传输到数据预存储节点,判断文件大小,如果文件大小超过了HDFS数据块的大小,则直接存入数据节点,并将元数据信息写入到名称节点;如果需要写入的文件属于小文件,则先判断小文件的类型,然后根据2.2中设计的小文件合并算法将小文件合并,生成索引信息,在这个合并的过程中,不断地将正在合并的小文件索引信息插入到小文件索引信息列表中,当合并文件块达到合适的大小时,客户端将写文件请求发送到名称节点将合并后的文件存储到相应的数据节点中。
3 实验验证
实验需要搭建Hadoop集群,集群中包括4个节点:一台Na⁃me Node,二台Data Node,以及客户端用来提交数据的Name No⁃de。 使用VMware 7.0 来模拟Linux环境[4,5台机器上模拟海量小文件的存储和访问操作。本文随机选取了10000个xml日志数据文件,文件大小分布情况为:200k B占1%,300k B占2%,400k B占10%,500k B占20%,600k B占30%,700k B占20%,800k B占10%,900k B占4%,1000k B占3%,可见文件大小集中在400kb到1000kb之间。
为了直观的反应优化方案在处理小文件和大文件时的系统性能,本文在测试数据中分别选取了100、1000、10000 组数据,按照以上测试和执行程序步骤,对文件写入时间进行测试,测试结果如图1 所示。实验结果表明,随着文件数量的增多,写入文件所用时间增长趋势的变化缓慢,说明本文设计的Ha⁃doop小文件存储优化方案在写入海量小文件时性能更高。
4 结论
本文首先对网络安全设备联动系统的数据转化为XML文档,然后对文件的特点及文件大小的分布进行了分析。针对HDFS对小文件存储效率低的问题,对小文件存储方案进行了优化,设计了小文件分组合并的算法。最后搭建了Hadoop集群环境,对改进的方案进行测试,实验结果表明,本文设计的Hadoop小文件存储优化方案在写入文件所用时间增长趋势的变化缓慢,说明本方案在写入海量小文件时具有很高的性能,在不影响存储系统运行状况的基础上,该方案提高了小文件的存储效率和读取效率。
参考文献
[1]廖彬,于炯,张陶,杨兴耀.基于分布式文件系统HDFS的节能算法[J].计算机学报,2013(05):1047-1064.
[2]傅颖勋,罗圣美,舒继武.安全云存储系统与关键技术综述[J].计算机研究与发展,2013,50(1):136-145
[3]D L Tennenhouse,J M Smith,W D Sincoskie,et al.A Survey ofActive Networks Research[J].IEEE Communications Magazine,1997,35(l):80-86.
[4]许春玲,张广泉.分布式文件系统Hadoop HDFS与传统文件系统Linux FS的比较与分析[J].苏州大学学报(工科版),2010,04:5-9+19.