文档存储（精选7篇）
文档存储 篇1
0.引言
云计算是信息科学研究领域的热点问题之一, 它的运用使各个企业能够对先进的信息技术进行更好更快的利用, 能够降低企业前期的运营成本[1]。云计算技术的应用将企业的可获利最大化。云计算作为新时代网络技术之一, 极大的利用了计算设备、存储资源及方便快捷的互联网服务, 并在各行各业充分体现出了价值。
一个企业在长期运作时, 必然产生的大量数据, 而且这些数据很多都以文档、表格、附件、图片等形式存储在不同员工的电脑上, 支持着企业发展。简言之, 企业的核心资产是来自员工日积月累贡献的文档[2]。
随着企业信息化的步伐不断深入, 带来的数据安全问题也日益突出, 企业的文档集中存储在"云"上, 对于数据的安全并不只局限于传统病毒感染或者黑客入侵等, 也有可能是因为内部人员对数据访问上没有限制造成泄密, 或者是"云"里的众多服务器中有一个或多个服务器崩溃, 导致数据丢失。本文将给出企业文档在云计算中安全存储的具体方案。该方案以纠删码为主要工具, 给出文档存储和恢复的具体构造方法, 并给出了安全性分析。
1. 纠删码
纠删码的工作原理可简述为:令A是发送方, B是接收方。首先, A将m个源数据包编码成n个编码包, 再把n个编码包通过互联网传输给B, B只要接收到一定数量的编码包, 就可以恢复出原始数据。目前主要有三类纠删码:RS类纠删码、级联低密度纠删码和数字喷泉码[2]。
RS码具有很强纠错能力, 最早是在1960年由Reed和Solomon提出的一种构造最优纠删码的方法, 使用这种方法构造的纠删码被称为RS纠删码。它可以对突发错误进行纠正, 也可以对随机错误进行纠正。构建纠删码的关键是找出一个生成矩阵Gk×n, 使Gk×n中任意k列均线性无关, 其中n>k。RS类纠删码根据其生成矩阵不同分为两类:范德蒙码 (Vandermonde Code) 和柯西码 (Cauchy Code) [2]。
2. 基于纠删码的文档存储方案
把被存储的文档设为F, 可分为m块大小相同的数据块fi, 即F= (f1, f2, …, fm) , 其中F和fi均为十进制数。在文档的存储的时候, 将文档F切割成若干块等大小的fi分别进行存储。当存有数据的在多台服务器集群里有一台或数台服务器崩溃, 利用纠删码可使用云端其余服务器中存储的数据块, 将存储云端的原始文档恢复出来。具体步骤如下:
2.1 文档存储
第一步:构建一个m× (m+k) 的范德蒙矩阵
第二步:文档进行编码, 设H是编码后的文档:
其中H包含了每个原数据块 (f1, f2, …, fm) 和k个新生成的校验向量 (c1, c2, …, ck) 。
第三步:存储文档F的时, 仅需在分布式文档系统中存储的文档编码后的向量H。
2.2 文档恢复
当出现服务器崩溃等情况造成存储在该服务器上的数据, 无法正常读取数据的时候, 借助还在正常工作的服务器上面的数据将文档恢复出来确保用户正常使用是很有必要的。借助矩阵的求逆过程和存储在其他服务器上的部分文档向量H, 就可以解决恢复文档的问题。
第一步:用户任取x个文档块H’= (H1’, H2’, …, Hx’) , 设为Hx’所对应的存储向量H中的校验向量cy, 且y∈L (L为所对应的Hx’索引集合) 。
第三步:求出P的逆矩阵P-1;
第四步:可以通过算式F=H’·P-1来轻松的恢复出原文档, 达到数据完整性, 可用性的目的。
3. 安全性分析
设文档F分为m块, 运算后, 文档块块数变为h=m+k, 任意取其中m个块, 文档F就可以得以恢复。在云存储环境中, 设数据块在服务器上均匀分布且云服务器个数为n, 平均故障率为p, 每个文档块分布在服务器上的概率为, 那么在n≥m的情况下文档安全存储的概率为:
4. 总结
本文从云计算的大背景出发, 利用范德蒙矩阵的特性, 结合RS纠删码的技术, 实现数据的完整性和可用性。做到在部分服务器在崩溃或者存储的部分数据块丢失的情况下可恢复出原文档, 确保用户的数据可用性。该方案在企业文档管理“云”化的实现上有一定的应用前景。
摘要：企业文档的数据化管理势在必行, 但带来的安全问题也日益突出。本文把企业文档管理与云计算相结合, 利用纠删码构造了文档安全存储方案, 解决了文档完整性和可用性问题, 并分析了方案的安全性。
关键词：云计算,范德蒙矩阵,纠删码,文档存储
参考文献
[1]蹇旭, 李雯雯.云计算中的网络安全问题及对策研究[J].电脑知识与技术, 2013, 9 (14) :3253-3256.
[2]郭春梅, 毕学尧.纠删码的分析与研究[J].信息安全与技术, 2010 (7) :38-42.
基于模式映射的GML文档存储 篇2
互联网的迅速发展为GIS的发展和普及提供了强大的基础, 然而不同GIS的开发商使用的数据格式不统一, 使得不同开发商的地理信息数据很难共享, 这在很大程度上阻碍了地理信息系统的发展。1999年开放式地理信息系统协会 (OGC) [1]提出了GML[2], 为GIS空间数据建模、集成与共享提供了统一的标准和框架。GML是一种基于XML[3], 用于地理空间信息编码、传输和存储的地理标记语言, 它能够用来表示地理空间对象的空间属性数据和非空间属性数据, 而且独立于任何厂商、任何平台。近年来, 大量的GML数据的涌现, 对如何有效地存储和管理GML数据提出了新的挑战。
一些学者[4,5,6,7,8,9,10]提出用传统数据库来存储和管理GML数据, 传统数据库技术比较成熟, 具有支持并发控制、多用户访问和数据恢复等功能。其中, 关系数据库和对象-关系数据库是目前主流的数据库:关系数据库能很好地处理所谓的“表格型数据”, 却对技术界出现的越来越多的复杂类型的数据无能为力;对象-关系数据库不仅继承了关系数据库的优点并且还具有扩充数据类型、支持复杂对象等特点。因此, 本文采用了对象-关系数据库作为后台存储数据库。
本文根据GML文档的特性, 提出了基于模式映射的存储方法。首先将GML模式根据一定的映射规则生成数据库模式, 然后解析GML文档并根据映射信息构造相应的SQL语句, 将数据存储于数据库。
1 相关工作
GML是一种基于XML的语言, 而目前XML存储技术的研究己经相对比较成熟, 因此可以通过借鉴XML存储技术来研究GML的存储。
在借鉴XML存储技术的基础上, 文献[4]提出了一种把GML数据存储到关系数据库的机制。该方法存在着存储粒度太小和不支持空间操作等问题。文献[5]选择了三个基于关系数据库的存储模型LegoDB、Monet、Xparent来存储GML数据。该方法能很好地处理文本操作, 但也不支持空间操作。文献[6,7]提出了通过扩展PostgreSQL/SPE 、Oracle Spatial等空间数据库来存储GML数据, 并且支持空间、非空间和两者混合的查询, 为GML数据有效管理推进了一大步。但是它们没有对查询结果的数据进行重新构建。文献[8,9]提出了基于“结构”和“模型”的两种映射技术, 前者将GML文档存储于由其模式映射生成的数据库模式中;后者将GML 文档以通用的方式存储到支持空间数据的数据库中。Snowflake软件公司开发了专门针对Oracle数据库的GML数据加载器GO loader[10], 它只是将GML数据存到Oracle数据库中, 并不支持空间和非空间查询操作。
如上所述, 目前利用传统数据库存储GML文档的方法基本可分为基于结构映射和基于模型映射两类。前者根据GML模式映射生成数据库模式, 后者使用通用的数据库模式。前者存在着映射准确性、通配符数据存储和模式冗余等诸多问题, 后者在查询时存在大量的连接操作和数据语义的丢失 (如:将整型数据存储为文本类型) 等问题。
本文提出的基于模式映射的存储方法中, 数据库模式生成部分使用了文献[8,9]的方法, 并针对该类存储方法存在的问题做了如下工作: (1) 提出了模式简化算法解决了模式冗余问题; (2) 提出移除代替属性的算法解决了模式中元素映射准确性问题; (3) 利用基于模型映射的存储方法解决了模式中通配符所对应的GML数据的存储问题; (4) 提出了基于模式映射的GML文档的加载算法。通过上述的工作, 很好地解决了基于结构映射的GML文档存储存在的问题。
2 GML存储
本文提出的基于模式映射的GML文档存储的GStore系统框架如图1所示, 该系统主要由数据库模式生成器、GML文档加载器和GML查询器组成。其中, 元素名称映射表是模式简化前后的元素命名的对应表, 在数据的加载和查询的过程中都需要通过此表对元素名称进行转换。
数据库模式生成器 GML应用模式通过模式简化器去除冗余的元素和数据类型定义, DB模式生成器将简化后的模式根据映射规则生成数据库模式的SQL语句存储于DB模式库中, 用户可以根据不同的策略将DB模式库中的SQL语句生成数据库模式。
GML文档存储器 利用基于SAX的解析器对GML文档进行解析, 并根据元素名称映射表和GML模式到数据模式映射的信息构造生成SQL语句将其存入数据库中。
GML文档查询器 GQuery[11]查询语句通过元素名称映射表进行元素名称替换, 再通过GQuery2SQL转换器将GQuery查询语句转为SQL语句进行查询, 并将查询的结果进行重构形成GML片断。
2.1 GML模式预处理
GML规范只是为创建使用地理对象特定应用领域的应用模式而提供的框架 (即核心模式) , 而不是直接定义像河流、道路这样特定的对象。为了创建特定对象, 数据库管理者和数据建模者通过导入GML核心模式和其它模式创建应用模式, 其结构如图2所示。
GML的应用模式定义了应用领域实例数据的表现形式, 一个应用模式可以看作是一个特定的XML语言的应用, 如图3所示是一个GML应用模式片断, 该模式是由荷兰地理空间信息Geonovum基金会提出的用于地理信息研究组织之间数据的交换和信息交流的空间地理对象的基本模型, 主要包括描述空间对象的术语、关系和拓扑结构等信息。该模式片断经过预处理后的结果如图4所示。
2.1.1 GML模式简化
GML应用模式通过include和import指令导入外部模式, 其导入是以整个模式文件为单位, 因此存在着大量当前应用模式不使用的元素和数据类型的定义。在将其映射到数据库的过程中会生成大量冗余, 浪费了数据库大量的空间和映射时间, 因此必须对其进行简化。另外, 对GML应用模式进行处理时, 由于现存的解析器并不支持或不能很好支持外部模式的处理, 因此, 必须将应用模式中的外部模式整合为单个文件。本文提出了模式简化算法SchemaSimplifier解决上述问题, 具体算法如下:
为了方便描述SchemaSimplifier算法, 提出了如下定义:
定义1 定义TDOM= (VT, ET ) 为GML应用模式的无向DOM树。其中, VT为DOM树的节点;ET为节点间相连的边。Glob
2.1.2 SubstitutionGroup属性
GML元素可以通过SubstitutionGroup属性标记可被当前元素替代的元素, 该元素必须与代替元素具有相同的数据类型或是代替元素派生的数据类型。代替元素和被代替元素的名称、约束条件等可能存在着不一致, 而数据库的元素名称、数据类型和约束条件等是确定的, 所以在数据库中代替元素和被代替元素不能存储在同一个数据库模式中。在GML模式中存在着大量的具有这样属性的元素, 因此解决这个问题是能否正确将GML模式映射成数据库模式的一个重要的方面。为此提出了移除SubstitutionGroup属性的算法来解决上述问题, 算法的具体内容如下:
2.2 数据库模式生成
利用传统数据库存储GML文档, 首要解决的问题是数据库模式生成的问题。本文提出的基于模式映射的数据库模式是由简化后的GML模式根据相应映射规则动态生成的, 对于模式中通配符对应的实例数据使用通用的方式进行存储。
2.2.1 模式映射
本文在XML模式映射到数据库模式[11]的基础上提出了GML模式到数据库模式的映射方法, 通过建立GML模式的映射规则在对象-关系数据库模式中保留GML模式的结构和语义约束。GML模式中定义了内置类型、复合类型、几何类型、属性和元素, 实现GML模式到数据库模式的映射, 首先确定GML模式中定义的数据类型到数据库模式上数据类型之间的对应关系, 为此, 我们定义了如下映射规则, 其具体的映射算法在文献[8]中有详细的描述。
(1) 内置简单类型和用户自定义简单类型 (User-defined simple type) 映射为对象关系数据库中简单类型及相应约束。
(2) 复合类型映射为对象关系数据库用户自定义类型UDT (User-Defined Type) , 复合类型中的GML属性映射成具有相应简单类型的UDT中的属性, 简单元素内容映射成具有相应简单类型的UDT中的属性, 元素/子元素间的关系映射成UDT中的属性, 根据子元素的出现次数和类型的不同, 它的类型或者是子元素的UDT或者是指向子元素的引用或数组。
(3) 几何类型映射为对象关系数据库的内置空间数据类型, 如PostgreSQL/PostGIS中的geometry或者Oracle Spatial中的SDO_GEOMETRY。
(4) 属性映射为对象关系数据库中的简单类型或用户自定义类型中的简单类型。
(5) 元素按其在 GML模式中出现次数和类型的不同, 映射成单独的一张表或者映射成其父元素表中的一个属性。
由于在 GML数据存储和查询过程都必须根据映射信息构造相应的 SQL语句, 因此除了映射算法生成的模式, 还需要如下所示的数据库表用于存储 GML模式到数据库模式的映射信息和文档的结构信息:
T1. gmlAttrTable<attrID, gmlName, mapType>
T2. gmlElemTable<elemID, gmlName, mapType, elemType, udtName>
T3. gmlElemAttrTable<elemID, attrID, ord>
T4. gmlElemElemTable<elemID, subElemID, ord, mapType, min, max>
其中, 表T1用于存储模式中的属性信息:attrID为属性的编号;gmlName为该属性的名称;mapType为该属性在数据库存储的数据类型。表T2用于存储模式中的元素信息:elemID为该元素的编号;gmlName为该元素的名称;mapType为该元素在数据库的存储类型;elemType为元素在模式中的类型 (在加载GML文档和查询时, 可以通过该字段判断此元素在数据库中是映射为一个用户自定义的数据类型还是映射为一张表, 从而生成相应的SQL语句) ;udtName为该元素的映射类型的名称。表T3用于存储模式中元素和属性之间关系:elemID为该元素的编号;attrID为该元素的属性编号;ord为该元素的多个属性之间的顺序。表T4用于存储父元素和子元素之间的关系:elemID该元素的编号;subElemID为子元素的编号;ord为该元素的多个子元素之间的顺序;mapType为子元素的数据库映射类型;min和max为子元素可重复出现的最少次数和最多次数。
2.2.2 通配符数据存储
GML模式中的通配符 (如: any, anyAttribute, anyType等) , 用于声明没有明确元素内容的元素。通配符在实例文档的数据和结构是不确定的, 因此必须采用一种与结构无关的存储模型来存储实例文档的数据。本文采用基于节点和边模型的存储方法[9], 其数据库表结构如下所示:
T5. PathTable<docid, pathid, pathexpr, nidarray>
T6. RelationTable<docid, pid, cid>
T7. ElementTable<docid, pathid, ordinal, nid, type, value>
T8. SpatialTable<docid, pathid, ordinal, nid, type, shape>
其中, 表T5用于存储GML文档中节点的标签路径信息:pathid为标签路径的编号;pathexpr为相应的路径表达式;nidarray为数组, 用于存储同一路径下节点编号。表T6用于存储GML文档节点之间关系的信息:docid、pid和cid分别为GML文档的编号、父节点编号和子节点编号, 通过此表可查询到文档中的父子节点之间的关系。表T7存储元素节点和属性节点的数据:ordinal表示具有相同标签路径的节点顺序;nid为该节点的编号;type为该节点类型 (元素节点还是属性节点) ;value 为该结点的数据 (所有的数据都存为varchar类型) 。表T8用于存储空间几何体节点的数据:type为几何体的类型;shape为空间几何体的数据。
2.2.3 数据库模式生成策略
由于GML模式通用性和全面性, GML实例的具体性和针对性, 具体的GML数据不可能会用到模式中的全部的元素定义, 因此, 经过预处理的GML模式仍然存在冗余。因此, 可以根据实际情况将DB模式库中的SQL语句生成到数据库, 生成的策略如下:
(1) 实时生成 GML模式经过映射算法的处理实时地生成数据库模式, 此策略在数据库中会生成所有模式。
(2) 延迟生成 GML模式经过映射算法生成数据库模式的SQL语句, 并将生成的SQL语句存储在DB模式库里, 在存储的过程中根据需要将所需要的 SQL语句生成到数据库里。
由于GML规范定义的空间数据类型相当的复杂而全面, 而具体的GML数据并没有那么复杂, 所以实际用于存储GML数据的模式只是生成的数据库模式的一部分。因此, 本文采用第二种策略生成数据库模式。
2.3 GML文档存储
将 GML文档存储到数据库, 首先必须对文档进行解析。
目前用于解析GML文档的解析器主要有SAX[12]和DOM[13]两种标准。其中, SAX标准是采用事件驱动方式, 能处理大数据量的GML文档。而DOM标准则是文档驱动方式, 需要在内存中构建文档树, 消耗较多的计算机资源, 尤其是内存资源。由于GML数据量大, 通常无法在内存中构建文档树, 因此基于DOM标准的解析器不适合解析GML文档。在本文中, 将采用基于SAX标准的Xerces[14]解析器来解析GML文档。
GML数据存储到数据库步骤如下:首先, 利用Xerces解析器对GML文档进行解析, 根据解析得到的元素名称从映射信息表中取得该元素的映射信息, 如果在映射信息表中无法获取到元素的信息, 就采用通用的存储方式存储该元素。其次, 根据当前元素的映射信息将当前元素的数据构造生成SQL语句。最后, 利用生成的SQL语句将数据存储到数据库, 具体算法如下:
3 GML查询
GML数据的查询包含了空间数据查询和非空间数据查询两方面。由于GML规范基于XML规范, 因此用于XML查询操作的XQuery语言[15]也可以用于对GML查询操作。但是, XQuery不能支持空间查询、空间分析等空间操作。文献[16]提出GQuery查询语言、文献[17]等提出GQL查询语言, 二者在XQuery查询语言的基础上增加了对空间算子的支持。
本文使用GQuery查询语言对GML数据进行查询, 查询示例如图5所示。查询的过程分为如下几个步骤:
(1) 根据元素名称映射表将查询语句中的元素名称进行转换。
(2) 根据GML模式到数据库的映射信息获得for和let定义的查询根节点。
(3) 根据where的查询条件过滤查询的根节点。
(4) 根据return 中的查询项, 进一步取得查询结果。
(5) 根据元素名称映射表对查询的结果中的元素名称进行逆替换, 得到最终的查询结果。
由于GQuery查询语言是基于XQuery, 因此GQuery查询不能直接使用数据库的查询引擎进行查询, 而必须将GQuery查询语句转换为SQL语句, 转换算法的详细内容在文献[18]中有详细描述。
4 实验及分析
为了对基于模式映射的GML数据存储的性能进行测试分析, 我们用Java语言实现了GStore原型系统。主要开发软件和开发工具包括DOM4J、SAX、Oracle和Eclipse-Galileo等。实验运行在Windows XP Professional环境下, 硬件配置为AMD Athlon 64 Processor 1.79GHz处理器、2GB内存、320GB硬盘空间。
4.1 数据集
本文分别对五组来自GML 4th Relay的数据进行了实验。GML 4th Relay是由荷兰的GIN (Geo-Information Netherlands) 组织发起的旨在验证GML是否是不同的系统和应用程序之间交换和共享地理信息的一种有效方式的活动, Autodesk、ESRI、Snowflake等公司参加了此次的活动。活动中, 各参与公司根据该组织提供的用于描述地理空间信息的TOP10NL数据集和应用模式生成自己公司产品使用的数据和应用模式, 并将各自的数据进行共享。本文从这些公司共享的数据中选取了五个文档进行实验, 文档的大小从800kB到13MB不等, 文档的详细信息如表1所示。
4.2 实验结果与性能分析
本文分别对基于模式映射的存储、文献[9]提出的基于模型映射的存储、文献[19]提出的基于Native的存储和文本的存储进行了实验。其中, 基于模型映射的存储, 如2.2.2节所述将整个GML文档以通用的方式进行存储;基于Native的存储, 将GML文档以树型的结构进行存储;文本的存储, 将GML数据以系统文件进行存储。实验将GML文档分别以这四种方法进行存储, 比较四者查询所花费的时间, 查询示例如图5所示。
图6所示为非空间数据查询所耗费的时间对比, 从图中可以看出本文提出的基于模式映射和基于Native存储方法的时间消耗很相近, 比另两种方法的时间消耗要小得多。这是由于模式映射将具有相同的父元素的子元素存储在同一行记录里, 查询多个这样的子元素时, 直接能从该行的记录取得而不需要额外的操作;基于Native存储是将GML文档以树结构进行存储, 相同路径的数据存储在一起, 在查询时不需要遍历整个文档而加快查询;基于模型映射存储是将每一个元素存为一行记录, 在对其进行查询时, 因需要大量的连接操作而消耗大量的时间;以文本存储的时间消耗较大是由于查询时需要解析整个文档才能查找到所需要的结果。
图7所示为空间数据查询所耗费的时间对比。从图中可以看出基于Native存储和文本存储的时间消耗比较多, 这是由于GML文档中的空间数据是以字符串形式存储, 在进行空间操作时, 需要先将空间数据转换为空间数据类型才能进行。而基于模式映射和模型存储方法是空间数据以空间数据类型存储, 在进行空间操作时, 不需要进行数据类型转换节省了查询时间。
如上所述, 本文提出的基于模式映射的存储方法在空间数据查询和非空间数据查询的时间消耗最少。
5 结束语
由于地理空间信息的数据是海量的, 而对这些海量的数据进行存储将是一项非常复杂的任务。本文提出一种基于模式映射的存储方案, 利用技术成熟的传统数据库存储和管理GML文档。实验证明, 本文提出的基于模式映射的GML文档存储方案是可行的, 能有效地存储和管理GML数据。
文档存储 篇3
在传统模式下, 用户若要使用数据文档, 首先要从本地传统数据存储介质中读取出数据。存储于本地的数据文档主要是通过用户设置的账号和密码来确保其安全, 同时这种数据文档存储方式受到本地存储空间的限制, 在现有数据文档量急剧增加的趋势下, 非常不利于大数据的存储。随着网络技术的发展, 尤其是云计算的日趋成熟, 本地数据文档可上传到云服务器中进行存储, 云计算环境下基于虚拟化[1]的存储技术由此产生。
1 云计算概述
云计算[2]是使计算分布在大量的分布式计算机上, 而非本地计算机或远程服务器中。云环境下数据中心的运行将与互联网更相似, 这使得用户能将资源切换到需要的应用上, 根据需求访问计算机和存储系统。大数据必然无法用单台的计算机进行处理, 必须采用分布式计算架构。其特色在于对海量数据的挖掘, 但必须依托云计算分布式处理、分布式数据库、云存储和虚拟化技术。
2 虚拟化及存储虚拟化
虚拟化是指计算机元件在虚拟平台上运行, 提供的是对简化计算机资源的管理, 同时对已有资源作进一步优化。虚拟化的存储是通过将多个存储单元通过一定的技术进行集中管理, 而这种集中式的存储管理是通过存储池技术实现的, 该技术将提供区别于以往物理存储的大容量高速存储系统。
存储虚拟化则是将现实中的物理存储实体与处于云计算环境中的逻辑存储单元相互分离, 服务器将只分配逻辑卷进行数据文档的存储, 用户不再将其数据文档存储于具体的物理存储实体上。
随着网络技术的不断发展, 通过云计算环境中存储的虚拟化, 将计算机网络中的各个存储单元加以整合, 通过虚拟存储池进行集中化管理, 按照用户的实际需求建立相关虚拟卷, 将虚拟卷的可读写权限分配给云计算环境中的服务器使用, 既能实现统一管理又能实现存储的充分利用。
3 云计算环境下存储虚拟化的特点
云计算环境下存储虚拟化的特点如下:
(1) 集中化管理。云计算环境下的存储虚拟化通过集中化管理, 在提高存储效率的同时可极大降低使用成本。
(2) 通用性较好。云计算环境下存储虚拟化的通用性较好, 打破了存储供应商之间的界线, 对于用户来说其产品使用的选择面更为广泛。
(3) 对用户透明。云计算环境下的虚拟化存储对于用户是透明的, 用户数据文档的存储不在本地的物理存储介质上完成, 在使用过程中也不需要考虑存储容量等问题, 虚拟化的存储空间将提供近似于无限的存储空间以满足用户日益增长的数据文档存储要求, 但必须注意数据文档存储的安全性问题。
(4) 数据安全要求高。通过各种数据文档加密软件的使用, 对降低数据泄露风险能起到一定的作用, 但不可否认的是, 数据泄露远非简单的加密所能解决。云计算环境下虚拟化存储效率的提高和数据被泄露风险的增大是并存的, 用户对于非存储在本地的数据安全提出了更高的要求。
4 云计算环境下存储虚拟化的文档加密
传统的数据文档加密均采用透明加密方式[3], 对不同类型的所有数据进行强制加密, 这往往是在数据的流转过程中进行。而在其它过程中, 为了减少系统资源的消耗, 一般不使用加密, 因此其性能无法保障。
云计算环境下, 加密软件只是数据泄露防护的核心构件之一, 将所有的重任都寄托于数据加密软件, 远远达不到云环境下的安全要求。加密软件无法承担数据泄露所带来的危害, 加密软件对数据文档的加密作为第一层次防护, 只是安全管理的开始而不是结束。对于云环境下文档数据的加密, 其发展趋势主要为两个方面。
4.1 智能动态化的加解密
加密软件的加密方式可分为自动加密方式和手动加密方式。对于手动加密方式, 用户的主观性比较强, 文档内容是否需要加密是根据文档的所有者来进行判断, 在此过程中文档所有者即用户的主观性所占比重很大。而对于自动加密方式, 加密系统能自动识别出文档的具体内容并根据内容来判断该文档是否需要加密。
强制性的加密软件是根据文档的文件类型来进行加密, 它会将该类型的所有文档都进行加密而不去管该文档是否需要加密。这将导致在加密过程中消耗过多的系统资源以及在往外发送时接受者又需花费很多的系统资源来进行解密工作, 而其中有很多文档是不需要加密和解密的。
在云计算环境下, 采用手动加密方式对数据文档进行加密显然不合适, 因为云计算环境下无法保证文档在加密前不被泄露出去;强制加密方式将极大消耗云存储的性能, 该类方式也不适用云环境下的加解密。而通过自动判断文档的内容来进行加解密则是比较理想的方式, 加密软件将自动判断文档并对其中需要加密的文档进行加解密操作, 可显著提高云存储的效率。
4.2 将文档加密集成到数据泄露防护体系中
早期的加密软件是尽可能从文档的源头上加以控制, 对其进行加密从而防止数据泄密。在云计算环境下, 广泛使用基于文档特征匹配以及基于文档行为识别的内容来进行数据加密, 因而不能再使用以前的数据管理方式, 有必要采用分层架构的多重防护来对云环境下的数据文档进行加密, 而这整个过程将持续作用于文档的创建、使用、流转、存储和销毁的整个周期中, 同时加密必须结合数据的身份认证等多个功能。
随着云计算环境下虚拟存储技术[4]的广泛应用, 数据将从物理性的存储环境转换为虚拟化的存储环境[5], 进一步改变传统的数据文档存储方式, 数据文档将按照虚拟存储的逻辑方式更加透明地存储于云平台中, 完全实现数据文档资源的存储自动化。
在云计算的虚拟化存储中, 加密软件将使用B/S模式来进行架构, 加密过程不在物理位置上完成而是在云环境中完成, 而这将极大减少物理主机的系统资源消耗。虚拟化的存储将对现有的加密软件带来巨大的改变, 主机等终端将不再存储数据文档, 这些数据文档存储在云环境中的虚拟存储中, 本地物理主机等终端只是云环境中虚拟存储位置的一个指向。
云计算环境下的网络虚拟化将使得数据文档的存储方式发生巨大变化, 部署于各处服务器的虚拟化[6]将使数据文档的存储位置变得更加隐蔽, 但也正是这种隐蔽对数据文档的加密提出了更高的要求。
5 结语
随着网络技术的不断发展, 云计算环境下数据文档的存储趋向于虚拟化存储, 传统的数据加密软件将不再适用。而数据泄露防护技术将提供一整套完整的数据加密管理过程, 通过智能化的数据文档识别技术, 自动化地识别出需要加密的数据文档, 并在识别的基础上对需要加密的数据文档进行自动加密。该过程对于用户来说是透明的, 也不会消耗用户的物理系统资源。云计算环境下的数据泄露防护能够对存储在虚拟存储上的数据文档进行高效管理, 并有效防止数据文档的非法获取和非法泄露。
参考文献
[1]金海.计算系统虚拟化——原理与应用[M].北京:清华大学出版社, 2008.
[2]王金波, 金涬, 何乐, 等.虚拟化与云计算[M].北京:电子工业出版社, 2010.
[3]李迈勇.网络安全:加密原理算法与协议[M].北京:清华大学出版社, 2007.
[4]郭玉东, 尹青.基于对象的网络存储[M].北京:电子工业出版社, 2007.
[5]云百科.服务器虚拟化[EB/OL].http://www.zdnet.com.cn/wiki-server_virtualization.
存储虚拟化趋势下的文档加密探讨 篇4
传统的数据存储是放在本地计算机上, 用户在使用的时候首先在本地的计算机存储介质上读取数据, 这种存储数据的方法在安全上由于有计算机的用户名存在, 可以起到一定的保护作用, 但这种存储文档数据的方式由于本地计算机的条件限制, 不利于大规模存储数据, 而借助于服务器技术, 可以将本地的文档数据上传到服务器存储中, 也就产生了一种基于虚拟化的存储技术。
虚拟化是一个广义的术语, 是指计算元件在虚拟的基础上运行, 是为了简化IT管理优化资源的一种解决方案。虚拟存储 (Storage Virtualization) , 就是把多个存储介质模块 (如硬盘、RAID) 通过一定的手段集中管理起来, 所有的存储模块在一个存储池中得到统一管理。这种可以将多种、多个存储设备统一管理起来, 为使用者提供大容量、高数据传输性能的存储系统, 就称之为虚拟存储。
存储虚拟化的基本概念是将实际的物理存储实体与存储的逻辑表示分离开来, 应用服务器只与分配给它们的逻辑卷 (或称虚卷) 打交道, 而不用关心其数据是在哪个物理存储实体上。
随着网络技术的不断发展, 网络和我们越来越密切, 带宽的不断增加和虚拟化技术的不断改进, 文档数据的虚拟化存储技术也在不断完善。
只有网络级的虚拟化, 才是真正意义上的存储虚拟化。它能将存储网络上的各种品牌的存储子系统整合成一个或多个可以集中管理的存储池 (存储池可以跨越多个存储子系统) , 并在存储池中按需要建立数量不等不同大小的虚卷, 并将这些虚卷按一定的读写授权分配给存储网络上各个对应的应用服务器, 从而达到充分利用存储容量、集中管理存储、降低存储成本等目的。
1 存储虚拟化特点
(1) 存储虚拟化是一个SAN里面的存储中央管理、集中管理, 这是虚拟化的一个特点, 一个突出的地方。可以得到收益同时降低成本。
(2) 存储虚拟化打破了存储供应商之间的界线, 可以用A公司的东西, 也可以用B公司的产品, 不会一直局限于A公司的产品。
2 存储虚拟化的文档加密
由于虚拟化存储对于普通用户来说是透明设置的, 虚拟化存储带来的是文档数据存储的便捷和方便, 特别是对于大容量的数据存储体现出了极大的优势, 而且虚拟化存储对应的是服务器, 由于文档数据的存储已经不在本地计算机上来完成的, 所以数据的安全性方面将更加的重视。
各种类型的加密软件的使用, 在一定程度上降低了数据泄露的风险, 起到保护数据安全的作用。然而, 数据泄露并不是一个加密软件就能解决的。网络虚拟化存储的提高和数据泄露风险增大是并存的, 用户对于数据安全已经提出了更多、更新、更高的需求。
从2002年开始, 一个旨在对核心数据加密、防止从内部泄密的软件行业开始兴起并发展起来, 通常称为“电子文档安全行业”, 或称“加密行业”。加密行业通常采用透明加密技术, 对不同类型的文档数据进行强制、实时、透明的加密, 从文件的创建、存储、使用、流转和销毁全过程进行保护。即使文档流失到外部, 也因为进行了加密处理而无法打开, 确保核心机密不被泄露。这个也常常被称为“透明加密行业”。
虽然加密软件行业的发展已经非常的迅速, 但是, 加密软件只是数据泄露防护的核心构件之一, 单凭加密软件就要承担起数据泄露防护的全部功能是不可能的。从整个信息安全的发展来看, 加密软件仅仅只是数据安全的开始。
3 文档加密发展趋势
(1) 智能动态加解密将成为加密软件的发展方向。加密软件的加密方式主要有两种, 一种是自动、强制、透明的加密方式, 另一种则是手动加密方式, 后者主要由文档的作者或者文档管理员根据内容来判断是否需要加密, 用手动的方式对文档进行加密, 这个中间可能主观性较强。
对用户来说, 加密软件应具备以下功能: (1) 系统自动识别文档内容并判断是否属于要加密文档。对于强制加密软件, 只根据文件类型来进行加密。而针对文件类型的加密, 将会把所有该类型的文件都加密, 在需要对外发送明文时, 必然要有大量的解密工作要做, 这会降低工作效率;而如果采用手动加密方式, 那就无法防止文件的作者或者文件管理员在加密之前把文档泄露出去; (2) 系统自动识别要加密的文档并自动进行加密。对手动加密方式来说, 加密之后的文件只能保证文档的下一个使用者不会泄密, 而无法防止文档的创建者或者文档管理员泄密。要防止手动加密的泄密, 加密软件就必须有自动对需要加密的文档进行加密。
(2) 文档加密将与文档的存储、备份和灾难恢复等功能集成在一起, 成为文档管理整体解决方案。文档加密和文档的备份、灾难恢复一样是解决数据安全问题, 所以文档的备份、灾难恢复与文档加密具有关系。
在新的安全威胁形势下, 基于内容的深度安全分析已经成为目前数据安全的热点方向, 包括基于特征匹配的深度分析以及基于行为识别的内容分析技术等。从文档的创建、使用、流转、存储和销毁整个生命周期来看, 必然包含了对文档的安全保护。文档安全保护的手段, 基本上可以细分为:文档的加密处理、文档备份、文档的存储管理、文档的灾难恢复等。
(3) 加密软件集成到数据泄露防护 (DLP) 体系中, 成为DLP解决方案的一部分。早期的加密软件的基本思路是通过对核心文档加密, 从源头上控制文档的使用, 防止泄密。但是, 随着信息技术和管理理念的发展, 单一的加密功能已经不能满足现在用户的需求。
在信息安全管理方面, 分层架构多重防护理念已经是主流。在一个网络内部的多个区域, 通常采用多种方案的分层保护来确保信息安全, 此种方法可以避开单点安全防御的失败。虽然现在的加密软件结合了身份认证、权限管理、自动备份、日志审计等功能, 已经具备了分层保护的雏形, 但随着网络的不断发展, 这种工作还是存在着缺陷。
(4) 随着虚拟化技术的广泛应用, 数据泄露防护 (DLP) 将成为数据安全的最佳解决方案。虚拟化是把物理资源转为逻辑上可以管理的资源, 打破物理结构之间的壁垒, 物理资源都透明地运行在各种各样的物理平台上, 资源的管理都将按逻辑方式进行, 完全实现资源的自动化分配。虚拟化是大趋势, 有服务器虚拟化、存储虚拟化、网络虚拟化、终端虚拟化、桌面虚拟化等。
在虚拟化中, 加密软件多数采用C/S架构, 对主机、服务器、终端等物理位置上的文档进行加密。而虚拟化技术将给加密软件带来巨大的冲击, 首先是终端的虚拟化。因为终端不再存储文档, 所有文档数据将存放在虚拟的服务器上, 终端所操作的文档都只是虚拟的图像文件, 不用对本地文档进行管理。存储虚拟化的影响更为直接。虚拟存储将会把文档存放在某个虚拟的区域里, 不再像以前样存放在本机或者上传到服务器。
网络虚拟化将会使文档的存储途径发生巨大变化, 服务器的虚拟化将会使文档的存储位置变得更无序可循, 也正是这种“无序可循”对文档数据的加密要求更高。
综上所述, 虚拟化时代的文档管理, 特别是网络化的不断发展, 加密软件将无用武之地, 取而代之的是数据泄露防护 (DLP) 。DLP是一套完整的数据安全保护体系, 它智能的将文档进行过滤, 区别出文档是需要加密或者是普通文档, 然后将需要加密的文档进行自动、强制、透明地加密。与此同时, DLP将会通过有效的终端管理、网络边界管理、电子邮件管理、网络接入管理等手段, 防止非法用户连接到虚拟服务器, 并防止加密信息非法流出。而对加密文档合法流转到内网之后, 也能对加密文档进行管理。
参考文献
[1]金海.计算系统虚拟化—原理与应用[M].北京:清华大学出版社, 2008.
[2]王金波, 金涬，何乐，等.虚拟化与云计算[M].北京:电子工业出版社, 2008.
[3]郭玉东, 尹青.基于对象的网络存储[M].北京:电子工业出版社, 2007.
文档存储 篇5
本系统以Eclipse作为开发工具,前台采用EXTJS进行页面的设计,后台采用JAVA语言进行代码的编写、struts2技术实现控制层, 结合先进的云存储分布式功能,实现安全高效的教学文档管理。系统功能如下:(1)文档分类管理:课程设计管理、毕业设计管理、科研资料管理和教学资料管理等。(2)严格的用户权限管理,保证系统的安全。完成文档在线管理的常见功能,例如上传、下载、浏览、编辑和删除等功能。(3)操作界面支持响应式布局,针对不同的访问终端可以自适应屏幕布局。云存储的选择和设计,更高层面的实现文档的分布式备份。(4)利用Ajax技术,提高文档上传下载的速度。使用加密和解密技术,保障存储文档的安全性。
1系统设计
基于云存储的教学资料管理系统是适合教学管理及文件归档等特定功能的服务网站,以低成本和高质量为目标,同时支持手机和平板电脑等智能设备访问,可以实现基于文档的移动办公。
该系统包括三部分:前台、后台和云端。前台系统提供上传和下载功能,用户可以上传与课程或科研相关的资料到云盘或者从云端下载已上传的文档资料或作品。后台系统进行用户信息、文档的管理。云端主要的功能就是存储文档。
前台功能模块主要包括程设计作品的管理和毕业设计作品的管理等。具体功能如下:
(1)课程设计管理:按不同的课程进行分类,每门课程下都会有对应的学生提交的课程设计的作品的相关信息,包括学号、姓名、文档名称、上传时间、学期等,教员可浏览对应课程设计作品的信息, 并进行对课程设计作品的浏览、上传、下载和删除。
(2)毕业设计管理:毕业设计按作品的类别或专业方向分类,各个类别下都会有对应的学生的信息以及提交的作品文档的的信息, 教员可浏览对应毕业设计作品的信息,并进行对毕业设计作品的浏览、上传、下载和删除。
后台功能模块主要包括用户管理、课程设计作品管理和毕业设计作品管理等。具体内容如下:
(1)课程设计作品管理:对不同课程的课程设计作品进行不同的类别管理,包括上传、下载、删除。
(2)毕业设计作品管理:对不同专业方向的毕业设计作品进行分类管理,包括上传、下载、删除。
(3)教员文档管理:对教员的课程和科研以及信息进行管理,包括添加、删除等。
云端主要使用的云产品是七牛云,通过云来保存用户上传的作品,提高文档上传下载速度。学生登录后,查询已提交的作品以及自己的作品和个人信息。教员登录后查看、上传、下载和删除学生提交的作品,在线下载后浏览已上传到云端的文档资料。管理员登录后对学生、教员和管理员用户的管理,对课程设计和毕业设计的管理, 对教学和科研资料的管理,以及对资料的归档和备份。教学文档管理系统业务流程如图1所示。
2界面设计实现
该系统根据使用者权限的不同,分为不同模块。课程设计管理界面包括对应的课程界面和课程设计信息界面;毕业设计管理界面包括对应的专业信息和毕业设计信息界面;教学文档管理模块包括教员课程管理界面、教员科研信息管理界面;用户管理模块包括管理员用户类别管理界面、管理员用户管理界面;文档管理模块包括管理员文档归档界面、管理员文档备份界面。
2.1登录界面
如图2为登录界面。
2.2课程设计管理界面
课程界面按照不同的课程分类,如信息安全、组网技术等不同的课程,每门课程下分别有不同上传的课程设计的作品信息,学生用户只能上传、下载和删除自己的作品信息。如图3所示。
如图4所示。为用户管理界面。用户管理界面分为学生管理、教员管理、管理员管理,此权限只限管理员有,管理员可以分别添加和删除学生、教员以及管理员信息。
2.3教学文档管理界面
教学文档管理功能模块包括:课程分类显示;详细信息显示;浏览、上传和维护文档;教学文档查询等。
课程分类显示:课程按其性质不同进行分类,教员课程界面显示课程类别和该类别下教员所带课程。特殊权限教员课程界面可显示所有教员所带课程分类及课程信息。
详细信息显示:教员可点击课程类别下的课程名显示该课程的详细信息包括该课程的编号、名称、所属类别以及和该课程有关的教学文档等。
浏览、上传和维护文档:教员在统一整理该课程有关文档后可在学期期末之前上传到服务器,并可查看已上传文档的信息详情。 在学期结束前教员可删除已上传文档,并可对文档类文档进行在线浏览。
教员文档查询:在课程名对应课程详细信息界面下,教员可进行对已上传文档的查询,浏览该文档上传的详细信息。
具体如图5所示。
3数据库设计
本系统数据库中所需要的表有Users表、User Type表、Terms表、Courses表、Course_User表、Research表、Research_User表、 File_CU表。
数据表关系如图6所示。
4结语
基于云存储的教学文档管理系统采用java语言,使用extjs框架、 jsp和struts2技术,使用Mysql数据库存储用户信息。在该系统中,主要通过MVC架构的设计、实现了基于云存储的教学文档管理。该系统主要服务于学生和教员,采用电子文档管理方式,既解决了传统纸质存储方式已经不能满足安全存储和快速检索的需要,有节省了购买硬件的成本和人力维护的成本,并且通过程序设计,可以保证数据的安全和隐私,拥有良好的发展前景。
摘要：完善的教学文档管理对提高教育教学质量,推动教育工作健康发展和创新型人才培养作用重大,随着移动互联技术的飞速发展,云存储技术提供更为安全可靠的文档管理解决方案。基于云存储的教学文档管理系统实现档案的分类管理、用户权限管理、档案上传管理、档案存储管理及文档的在线编辑功能等。要求上传速度符合用户可等待度范围,存储采用分布式云储存解决方案,用户权限拥有不同等级,文档在云端的管理支持手机和平板电脑等智能设备。该系统利用前端支持HTML5 Mobile的应用框架,结合先进的云储存分布式功能,实现支持移动互联网的安全高效的档案管理。
关键词：文档管理,权限管理,云存储
参考文献
[1]Russell J.T.Dyer著,李红军李冬梅译.My SQL in a Nutshell 2edition.北京:机械工业出版社.2009(9).
[2]Kouresh Ardestani著,张哲峰译.extjs.北京:清华大学出版社.2003.
[3]朱玉超,鞠艳,王代勇.Ext Js高级程序设计北京:机械工业出版社.2008.
[4]余金山.ASP.NET 2.0+mysql企业项目开发与实战.北京:电子工业出版社.2008.
文档存储 篇6
一、传统关系型数据模式及操作
(一) 系统的功能结构图 (图1) 。
文档的分类与文档的基本信息都存储于标准关系型数据库系统中 (例如SQL Server) 。二者通过关键字段进行关联。
(表1) 文档分类表字段设置
查询代码:
Select文档名称分类名称from表1 INNER JOIN表2 ON表1.分类索引号=表2.分类索引号
这种模式下, 如果文档的分类越来越多, 层次越来越深, 使用关系型数据库存储容量快速增加, 数据冗余大量出现, 严重影响查询速度。同时, 系统上分类界面的树型结构显示也变得十分复杂, 需要用多层循环的递归来实现, 这种设计方法降低了程序的高效性、健壮性与复用性, 严重地增加了程序编写的负担。
二、XML数据结构模式的特点
当今众多开发语都支持对XML文件与数据的操作。针对XML的特性, 定义了各种操作和应用, 使得对XML数据的操作与显示更加简洁与高效。在APS.net中, 不仅可以对XML文件进行读和写。而且对于XML数据中的节点的操作也是应有尽有。同时为了将XML数据快捷、有效地显示在网页或应用程序上, 将treeview、map、menu等控件紧密地绑定在一起, 程序员只需简单地设置几个参数即可, 大大降低了数据层到表现层的开发难度, 使程序员从繁琐的代码工作中解脱出来, 进行更高效的逻辑设计。
三、关系型数据模式与XML数据模式的结合
对数据进行合理的分类与分解, 分别存储于不同模式的数据模式中。
(一) 新型模式下的文档管理系统功能结构 (图2) 。
在对系统功能和数据结构详细设计与分析下, 对数据进行合理的分类与分解, 使得过去全部存储在关系型数据库下的数据分别存储于不同的模式下。在XML文件中存放文档的分类设置信息, 文档的基本信息存于关系型数据库中。
(二) XML数据模式下数据结构的实现 (文件名为XML-File.xml) 。
具体如下:
(三) XML数据表现层的数据存取的实现。
第一步:设置XML文件数据源。
第二步:建立XML对象, 将XML数据源中的数据导入对象中。
(四) XML数据表现层的实现, 即与树型结构控制tree view的绑定。
第一步:页面上Treeview控件的建立。
第二步:Treeview控件与XML对象的绑定。
四、结语
XML在软件开发中的应用, 增加了数据存储的灵活性与多样性, 使传统的关系型数据模式得到了更大的扩展;XML数据模式的简单性与易构性, 使其成为多种软件、系统之间的桥梁, 通过XML格式使数据更易在不同的软件间流转与共享;XML与HTML同为开放式的标记性语言, 与HTML一样使用HTTP协议进行传送, 不仅WEB应用开发更加简单, 而且数据结合更加紧密, 实现了XML数据与HTML页面的无缝契合, 由此WEB应用的响应速度提高了, 健壮性也有了很好的提升。综上所述, XML数据模式的应用是高校文档管理系统最佳、最优的选择。
摘要：传统关系型数据模式严重影响了查询速度, 增加了程序编写的负担。XML数据模式大大降低了数据层到表现层的开发难度, 使程序员从繁琐的代码工作中解脱出来, 进行更高效的逻辑设计, 是一种新型模式下的文档管理系统。
关键词：数据映射,数据模型,文档分类
参考文献
[1] .何中灵, 黄黎艳.浅谈XML数据管理技术[J].科技致富向导, 2012
文档存储 篇7
随着互联网和信息化技术的快速发展,医院在逐步完成医院信息数字化建设过程中,它的核心技术之一就是电子病历的数字化管理和应用。电子病历包括病人就诊或治疗的全部临床信息,这些信息一般由数字、文字、图形和图像等数字信息组成。
本文仅对纯文本数据电子病例的存储和查询的性能进行分析和比较。电子病历的存储、交换、共享和使用要求电子病历必须以一种统一的格式规范或语法进行定义[1],能够支持高效的查询和更新存储。定义基于语义标记的XML文档格式[2]能够为解决各种类型的数据共享、交换和使用问题提供一种行之有效的技术解决方法。Oracle XML DB[3]和IBM DB2 pure XML[4]数据库管理系统都对XML文档提供了强大的支持,是将关系型数据和XML数据进行混合管理的数据库软件[5],但这两种XML文档技术解决方法,在电子病历的应用性能方面是否存在差异成为系统构架师和设计师高度关注的技术要素,本文就该技术要素展开分析和比较。
1 在存储和查询实现技术上的比较分析
Oracle XML DB和IBM DB2 pure XML都采用了W3C的XML数据模型,但在物理存储层的设计和实现差异很大。查询虽都是基于XQuery语言,但因采用了不同的存储技术而各自做了不同的封装和扩展。
1.1 在物理存储层实现方式比较
Oracle XML DB 11g 中针对不同的数据可选用三种不同的存储机制,即以大字符对象(CLOB)方式的非结构化存储、二进制存储和完全结构化的存储机制。
针对结构化存储,Oracle XML DB用XMLSchema所含信息派生一个对象模型、该模型可使符合XMLSchema的XML内容得到分解并以对象集的方式存入数据库。注册XMLSchema之后,Oracle XML DB为XMLSchema定义的每个全局元素创建一个默认的XMLType表,即对象表[6]。XMLSchema中的类型如String 、Decimal和Date 分别被映射成SQL中的Varchar2、Number和Date 类型。
当XML实例文档被装载进Oracle XML DB知识库时,XML文档内容将被“分解”并保存在对象关系表中。表1是在Oracle XML DB中采用结构存储方式存储XML文档的示例,该XML文档片段如下:
DB2 V9引入了DB2 pure XML支持,是一种高效的大字段存储模式,其性能优于传统CLOB的文本字段处理。因为XML 标签元素存有内在的层次结构,所以在DB2 pure XML数据库中的物理存储层主要存储单元是节点且以树型形式展现,同时可在保存XML文档层次结构的前提下,在节点的粒度上存储XML文档的片段,而不破坏其层次结构。图1为XML文档在DB2 pure XML中存储方式的示例。
由于Oracle XML DB把XML文档转换为关系表保存,基此方便XML文档的有效性验证,但插入时开销偏大。DB2 pure XML可高效维护XML文档的层次结构和加速对XML文档的检索性能。通过节点与父、子节点的关联有利于遍历。如果待查节点在同一页上,那么遍历速度将比指针遍历还快。
1.2 在查询方式上的比较
DB2提供两种语言规范查询 XML 数据,即SQL/XML 和 XQuery。既可以单独使用 XQuery 和 SQL,也可将 XQuery 嵌入 SQL 中使用,反之亦然。还增加了新的 SQL/XML 查询函数,包括 XMLQUERY、XMLTABLE 函数以及 XMLEXISTS 谓词。这些函数允许用户在 SQL 语句中嵌入 XQuery 或简单的 XPath 表达式。如果需要结合关系型数据和 XML 数据,那么 SQL/XML是一种最佳选择。
Oracle XML DB 对采用结构化存储技术保存的XML文档,尝试将SQL/XML运算符中的XPath表达式翻译成等价的SQL查询。SQL查询主要使用于基于模式的XMLType对象关系数据结构,该过程被称为XPath重写。XPath重写使得数据库能使用传统关系SQL操作来有效处理含有一个或多个XPath表达式的SQL语句。通过将XPath表达式翻译成传统的SQL语句,Oracle XML DB使数据库优化器无需理解XPath格式和XMLTpye数据模型。XPath重写处理的相关资源开销非常少,使得Oracle XML DB能以接近关系查询的速度执行基于XPath的查询[7] 。
Oracle XML DB 和DB2 pure XML的查询语言都基于XQuery语言。Oracle XML DB存在更细粒度的数据检索,而且基于 B 树和基于函数的索引使其得到了增强。实际应用中XQuery 是一种用于查询 Oracle 数据库存储的 XML 内容的高效方法。因为DB2不提供调用带参数标记的独立 XQuery 的方法,要向 XQuery 传递参数,则必须使用 SQL/XML 将一个参数标记(“?”)转换为指定变量,所以DB2中的SQL/XML是一种更佳的查询语言。
2 应用于电子病历系统的技术实现
本文通过示例说明Oracle XML DB和DB2 pure XML应用于电子病历系统的技术实现。本文设计和实践的电子病历系统分为中心服务器端的文档注册模块和客户端的文档提交模块。客户端按间隔时间参数值以批次方式向中心服务器端提交要注册的病历文档。客户端向中心服务器端一次提交的数据量称为提交集。每个提交集对应一个病人在数据库中的一条记录,它可以包含多份文档,这些文档组装成一条XML数据存入数据库。系统采用多库多表(分区)技术。存储时按照患者的唯一标识将数据按关联关系分布在多表中。
本系统开发语言基于JAVA;Oracle和DB2的数据库配置和多库多表策略均采用了Spring的动态数据源配置,持久层的操作采用了Spring的JDBCTemplate,系统服务方法之间的依赖关系通过Spring来管理,以利更好地进行效率测试对比。下面是要存入数据库中的XML电子病例文档片段示例:
<display>自胸廓入口向下扫描至两肺底,层厚、层距10mm。右肺上叶前段见一直径为1cm大小的肿块,平扫密度为Hu,可见分叶及毛刺;肿块早期强化较显著,密度较高且不均匀,其密度为Hu。周围肺纹理较粗;邻近胸膜可见凹陷征象。右侧肺门区可见淋巴结肿大。纵隔内亦见异常增大的淋巴结。纵隔内血管影正常。心影未见明显异常。</display>
<docs>标记为根节点,可包含多个<doc>节点,每个<doc>节点为一份病历文档。<doc>节点包含两部分内容:一部分为医院、科室、医生等信息,另一部分为详细的诊疗信息。
2.1应用Oracle XML DB的技术实现
本系统数据库采用Oracle 10g中Oracle XML DB存储和查询XML文档的技术实现路线概述如下。
1)XMLSchema约束
本文采用结构化存储方式,因此首先需要定义XMLSchema以约束XML电子病例文档的格式和数据类型。使用PL/SQL存储过程调用函数DBMS＿XMLSCHEMA.Registerschema()向数据库中注册复杂的XML模式。通过语句select schema＿url from user＿xml＿schemas;查看已经注册的XMLSchema。建立基于此模式的表。只要在建表语句后添加XMLTYPE COLUMN列名EL-EMENT″xds＿metadata.xsd#docs″就能把XMLSchema和表关联起来。
2)插入XML文档
通过JAVA的JDBC方式插入XMLType,根据SQL中参数的类型通常有3种方法供选择使用:第一种,客户端只需传递一个字符串参数,通过Oracle数据库的sys.xml Type.create XML()函数构造成XMLType类型的值[8]。由于把创建XMLType的任务完全交给数据库,此方法对数据库的压力最大;第二种,客户端调用JAVA API函数XMLType.create XML(conn,xmldata)创建一个XMLType给数据库,此方法将创建XMLType的任务完全交给了客户端,因此数据库的压力最小;第三种,在客户端把XML文档转换为ORACLE.SQL.CLOB类型再传入数据库端,通过Oracle数据库的XMLTYPE()函数构造成XMLType类型的值。此方法客户端和数据库端同时承担了创建XMLType的任务,因此数据库的压力居中。
上述第一、第二种方法的XMLType型字段只能存储4k字节的数据,当添加超过4k字节的XML文档到XMLType型字段时不能采用直接插入字符串的方式,建议采用第三种方法。
为了更好地对Oracle XML DB和DB2 pure XML关于存储、查询和更新性能做对比,本文采用JDBCTemplate方式存入数据,相关程序片段如下:
上述代码通过向get Jdbc Template().update(sql,params,types)函数传递三个参数分别为SQL语句、参数的值和参数的类型,实现向table Name表中插入XML文档。
3)查询XML文档
根据指定患者全局唯一标识符(Patinet ID)和相关文档的可用性状态查询XML文档信息,通过参数作为进一步的限定条件。使用Oracle中的SQL函数get String Val()只能查询小的文档数据,当文档数据太大时需使用XMLQuery()方法或EX-TRACT()方法。
不失一般性的查询语句示例如下:
根据病人的ID从表registry12中的XMlType类型的DOCU-MENTENTRYS列查询出病人的所有文档即所有的doc片段,有两种查询方式:
使用XMLQuery()函数查询DOCUMENTENTRYS列docs条目下包含的所有doc片段。
查询XMLType类型的DOCUMENTENTRYS列的docs节点下包含的所有doc节点。
4)应用程序获得查询结果的方法
用Jdbc Template().query()函数查询出XML文档,用orset.get OPAQUE()函数取出结果集中的一条数据,使用XML-Type.create XML()函数转换为XMLType类型。
2.2应用DB2 pure XML的技术实现
用于性能比较的数据库使用DB2000,数据存储和查询采用DB2 Version 9的pure XML技术。基于DB2 pure XML存储和查询XML文档的技术实现路线概述如下:
1)创建XML文档的存储表
根据实际需求,创建XML文档的存储表程序如下:
2)存储XML电子病例文档到DB2数据库
存入XML字段的参数为XML文档的字符串,采用JDBC-Template方式存入数据:
向函数get Simple Jdbc Template().update(sql,param)中传递两个参数分别为SQL语句和SQL语句中的参数值实现向表中存入数据。
3)查询要求与Oracle XML DB中的要求相同
使用带表空间的XMLQUERY()的查询语句如下:
查询DOCUMENTENTRYS列下的docs标记下的所有doc片段,即病人的病历文档。DOCUMENTENTRYS/docs/doc为查询路径。
4)使用Spring的JDBCTemplate获得结果集
相关程序如下:
使用get Simple Jdbc Template().query()函数的行映射功能返回结果集中的每一条数据。
3 关于存储和查询XML电子病历的性能测试
存储负荷:Oracle XML DB和DB2 puer XML的提交集和每个提交集包含的文档数量均相同。
查询要求:根据患者ID把所有属于此患者的病历文档完整地查询出来。
查询测试条件为从数据库一张表中查询出属于某个病人的所有完整的病历文档。
提交集数量为表中含有的数据量。
存储性能测试结果如表2所示。
查询性能测试结果如表3所示。
由表2和表3容易看出,在存储相同XML文档量负荷和相同查询限制条件下,Oracle XML DB 与DB2 pure XML关于存储和查询的耗时之比分别约为2∶1和1.32∶1。
图2为Oracle与DB2性能测试对比。X轴为提交集的数量,Y轴为提交数据耗时。每个提交集的文档数量固定为20份。由图2可以得出提交集数量与Oracle和DB2的耗时都成线性关系。Oracle 的线性比例系数为K=47.375,DB2的为K=20.22,说明提交集数量越大Oracle所花费的时间增长的速度也越快。
4 结 语
本文分析了Oracle XML DB 和DB2 pure XML关于存储和查询XML文档的技术特点及其实现原理,并就测试准备给出了相关程序片段。Oracle XML DB按对象关系型存储数据到基于模式的XMLTYPE 表列中,这种细粒度的拆分可以方便地执行XML文档的有效性验证,但在存储上要多花费时间。查询时Oracle XML DB将SQL/XML中的XPath表达式翻译成等价的SQL查询,再去查询相应的表列,在查询完整的XML数据文档时同样耗费更多的时间。DB2 pure XML是根据XML数据层次结构按节点的方式存储数据,在节点粒度上存储XML文档的片段。这在存储和查询完整的XML文档的速度上比Oracle XML DB的技术实现更具优势,但是在应用程序端需要花费额外的时间对XML文档的有效性进行验证。
本文给出的测试对比结论提示应用这两种产品时,要在数据存储、查询速度和数据质量方面根据应用场景做出合理的取舍和平衡。
参考文献
[1]巴斯,等.软件构架实践[M].车立红,等译.清华大学出版社,2004.
[2]Houqin SU,Jinquan SU.A Study and Practice of Report System Tech-niques based on Three-layer Calculating Architecture[C/OL].The 2ndInternational Workshop on Education Technology and Computer Sci-ence(ETCS2010),March 6～7,2010-03-06/07,Wuhan,Chian.http://www.icetcs.org/etcs2010/.
[3]任金铜.基于Oracle XML DB的GML存储_查询及索引研究[D].江西理工大学,2009.
[4]使用SQL查询DB2XML数据[EB/OL].http://www.ibm.com/de-veloperworks/cn/data/library/techarticles/dm-0603saracco2/.
[5]覃永胜,等.Oracle XML DB和DB2pure XML在基于XML电子病历实现技术方面的比较分析[J].医学信息学杂志,2009(30):10-13.
[6]Murthy R.XML Schemas in Oracle XML DB[S].Oracle Corporation.
[7]Oracle SQL/XML(XML的详细介绍)[EB/OL].http://meidayhxp.blog.163.com/blog/static/11760815620103295626909/.