基于关系数据库的地籍空间数据存储结构

基于关系数据库的地籍空间数据存储结构（通用7篇）

基于关系数据库的地籍空间数据存储结构 篇1

存储结构之数据文件和表空间

oracle存储结构，可分物理结构和逻辑结构，后者是为方便管理前者而生。

oracle把数据逻辑地存放在表空间里，物理地存放在数据文件里。

有两个视图，我们可能会常用到：

dba_data_files:描述数据文件的信息

dba_tablespaces:描述表空间的信息

这里先谈三个问题。

表空间的类型?

1)永久性表空间，如：system，sysaux，user等

sysaux用于存放非核心功能的数据，如OEM

查看存放了哪些非核心功能的数据：

select occupant_name,occupant_desc,schema_name

from v$sysaux_occupants;

2)临时表空间

用于排序，创建索引

oracle建议，为每个用户创建一个临时表空间;

10g引入临时表空间组

3)undo表空间

虽有多个undo表空间，但任一时点，只有一个undo表空间被激活。

不同类型的表空间会产生不同的写入方式和时机点

永久性表空间

DBWn写入有两种方式多个时机点

方式一：

LRU机制：

LRU list：保存最近被存取的数据块;

Dirty list：被修改但尚未写入数据文件的数据块;

时机点：

1)Dirty buffer达到阀值时

2)没有free buffer时(server process在LRU list里找不到足够多的free buffer)

3)每3秒，DBWn会去检查dirty list，如果dirty list未到域值，就去读LRU list，将dirty buffer移到dirty list;如果dirty list已满，则写入数据文件，

方式二：

检查点事件：

时机点：

1)log switch时，要求做检查点，即：把dirty buffer flush到数据文件。也即：DBWn将dirty buffer从LRU list中移到dirty list，然后把dirty list中的dirty block flush到数据文件。

2)表空间下线或热备时，

3)drop一个对象时，

4)关闭数据库时

表空间组成?

段：占用存储空间的数据库对象，如：emp表又叫emp段。可跨越数据文件，但不能跨越表空间。

区：连续分配的空间。不能跨越数据文件。注意：这里的连续可能会带来空间碎片

块：

1)一个数据库中允许不同块大小，主要用于可传输表空间

2)通常，数据库中5种不同块大小：默认和非默认。在特殊情况，还存有非标准(不是2的幂)。注意：system表空间总是使用默认块大小，一个表空间中所有块的大小都相同。

3)块组成：

块开销：块头，表目录，行目录(指针表：指向每条记录)

空闲空间

数据空间

4)块头：数据块地址，数据块类型，事务表(ITL)

ITL:行级锁和读一致性的实现基础，每条记录含：UBA(undo block address)，事务号，SCN号

一致性读：oracle对每次用户查询都要记录查询开始的SCN号，用于和数据块中的SCN号比较，如果数据块中的SCN号大于查询SCN，oracle就会利用UBA信息构造CR块，然后再比较CR块中的SCN号和查询SCN，如果仍然大于查询SCN，则还需要继续构造，直到CR块中的SCN小于或等于查询SCN，若还是找不到，就会报ora-01555错误了。

作者 linwaterbin

基于关系数据库的地籍空间数据存储结构 篇2

关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于表与表之间进行连接等操作,但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储,它的结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。

随着互联网技术的发展以及企业IT信息化技术的普及,用户的对企业信息化的认可度不断升温,用户的需求也越来越来越个性化。传统的关系数据库在应付这种个性化需求时已经显得力不从心,暴露了很多难以克服的问题,而非关系型的数据库No SQL则由于其本身的特点得到了非常迅速的发展。

No SQL数据库崛起的原因是数据作用域发生了改变。它们不再是整数和浮点等原始的数据类型,数据已经成为了一个完整的文件。由于DBA(数据库管理员)正在逐渐丧失对其领域的控制权,因此No SQL可能将让DBA感受到了压力。

但目前No SQL数据库的应用并未普及,技术上并不成熟。那么,如何将当前比较成熟的关系型数据库与非结构化数据结合起来应用,使两者各自发挥自身的优势成为了一个难点。

1 No SQL简介

1.1 关系数据库的缺陷

在当代的IT信息时代,web2.0网站更加倾向于纯动态化、高并发化,在此其间产生了许多不受约束的大规模数据。web2.0网站对这些数据具有高效的存储和大并发量读写等的要求。同时很多网站提供24小时网上服务功能,而关系型数据库系统的升级、扩展往往需要停机维护和数据迁移。因此,网站的维护就要要求数据库具有更加良好的可扩展性。

关系型数据库应付这些要求已经力不从心,不受约束的大规模数据之间错综复杂的关系更使得关系型数据库暴露出很多难以克服的实际问题。

1.2 No SQL定义

No SQL(No SQL=Not Only SQL),意为反SQL运动,是一项全新的数据库革命性运动,早期就有一些人提出,发展至2009年趋势越发高涨。No SQL的拥护者们提倡运用非关系型的数据存储,相对于现代铺天盖地的关系型数据库运用,这一概念无疑是一种全新的思维的注入。

No SQL的主要特点包括非关系的、分布式的、开源的和水平可扩展性。

No SQL的原始目的是为了大规模的web应用,在数据存储中,通常的应用如模式自由、支持简易复制、简单的API、最终的一致性(非ACID)、大容量数据等。No SQL用得最多饿是key-value(键值对)存储,还有文档型、列存储、图形数据库等。

1.3 No SQL的特点

(1)No SQL可以运行在便宜的PC服务器群上。这样PC服务群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性、成本。

(2)No SQL打破性能瓶颈。通过No SQL数据架构可以省去将Web或Java应用和数据转换成SQL格式的时间,执行速度变得更快。“SQL并非适用于所有的程序代码,”对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。

(3)No SQL可以处理超大量的数据高并发和高存储。

(4)No SQL没有过多的操作。

1.4 No SQL与关系型数据库比较

关系型数据库中的表都是存储一些格式化的数据结构和数据元素,每个元组(行)字段(列)的组成都是一样的,即使不是每个元组(行)都需要所有的字段(列),但数据库会为每个元组(行)分配所有的字段(列),这样的结构可以便于表与表之间进行连接等操作,但从另外一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库No SQL以键值对存储,它的结构是不固定的,每一个元组(行)可以有不一样的字段(列),每个元组(行)可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。

2 通用数据存储结构的问题情景分析

在当今社会,用户网上缴费和支付的需求量越来越大。针对目前用户网上支付需求量大的问题,我们开发了一套在线缴费系统,本系统前端部分可通过多种方式产生订单,应用于不同的缴费项目,例如物业费、学杂费、通讯费等等,根据不同的缴费项产生订单,订单中的订单号、缴费时间、缴费金额等字段可共用,但与订单相关的其他附属属性则不同,比如物业费订单中含有房号、业主姓名等信息,学杂费订单中含有学生姓名、学校名称、院系、班级、学号、性别等信息,而在通讯费中,含有电话号码、姓名、区域、缴费项目等等信息。如何做到同一套系统部署时,不用修改代码即可挂载不同的应用,存储对应缴费项目的订单成为开发人员需要解决的难题。在本论文中我们不详细介绍系统组建的过程,只介绍使用No SQL数据库搭建通用数据存储结构的方案设计。

3 存储结构设计

3.1 存储结构设计

本论文介绍的数据存储结构的设计主要是依据在线缴费系统来介绍,具体的字段不在这逐个介绍,只介绍与本存储结构相关的字段内容举例。

依据No SQL数据库存储数据的基本思想,在关系型数据库中新建数据库时,在表结构中新建一个blob类型的字段,将与订单相关的个性化附属属性以高性能的JSON格式存放,比如物业费在关系数据库中数据存储的字段为:订单号、支付金额、支付时间、订单属性;其中订单个性化属性的存储的数据有:房号、业主姓名、小区名称、小区地址,存储该数据的存储格式为:

{"house Id":"1-2-101","owner Name":"张三","area Name":"关中花园","address":"幸福路12号"}

其他通用属性,如订单号,订单金额,支付时间,支付状态等仍然存在对应表字段中,如图1所示。

数据存储样例:

通过以上存储结构的设计,可以解决不同缴费项目的订单数据在相同的关系数据表中的数据存储问题。从而,将缴费系统前端订单模块抽象成了通用的订单数据存储模块,当有新的、异构的缴费项目新建时,订单存储模块不需要做任何改动。这种方式可以通用语物业费、学杂费、通讯费等等在线缴费系统的使用,这样就可以把多个系统融合为一个系统来完成。

3.2 数据保存

采用以上结构存储订单数据以后,数据保存时,需要将订单记录中的个性化属性构建成JSON格式保存,构建方法通常有直接构建JSON串,或者先构建Map对象,再转换为JSON串。

3.3 数据查询

对于web网站操作中,应用最多的就是对数据库中数据的查询功能和对查询结果数据的存储,在关系型数据库中数据查询的语法大多数都是进行检索词和关键词之间进行匹配性比较,也就是说数据查询时,关系数据库其他字段按照关系数据库查询语句的语法进行匹配查询,语法格式一般用:select字段名from表名where匹配查询条件group by查询分组。对于个性化属性部分的查询,则需要使用LIKE语句的方式模糊匹配查询。查询结果显示时,可直接通过Key-Value方式获取数据,或者先进行对象转换,再通过对象属性获取数据。

4 应用示范

缴费平台已经投入使用,当前在物业费缴费、学费缴费、通讯费缴费等领域已运营两年,同时,业务领域仍在不断扩大,但系统的订单存储结构仍然采用目前这种模式,实践证明,此模式对于软件开发人员实施快速开发以及满足用户方的个性化需求等方面起到了很大的作用。同时,我们也在不断探索实践,通过这种模式的引入,我们在此基础上又设计了关系数据库个性化属性的导出、分类、生成个性化报表等。此方法的应用对提升用户的体验、满足用户的个性化需求上起到了积极的作用。

5 结束语

通过将不固定属性以JSON格式存储在某个固定字段中的方法,解决了数据灵活多变,利用关系数据库构建通用程序的问题。但同时此方法也存在一定的弊端,当数据量不断增大时,针对个性化属性字段内容的查询效率会逐渐降低,虽然可通过全文检索的方式来解决此问题,但并不是所有的数据库都支持全文检索,部分数据库由于版本问题、中文支持问题、数据存储引擎类型的差异等无法解决此问题。

摘要：针对目前软件开发中关系数据库表结构无法适应数据记录属性不固定的情况,该文提出了一种将不固定属性以JSON格式存储在某个固定字段中的方法,解决了数据灵活多变时,利用关系数据库无法构建通用程序的问题。

关键词：关系数据库,JSON,通用程序

参考文献

[1]汉德罗克.Ajax——Web开发、可重用组件及模式[M].北京:清华大学出版社,2011:28-31.

[2]韩义波,宋莉,宋俊杰,等.Ajax技术结合XML或JSON的使用比较[J].电脑知识与技术,2009,(01):101-103.

基于关系数据库的地籍空间数据存储结构 篇3

关键词： 链式存储结 指针变量 赋值运算

Teaching Methods of Linked Structure in "Date structure"

Kan Nan

（Department of Information Engineering, WuHan Vocational College of Information Transmission Technology, Nan Kan, 430074 , China）

Abstract：Pointer is a difficulty for students to grasp in linked structure; there is one question about it. For example assignmentoperation about pointer variable,,Based on this, author discusses new teaching methods.

Keyword: linked structure; pointer variable; assignment operation

《数据结构》主要研究信息的逻辑结构及其基本操作在计算机中的表现和现实，是计算机专业的核心课程。链式存储作为该课程讨论的重要的储结结构之一，是学生应掌握程序设计技巧的基础。

从进几年《数据结构》课程的教学过程反映出，当讨论链式存储结构时学生出现理解上的“瓶颈”现象。问题集中体现在：指针变量与指针赋值运算。下面就这一问题谈谈教法与感受，希望与同仁共勉。

首先我们引入两个概念 “菜篮子”和“菜”而且要分清它们。 说到赋值语句，我们先来回顾一下赋值运算的实质。尽管不同语句的赋值语句有不同的语法结构，但大都数语句所定义的语意大体相同。下面以C语言为例说明：

某程序段中语句x=y；x和y是变量名，无论他们是数据类型，每一名字有两个“身份”：一方面该变量名代表一定的存储单元，另一方面代表该存储单元里的内容，以该单元的内容为值。赋值语句x=y的意义是：“把y的值送入x所代表的存储单元”，也就是说，赋值语句中赋值号“=”左右两边的变量名扮演着两种不同的角色。为了区别一个变量名的两种“身份”我们把一个名字所代表的那个存储单元称为该名的左值，通俗地说是“菜篮子”用来装菜的；把一个名字所代表的的单元内容（值）称为该名的右值，对应的就是“菜”。当变量名出现在等号左边就是“菜篮子”出现在等号右边就是“菜”，赋值运算就是把“菜”往“菜篮子”里放（注意这儿的“菜篮子”的特殊性：最后一次方的“菜”就覆盖“菜篮子”里以前放的“菜”，且“菜篮子”里只能放一个“菜”）。

对变量名的双重性有了以上的深刻认识在来讨论指针变量的赋值运算学生就恍然大悟了。

例1： 有定义如下的双向链接表

struct dnode {elemtp data;

struct dnode *prior, *next;}*p,*r;如图1所示，在双向链接表中的结点之前插入一个结点r使线性表（a1…ai，ai+1…an）变成（a1…ai,b,ai+1…an）。操作语句如下；

{1}r->prior=p->prior;

{2}r->next=p;

{3}p->prior->next=r

{4}p->prior=r;

以上4条语句的语义分别是：

{1}把数据元素ai所在的结点地址（在p的prior域中放着的地址值，此時表现为变量p->prior所代表的内容，以后简称右值，也就是我们所说的“菜”）放到结点r 的prior域中(此时r->prior应以其所代表的存储单元的身份出现，即左值，也就是“菜篮子”)这就是把变量p->prior所代表的存储单元的地址值赋值给变量r->prior所代表的存储单元，即把“菜”放进“菜篮子”，线1所代表的链建成了。注意千万不能把该语句中理解为其左值，我们是不可能把“菜篮子”放进“菜篮子”的

{2}把数据元素ai+1所在结点的地址（是变量p代表的内容，即p的右值）放到结点r 的next域（是变量r->next代表的存储单元，即左值）。变量p的值作为“菜”放进了变量r->next这个“菜篮子”，线2所代表的链建成了。

{3}把被插入数据元素b所在的结点的地址（该地址作为值在r所代表的存储单元中放着，即r右值）放到数据元素ai所在的结点next域中，而数据元素ai所在的结点就是p->prior（因为数据元素ai所在的结点地址在p->prior中放着，此时取其右值），那么数据元素ai所在的结点next域中就是p->prior->next这个“菜篮子”，此时语句实现使b变成ai的后续，经赋值后原链5自然断掉。

{4}把被插入数据元素b所在的结点的中的地址，放到数据元素ai+1的地址，放到数据元素ai+1所在结点prior域中，变量r的值再次为“菜”放入了变量p->prior“菜篮子”，就使b称为ai+1的前驱，经赋值后原链自然断掉。

以上4条语句{1},{2}的次序可以调换，{3},{4}的次序不可以调换，而且{1},{3}语句必须在{4}之前，只要学生对赋值语句能有以上的深刻理解，其原因就不言而喻了。再复杂的链式存储结构及其操作一般都涉及改变链的状态，其无非就是通过赋值语句来改变链，在操作中分清变量“菜篮子”和“菜”的双重角色，对学生掌握链式存储结构起着重要的作用。

参考文献：

[1]Horowitz ES. Fundamentals of Data Structures. Pitmen Publishing Limited, 1976

GML空间数据原生模式存储研究 篇4

从国内外研究进展来看,原生数据库环境下GML空间数据管理机制的研究还处于非系统化、非全面化、非应用化的部分内容研究、初始研究阶段。对原生模式GML空间数据管理机制系统、全面的研究还需深入、具体的开展。本文借鉴XML数据管理机制思想,提出了一种基于原生XML数据库的原生GML空间数据存储模型;提出了一种原生GML空间数据库系统架构体系,为原生GML空间数据库存储机制提供了一种方法。

1 GML空间数据存储模型

原生XML数据库的基本(逻辑)存储单元是XML文档,正如同关系数据库中的基本(逻辑)存储单元是二维关系表中的一条记录一样(也即,原生XML数据库中数据的存储是文档进、文档出,而关系数据库中数据的存储是记录进、记录出)。一般,原生XML数据库都有集合(Collection)的概念,一个集合是若干XML文档(甚至包括其它嵌套集合)的群集,其功能和特征与关系数据库中的二维表、文件系统中的文件目录类似。集合的设计,确保对XML文档的操作(存储、索引、查询、更新、删除等)可以在一个文档群集中进行。与二维关系表都有一个模式与其对应不同,原生XML数据库中的集合可以没有与其对应的模式,也即,它是模式独立的(Schema-independent)。集合的模式独立性使得原生XML数据库拥有了很多灵活性,并且为应用开发提供了很多便利;如,XML文档的存入、读取无需对应的XML文档模式的支持即可实现。

原生模式GML空间数据存储时,其理想存储模型也应为GML文档。并支持文档集合以及集合的嵌套,如此对GML文档的存储、查询、更新、删除等都可以在一个文档群集中进行。并且集合支持模式独立性,以便于GML实例文档的灵活存入与读取。

在存储粒度上,一般XML数据库的存储粒度分为:(1)粗粒度存储;即XML数据的存储以整个文档为存储粒度,此存储粒度不利于XML文档的查询和粒状更新。(2)中粒度存储;即XML数据的存储以XML文档树中的子树(元素集合)为粒度,此存储粒度可方便实现XML文档的查询和粒状更新,但效果视具体应用而定。(3)细粒度存储;即XML数据的存储以XML文档中的元素为粒度,此存储粒度可最大限度的灵活实现XML文档的查询和粒状更新;不过,由于以元素为粒度,处理时具有一定的开销。

对于GML文档的存储,本文在充分考虑GML索引构建、GML空间/非空间数据查询所采用的机制、算法、策略等情况下,并结合一些原生XML数据库系统(如eXist)的存储特性,确定其存储粒度为细粒度,以便于原生GML空间数据库系统的设计、实现和应用。

2 原生GML空间数据库系统架构体系

在对XML、GML、经典关系型数据库系统、传统空间数据库系统、原生XML数据库系统等分析的基础上,本文提出了一种原生GML空间数据库系统架构体系(见图1),其涵盖内容如下。

2.1 原生GML空间数据库系统定义

原生GML空间数据库系统是以GML文档为存储模型,对GML文档进行数据组织、索引构建、存储分配、查询处理的数据库系统。系统对GML文档的读、写采用文档进、文档出模式;系统查询语言采用支持空间数据的扩展XQuery语言,可进行GML空间与非空间数据的一体化查询与更新处理;系统支持多种GML数据访问的API;同时,系统也具备传统数据库系统所具有的多用户多任务并发、事务、回滚、访问控制、备份等机制,以支持在包括分布式网络在内的各种环境下的应用。

2.2 GML数据管理

原生GML空间数据库系统中存储的数据主要是GML实例文档,而GML实例文档一般都有对应的GML应用模式文档,以约束、控制和校验GML实例文档的结构与内容。因此,GML数据管理模块涉及GML模式文档管理和GML实例文档管理。

GML模式文档管理负责:(1)采用GML解析器对GML模式文档进行解析,提取出与GML实例文档中元素对应的各种元素类型信息,并提交GML实例文档管理子模块,由其负责依据元素类型信息采用GML解析器对GML实例文档进行解析。(2)采用GML解析器对GML模式文档进行解析并构建节点树再提交GML存储管理模块进行存储。(3)建立、维护GML模式文档存储检索表,以备GML查询处理模块对GML模式文档进行全文查询。(4)响应GML查询处理模块对GML模式文档的查询请求,并返回目标模式文档。

GML实例文档管理负责:(1)采用GML解析器对GML实例文档进行解析、构建节点树,并提交GML索引管理模块以构建GML非空间数据索引。(2)接收GML模式文档管理子模块发送的GML实例文档元素类型信息,据此采用GML解析器对GML实例文档进行解析,以提取GML要素、几何、拓扑等对象,并提交GML索引管理模块实现对GML空间数据的索引构建。(3)原生GML空间数据库系统支持集合(以及集合的嵌套),因此,在将GML实例文档相关信息提交GML索引管理模块时,也提交关联集合的信息,以便于构建索引。(4)当不对GML实例文档构建索引时,采用GML解析器对GML实例文档进行解析并构建节点树再提交GML存储管理模块进行存储。(5)建立、维护GML实例文档存储检索表,以备GML查询处理模块对GML实例文档进行全文查询。(6)响应GML查询处理模块对GML实例文档或集合的查询请求,并返回目标实例文档或集合信息列表。

GML实例文档入库时分两种情况:有GML模式文档相伴和无GML模式文档相伴。当无GML模式文档相伴时,将无法有效的建立GML空间数据索引。

2.3 GML索引管理

索引管理是一个数据库系统重要的功能模块。

GML文档向原生GML空间数据库存储时需对文档中的GML空间和非空间数据建立索引,以便高效进行GML空间数据的查询。与GML空间数据文档存储入库时不构建索引相比,存储时建立索引将耗费更多的时间;但是从数据库的整体操作、使用而言,一般遵从“操作局部性”(类似于计算机科学中的时间局部性原理和空间局部性原理),表现为通常对数据库中数据的增加、删除、修改、查询等操作,一般情况下局部化为查询操作。鉴于此,GML空间数据存储入库时因建立数据索引而额外耗费的时间,对于数据的后续操作和使用管理是非常有价值的。

GML索引管理包括:GML非空间数据索引管理和GML空间数据索引管理两个子模块。

GML非空间数据索引管理负责:(1)接收GML数据管理模块发送的GML实例文档解析、构建的节点树,并采用XML文档编码方案(如论文提出的Ex-Dewey前缀编码方案)对GML实例文档构建GML非空间数据索引。(2)接收GML数据管理模块发送的与GML实例文档关联的集合信息,以共同对GML实例文档构建GML非空间数据索引。(3)将构建的GML实例文档非空间数据索引信息数据提交GML存储管理模块进行存储,并同时提交GML实例文档节点树数据,对GML实例文档数据进行存储。(4)协调GML空间数据索引管理子模块对GML实例文档构建空间索引。(5)响应GML查询处理模块对GML非空间数据的查询请求,并返回相关索引信息数据。

GML空间数据索引管理负责:(1)接收GML数据管理模块发送的对GML实例文档解析后提取的GML要素、几何、拓扑等对象数据,并采用R树、R+树等经典空间数据索引算法实现对GML空间数据的索引构建。(2)接收GML数据管理模块发送的与GML实例文档关联的集合信息,以共同对GML实例文档构建GML空间数据索引。(3)将构建的GML实例文档空间数据索引信息数据提交GML存储管理模块进行存储。(4)与GML非空间数据索引管理子模块交互,完成对GML实例文档空间索引的构建。(5)响应GML查询处理模块对GML空间数据的查询请求,并返回相关索引信息数据。

由于GML实例文档索引的构建比较耗时,可采用后台服务进程/线程自动构建索引的方式,从而保证GML实例文档可以迅速存入GML空间数据库中。当GML实例文档索引后台自动构建还未完成时出现查询请求,可采取的策略是直接对GML实例文档进行检索。根据局部性原理,通常GML实例文档入库后不会很快出现大量、频繁的查询请求,此时直接检索GML实例文档是可行的,当索引构建完成后则可先查询索引,然后快速定位GML目标数据。

2.4 GML存储管理

GML存储管理负责:(1)GML模式文档、GML实例文档、GML集合信息、GML实例文档非空间数据索引信息、GML实例文档空间数据索引信息的物理存储。(2)GML模式文档、GML实例文档、GML集合信息、GML实例文档非空间数据索引信息、GML实例文档空间数据索引信息的提取。(3)响应GML查询处理模块对GML空间、非空间数据的查询请求,并返回实际数据。

GML存储管理采用原生XML数据库系统(如eXist)已有的存储管理模块,实现对上述功能的支持。

2.5 GML查询处理

GML查询处理既要实现一般XML数据的查询功能,又要实现GML所特有的空间数据查询功能。它包括:GML查询解析、GML查询执行、GML查询结果构造等子模块。

GML查询解析负责对GML查询语句(由XQuery查询语言增加空间扩展支持实现)进行解析,对查询语句结构、合法性等进行分析,如果语句不合法则返回错误信息,否则对查询语句进行分类(包括:GML模式文档全文查询、GML实例文档全文查询、GML集合信息查询、GML非空间数据查询、GML空间数据查询、GML空间、非空间数据混合查询等),并将分类信息提交GML查询执行子模块进行查询执行。

GML查询执行负责根据查询语句分类信息进行数据的查询执行,并将查询结果提交GML查询结果构造子模块。之中:(1)对于GML模式文档全文查询、GML实例文档全文查询、GML集合信息查询直接访问GML数据管理模块,由其执行并返回结果。(2)对于GML非空间数据查询则先访问GML索引管理模块,由其返回与查询相关的索引信息数据,然后采用结构连接算法(如论文提出的ED-XQ-SJ算法)确定符合查询条件的节点信息,并进而依据索引信息中节点编码值所对应的节点物理存储地址,通过GML存储管理模块读取节点实际数据。(3)对于GML空间数据查询则先访问GML索引管理模块,由其返回与查询相关的索引信息数据,然后利用空间索引构建采用的算法(如R树算法)确定符合查询条件的GML要素信息,并进而依据索引信息中GML要素所对应的物理存储地址,通过GML存储管理模块读取GML要素的实际数据。(4)对于GML空间、非空间数据混合查询,则先执行GML非空间数据查询,在其结果集上结合对应的空间索引信息以及非空间索引信息,进一步执行空间数据查询,并最终通过GML存储管理模块获取实际的GML数据。

GML查询结果构造负责将查询获取的目标原始数据,依据数据关系(如节点编码值等)进行GML格式的数据构造,并返回(对于GML模式文档全文查询、GML实例文档全文查询、GML集合信息查询则直接返回)。

2.6 GML数据访问API

为方便原生GML空间数据库的使用,需要构建各种GML数据访问的API,如:类似XML-RPC、XML:DB API的访问接口,能够通过SOAP、HTTP进行GML数据访问的接口等。GML数据访问API将可直接访问GML数据管理模块和GML查询处理模块。

2.7 其它支撑

一般数据库系统都具有多用户多任务并发、事务、回滚、访问控制、备份等机制,原生GML空间数据库系统也需具备上述特征,以便于在包括分布式网络在内的各种环境下使用。GML空间数据库将采用原生XML数据库系统(如eXist)已具备的上述机制实现对上述功能的支持。

将原生GML空间数据库构建于原生XML数据库系统之上,不仅可以充分利用XML数据库系统已有的成熟功能与机制,而且可以将XML文档、GML文档共储于同一数据库系统中,实现GML地理空间数据、XML普通事务数据的一体化存储;正如当前基于关系型数据库的地理空间数据库系统一样(如:Oracle Spatial)。

3 结语

与XML数据存储类似,GML空间数据的存储方式也包括:文件存储管理方式、关系数据库存储管理方式和原生数据库存储管理方式。原生GML空间数据的存储构建于原生XML数据库之上是一种理想的选择。基于开源原生XML数据库(如:eXist)并充分考虑GML索引构建、GML空间、非空间数据查询所采用的机制、算法、策略等情况,原生GML空间数据的存储模型以细粒度(即,存储以GML文档中元素为粒度)为宜。本文进一步重点研究、设计了原生GML空间数据库系统架构体系,给出了系统定义、系统架构与系统模块的交互原理与技术方法;系统模块包括:GML数据管理、GML索引管理、GML存储管理、GML查询处理、GML数据访问API,以及多用户并发、事务、回滚等其它支撑模块。

摘要：大量GML空间数据的出现,使其有效性存储管理面临严峻挑战。鉴于GML空间数据XML格式编码的特点,本文分析并借鉴XML数据存储方式,提出GML空间数据的存储构建于原生XML数据库之上是一种理想的选择。基于开源原生XML数据库并充分考虑GML索引构建、GML空间、非空间数据查询所采用的机制、算法、策略等情况,本文提出GML空间数据的原生存储模型以细粒度为宜。本文进一步着力研究、设计了原生GML空间数据库系统架构体系,给出了系统定义、系统架构与GML空间数据存储、索引、查询等原理与技术方法。

关键词：GML空间数据,原生XML数据库,原生存储模型,原生GML空间数据库

参考文献

[1]OGC.OpenGIS Geography Markup Language(GML)EncodingStandard(Version 3.2.1)[EB/OL].http://www.opengeospatial.org/standards/gml.2007.

[2]W3C.eXtensible Markup Language(XML)1.0(FourthEdition)[EB/OL].http://www.w3.org/TR/2006/REC-xml-20060816.2006.

[3]兰小机,张书亮,刘德儿等.GML空间数据库系统研究[J].测绘科学.2005.

[4]兰小机,闾国年,刘德儿.GML空间数据查询与索引机制研究[J].遥感学报.2006.

[5]兰小机,刘德儿,闾国年.GML空间数据索引机制研究[J].计算机工程.2007.

[6]兰小机,肖辉辉,段艳明,基于扩展NXD的GML空间数据库数据查询系统[J].大地测量与地球动力学.2008.

[7]陈建华,王华军,苗放,等.XML/GML非空间数据查询的结构连接算法[J].计算机工程.2010.

论地图制图数据库存储结构设计 篇5

1 数据库数据组织

本系统是基于Oracle数据库的地图制图系统, 数据库中存储以下三类数据:地理数据, 即国家基础地理信息数据, 它是制图数据源;制图数据, 是制图成果数据, 主要包括空间数据、制图图形数据、符号关联数据及注记数据几类;制图规则信息, 主要包括符号库、字体库、符号配置规则、字体配置规则等信息。制图数据是地理数据在制图规则信息的约束下得到的。

1.1 地理数据组织

在数据库中, 以图幅为单位, 图幅内按照要素类型和几何类型单一的原则分为若干个图层, 图层内部属性统一, 将其作为一个表存储。图层中包含空间数据和属性数据, 按照面向对象的思想, 以ID为惟一地物标识, 在一条记录中存储一个地物的属性数据和空间数据。

1.2 制图数据组织

经过一系列制图过程以后, 系统得到该图幅的制图数据, 它包含进行一定修改后的地理数据、符号图形数据、地物符号对照表、注记结果数据、整饰结果数据等。为了存取的快捷, 用一个表存储图幅内所有的符号图形, 表中以图层名为关键字, 将一个图层的符号图形用二进制方式作为一条记录存储, 存储顺序为其绘制顺序。

1.3 制图规则信息数据组织

符号库数据组织。符号分为点、线、面三种, 其中面符号层次稍高于点符号和线符号。点符号和线符号由点、线、面图元组成。由此, 设计八个表来存储一个符号库, 各个表中, 以符号代码或图元代码为内外部关键字进行关联, 其存储关联关系。符号配置规则用一个表进行存储, 表中字段名称分别为优先级值、符号代码和地物国标码。当对一个图层配置符号时, 首先将图层按国标码分为若干子图层, 再按优先级顺序从该表中选取含有该图层的国标码的所有记录, 从记录中获取符号代码, 依据符号代码再从符号库中获取符号参数, 按优先级从高到低依次对各类地物配置符号, 从而在符号化的同时解决了各类地物的绘制顺序问题。为了实现一些特殊的制图要求, 一个地物可对应多个符号。

字体数据组织。与符号数据类似, 字体数据分为字体参数库和字体配置规则。字体参数用一个表来存储, 表中包含代码、高度、宽度、名称、颜色和字型六个字段。同一类型的地物, 字体的大小随着该地物的等级而变化, 即一个字体约束于多个条件, 而且这些条件有时要从某个属性值的某一位或几位的值来确定。一般常用四个参数描述一个条件, 即属性名称、取值开始位、取值结束位和对应值, 每条字体规则最多设置五个条件。由此, 字体规则表中除存储字体代码、优先级、图层类型、使用条件个数外, 还需存储五个条件的具体描述信息。当为一个图层配置注记时, 从上表中选择所有与该图层类型一致的注记配置规则, 再将地物的属性与每条规则中定义的所有条件进行对比, 如果全部符合, 则为该地物的注记配置规则所对应的字体。

2 地理数据的存储结构设计

2.1 地理数据的内容

地理数据来源于对实地测绘数据的数字化跟踪结果, 它是按照比例尺和区域分幅存储, 在单一分幅中, 又按照地物类型和几何属性分层存储, 每一层中存储若干个地物对象的空间数据和属性数据。对同一比例尺而言, 全国地理数据的分层的形式是统一的, 现行全国1:25万基础地理信息数据的分层方法。地理数据依据要素类型和几何型的不同被划分为21个图层。在单一图层中, 地物的几何类型和包含的属性项相同。

2.2 数据的存储结构

针对上述的地理数据内容, 以及Oracle数据库的存储方式以及它所提供的Oracle Spatial空间插件对空间数据支持, 给出了如下的层次型面向对象的地理数据存结构。Oracle中, 一个数据库对象中包含若干个方案, 每个方案中有表集合、索引集合、视图集合、同义词集合序列集合、簇集合、类型集合等, 在本系统中, 主要用到表集合来存储地理数据, 表中又包含若干个记录。这样我们所用方案对应于图幅, 表对应于图层, 记录对应每个地物。

2.3 空间数据的存储形式

按照面向对a象的思想, 每条记录存储一个地物, 包括它的一般属性和空间属性, 即空间坐标。可以用两种方法, 存储空间数据:第一种方法是借助Oracle提供的支持空间数据类型的插件Oracle Spatial中的数据结构类型MDSYS·SDO_GEOMETRY, 其主要用于说明其中, 该空间对象的类型、记录图形的坐标系统、存储点对象坐标、变长数组。用这种方式存储空间数据的优点是结构性和对象性强, 同时可以利用Oracle Spatial提供的空间索引。缺点是存取速度慢, 因为访问它的所有内容需要解析多个数组, 而Oracle提供的访问数据库的接口对数组的解析需要花费很多的时间。第二种方法是利用Oracle提供的二进制的大对象类型BLOB, 它将地物的空间坐标数据和空间对象类型以及其他一些说明信息按系统设计者规定的规则顺序地存入一个类型为BLOB的字段中, 当要读取时, 再按规则取出即可, 这种方法的缺点恰恰是第一种方法的优点, 而其优点是读取速度极快, 这恰恰弥补了第一种方法的缺点。

3 地图数据存储结构设计

地图数据包括四个部分, 第一部分为地理数据, 第二部分地物与符号的对应信息, 第三部分为符号图形数据, 第四部分为注记数据。其中, 地理数据作为地图数据的基础被带进地图数据中, 它的存储方式与上面介绍的相同。

3.1 地物符号对应信息存储

某个图层被符号化时, 是分成了若干个子图层, 每个子图层再配上若干个符号完成的。所以地物与符号之间通过子图层来联系的, 因此为每个图层设计两个表, 假设图层名为Layer-Name, 则第一个表名为Layer Name_S, 该表记录该图层中的子图层信息, 第二个表名为Layer Name_SP, 记录地物与子图层的联系信息, 即哪个地物属于哪个子图层。第三个表名为Layer Name_D, 记录该图层中所用到的符号信息。

3.2 符号图形数据的存储

符号化的结果数据称为符号图形, 它是地理数据和符号结合的产物, 是该制图系统的图形基础, 它的存在能加快系统的绘图速度, 而且施加于其上的编辑操作能改变符号化后的图形细节, 达到一些特殊的制图效果。针对地图图形的特点, 将符号图形划分为种基本类型, 即圆、线和多边形。所有复杂的图形都可以分解为这三种图形。例如:用境界符号符号化线状地物以后, 得到一串圆和线顺序排列的符号图形序列, 用灯塔符号化点状地物后, 得到由六条线和一个多边形组成在一个图层中, 符号图形的坐标数据量非常大, 如果像存储绘制属性一样在表中每个单独存成一行, 那么当读取符号图形时, 系统与数据库的I/O交换量将十分巨大, 速度将十分缓慢。

3.3 地图注记数据存储

注记是对图形的文字标示, 按所标示的图形几何类型分为点状注记, 线状注记和面状注记。但无论是何种注记, 目的都是将文字字符串摆放在合适的位置, 结果无非是两种:一是字符串挨在一起, 此时, 字符串只有一个定位点, 即第一个字符的左上角, 二是字符串分隔开来, 此时, 字符串有N个定位点, 分别位于每个字符的左上角。所以, 注记分为两个层次, 一是注记整体, 表示对一个地物所标示文字的整体信息, 二是注记细胞, 对应注记整体中的有一个定位点定位的字符串对象。

摘要：详细介绍了基于Oracle数据库数据的组织, 并分析了各类数据在数据库中的存储结构, 特别介绍了Oracle中的大对象数据类型存储坐标数据的使用。

关键词：地图制图,数据组织,Oracle

参考文献

[1]李志涛.地图制图系统中组件技术的应用与实现[D].武汉:武汉大学, 2005.

[2]祝国瑞.地图学[M].武汉:武汉大学出版社, 2004.

基于关系数据库的地籍空间数据存储结构 篇6

随着社会主义市场经济体制不断完善, 公共财政体系逐步建立, 在对财政支出总量不作大调整的基础上, 适当调整财政支出结构, 做到区别对待, 对经济增长至关重要。比如, 对政府直接用于一般竞争性领域等“越位”的投入, 积极采取措施退出来、压下来;对属于公共财政范畴的, 涉及到财政“缺位或不到位”的, 如公共卫生、教育、科技等经济社会发展的薄弱环节, 逐步加大投入和支持的力度。因此, 有必要对财政支出结构的合理性进行研究。财政支出结构是否合理, 其目标函数是以经济增长为主的社会发展。

一、理论模型与变量说明

(一) 基本模型的构建

为分析改革开放以来湖南省经济增长与财政支出结构的关系, 本文采用的方法是阿绍尔 (Aschauer, 1988) 的方法, 公共投资进入生产函数。假设生产函数是柯布—道格拉斯形式:

其中, Y代表总产出, A代表随时间变化的技术水平, N代表劳动投入量, K代表物质资本存量, G代表公共投资支出, α、β、γ分别代表劳动投入、物质资本存量和公共投资支出的产出弹性。

若要分析财政支出结构与经济增长的关系, 只需函数转变为:

由于数据及模型设立方面的问题, 本文只将财政支出分为三个部分。对上式两边取对数, 则有如下回归方程:

(二) 变量及样本数据的说明

1. 产出。

我们采用1978—2006年的湖南省GDP数据作为产出数据, 按照1978年的不变价格进行计算, 以居民消费价格指数进行消胀, 剔除价格因素, 代表实际产量。后面的变量一律按此方式剔除价格因素。

2. 资本投入。

由于我国不存在真实资本存量的总量和结构数据, 因此本文采用资本形成总额 (等于固定资产+存货) 作为资本投入的表示。时间跨度同样为1978-2006年。

3. 劳动投入。

构造劳动投入数据面临如下问题:劳动投入应该按照投入的劳动时间计算, 但是我国目前没有关于劳动时间的完整统计, 只有劳动力、全社会就业人数等按照人数计算的数据。对此, 本文的处理方法是通过投入生产的劳动力人数来衡量劳动投入量, 用从业人数代表。这样, 即可得到1978—1998年湖南省的劳动投入数据。

4. 财政支出。

由于数据可得性与统计口径的问题, 本文将财政支出分为三部分:基本建设支出 (G1) 、科教文卫事业费 (G2) 和财政其余部分支出 (G3) 。基本建设支出是财政支出的一大主要部分, 主要包括基础设施建设等。科教文卫支出在财政支出总额中也占据较大份额, 特别是教育支出, 以此指标作为政府支出公共服务部分的代表。财政其余部分支出则主要包括国防支出、农业支出, 价格补贴、行政管理费, 城市维护费等等。以上数据均可在《湖南统计年鉴》中查得。

二、财政支出结构与经济增长关系的实证检验

(一) 平稳性检验

在具体应用时间数据进行回归分析时, 为防止伪回归现象的出现, 我们首先必须对被检验分析序列进行平稳性检验, 即是否具有单位根 (unite root) 。本文采用增长迪基—富勒 (Augm e nte d Dick—Fulle r, ADF) 的方法进行检验。其主要思想是一个不平稳随机序列{Xt}, 如果经过n次差分之后变为平稳序列, 则称序列有n阶单整性, 并记为I (n) , 把平稳序列记为I (0) , 其具体方法是对进行估计, 其滞后阶数的选择原则是保证回归式的残差εt符合白噪声 (White noise) 。从检验结果得知, 这些变量都是一阶单整的, 而其差分是平稳的, 说明它们之间存在协整的可能性, 即这些变量之间可能存在长期均衡关系。

(二) 协整检验

协整 (Cointegration) 分析是指如果两个或两个以上的变量的时间序列是非平稳的, 但它们的某种线性组合却表现出平稳性, 则这些变之间可能存在长期的稳定的关系, 即协整关系。关于协整检验的方法有多种技术模型, 主要有恩格尔格兰杰两步法、Johansen极大似然估计法或JJ法等, 本文由于是多变量模型, 所以应采用Johansen极大似然估计法对变量进行协整检。检验结果如下:

由检验结果可知, 6个变量在5%水平上至少存在四个协整方程, 说明这些变量虽然是非平稳变量, 但它们却保持着共同的趋势, 存在协整关系。

(三) 协整回归分析

利用eivews做logGDP对其余变量的回归, 结果如下:

由上述回归结果可得出模型如下:

可以看出方程回归系数的t检验和方程整体显著性的F检验均通过, R2也高达0.9944, 拟合度很高。

方程残差序列自相关检验:由上知DW值为1.704274, 查得在方程自变量个数为5, 样本数为29的DW的下限dL为1.050, 上限dU为1.841, 所以本模型的DW值处于两者之间, 无法判断。为此, 我们进行残差相关图的检验, 结果显示不存在自相关。此外, 经检验前10阶的LM统计量均小于临界值, 所以可以确定残差不存在自相关问题。

异方差检验:我们进行异方差的怀特检验如下图所示:

得出相伴概率为0.3357大于显著性水平的0.05, 可断定没有异方差的影响。

综上得知此模型的整体拟合效果很好。

(四) 因果检验

协整检验告诉我们变量之间存在长期均衡关系, 但是否构成因果关系, 还需要进一步检验。在此, 我们进行G、G1、G2、G3与GDP之间的Granger因果检验。G为财政支出总额。根据协整关系检验结果, 由于各变量均为I (1) 过程并具有协整关系, 故可对其进行Granger因果关系检验。检验结果表明GDP不是财政支出总额的原假设, 拒绝它的概率为0.266, 表明GDP不是财政支出总额的概率较大, 不能拒绝原假设。第二个检验的相伴概率为0.10753, 在5%的显著性水平上, 仍然不能拒绝原假设。所以, GDP和财政支出总额之间没有因果联系。

用同样的分析可得出, GDP总额是财政基本建设支出的原因, 基本建设支出不是GDP的原因。GDP不是科教文卫事业费支出的原因, 但科教文卫事业费支出是GDP的原因, 对GDP增长有实质影响。GDP和其余财政支出部分无因果联系。

三、小结

(一) 财政基本建设支出、科教文卫事业费支出、其余财政

支出部分、资本、劳动力与经济增长之间存在长期均衡关系, 即协整关系。

(二) 财政投资 (基本建设支出) 与经济增长正相关, 但弹性较低

说明目前政府投资基础设施项目部分依然对经济增长有效用, 湖南省的政府投资部分任有一定的空间, 但弹性很小, 基建支出每增加1%, GDP只增加0.17%, 表明政府投资的挤出效应有可能较大。科教文卫事业费支出与经济增长有长期的正向联系, 且弹性比基本建设支出大。表明科教对经济增长的促进作用较大, 政府应该加强在这方面的投入。其余财政支出部分与经济增长负相关。表明国防支出、农业支出, 价格补贴、行政管理费, 城市维护费等综合来讲对经济增长无帮助, 但这些对国家的稳定起到了重要作用, 必不可少。

(三) 因果检验的实证结果表明, GDP总额的增长能够促进

财政基本经济建设支出的增加, 所以政府投资的增加很大程度上依赖于整个宏观经济状况的好坏

基于关系数据库的地籍空间数据存储结构 篇7

一、海量结构化大数据存储检索系统的工作原理

大数据的处理对数据的加载效率、存储效率和检索效率提出了更高的要求,因此为了满足大数据的需求,需要利用多机协同机进行分布式存储,进而提高系统随数据的处理效率。对于海量结构化大数据存储检索系统而言,其中包括加载机集群、查询机集群、元数据节点集群以及存储点的集群。

二、海量结构化大数据存储检索系统的数据模型和存储结构

(一)MDSS中的数据模型

MDSS作为一种新型的数据管理模型,为用户提供的是二维表空间,一行就是一条包含多个字段或者是属性的记录,在表结构的支持下,表空间对字段的类型进行正确的描述。一般应用于表结构的数据类型有以下几种:属于整数类型并进行数学比较运算的NTEGER(或INT),存储IP类型字段并对子网和区间进行查询的IPFIELD,利用两种数据格式对IPV4和IPV6地址进行保存的INDEX,存储模糊类型数据并支持精确匹配和模糊匹配的TIMESTAMP和直接对数据存储但不对内容查询的STORE。

(二)数据存储组织结构

对于数据的存储,主要有:STORE类型和字符类型两种,前者是对文件信息进行直接的存储,用户对数据的内容进行相应的解析,或者是将数据源根据字符的方式进行分块存储,因此可以在存储的过程中实现迁移,提高了存储的灵活性,同时在对数据进行存储时根据特定的需要对数据进行相应的转换,这项转换工作需奥借助加载机来实现。

三、海量结构化大数据存储检索系统的数据检索方法

MDSS对复杂任务的查询主要是通过将复杂的任务进行细分,即以查询的条件为依据将查询任务分为几个查询的子任务,进而每个子任务在不同环境和不同层次下同时实现,这样就大大的提高了查询的效率,一方面通过对查询条件的分解和对查询任务的设置,可以很大程度的提高查询的正确性,另一方面最大限度的考虑到影响数据检索的多种因素,使系统的计算能力得到了充分的发挥。

(一)查询条件的分解

为了对二维表空间的操作起到积极的促进作用,推进结构化数据的统计与检索,需要设计新的分析语言,既要符合一般的语法规则和标准,同时还要取消关联查询、嵌套查询和视图等一些复杂的检索功能。

多个查询的语句共同构成了一个查询任务,因此为了提高查询工作的效率和准确性,需要将查询条件进行分解,在MDSS的作用下,查询条件一般分为三个基本的类型,并且每一个基本条件都等同于一项查询子任务。

分区查询条件属于目标索引文件,这样一查询目标为指导,可以大大的缩小海量数据的查询范围,降低了查询的难度,因此在系统的应用中,需要先执行分区查询条件,对每一个表空间设置一个分区查询条件,实现对数据库的有效索引;过滤查询条件是在逻辑运算符号的衔接下,形成多个逻辑组合并进行查询,因为多个字段共同构成了结构化数据的记录,并且其属性支持模糊查询,利用过滤查询条件机械能比较查询等模糊查询,提高了查询的针对性;统计分析查询条件是指对经过前两个环节的查询后,对返回的结果集的查询,是对全集数据集的统计和分析,一般来说,统计分析查询主要包括数据分组操作、排序操作和统计函数。使用统计分析查询条件时,要将全部符合条件的数据进行统计,然后再对其进行分析,进而得出正确的结论,同时具体的查询任务要按照下图的流程进行:

(二)查询子任务的执行

在对海量化大数据进行查询时,为了简化查询的工作,需要把一个复杂的查询任务进行细化,分为几个查询子任务,对于查询子任务的分解,可以根据上述的分类进行查询。在分布式环境下,不同的层次会执行不同的子任务,分区类查询条件结合元数据信息在具体的存储节点上进行索引文件级别的查询;过滤类查询条件针对目标索引文件内的具体记录进行过滤,这两类条件在多数据存储节点中并发执行。统计分析类查询条件在查询机上,针对过滤类查询条件返回的结果集进行汇总后再进行统一计算处理,保证查询语义的正确性。

在MDSS中,一般是将时间属性作为分区类检索的条件,在检索条件的时间属性导致支持下,可以快速地检索到符合要求的目标索引分片,进而提高检索的速度,这样就大大的简化了数据的管理策略,同时能够应用于各个具体的工作环境,并且起到了积极的促进作用。统计分析类查询是对有具体分组和排序的数值分析,是建立在对全部的结果集进行统计的基础之上的,只有对全部的数据集进行统计和分析,才能够得出正确的查询结果。一般而言,对分组和排序的操作主要是在查询机上进行,在此环节中,Bloom Filter算法起到了加速分组的操作,并且消除了重复的计算过程,这样就极大的提高了数据查询的效果。此外,MDSS还能对部分的查询进行特殊的处理,并查询的结果进行优化,在保护查询结果准确性的基础上,MDSS会同过滤类查询条件一起执行,此时返回的子查询结果集是已经分好组、排好序或去重后的结果集,最后的数据汇总阶段只做一次对应的统计操作,会大大提高数据汇总阶段的执行效率。MDSS对查询条件的分层如下图所示:

不同的查询条件要对应相应的查询机和合适的查询时间,MDSS中的查询机制主要有两种,即在线查询和离线查询,前者的数据查询时间响应的要求很高,在几秒内便反应出查询的结果,用户可以花费较短的时间得到查询的结果,后者的数据查询模式比较复杂,主要是对数据的挖掘和分析,甚至有时候需要对全部的数据进行统计和分析,只有经过这些必要的程序才能够获得查询的结果,这就需要较长的数据查询响应时间。上述的两种查询机制在MDSS中得到了广泛的应用,为了充分发挥两者的优势,需要引入分批返回机制,即在执行子查询中,设置子查询检索结果集的阈值,如果检索到结果集超过阈值,返回当前的检索结果,同时存储节点保存当前的检索状态、缓存剩余的结果集。

结束语:

在传统的数据库设计思想的指导下,探讨了数据管理方式,建立了建立面向结构化数据的海量数据存储检索系统,该系统具有明显的优势,不仅提高了数据存储的效率,还具备较多的功能,例如高效加载功能、分布存储功能以及复杂条件的查询功能。但在该系统的具体开发和应用中,还要注意以下几个方面的问题:(1)结合具体的应用,综合利用分区索引条件、列存储结构等技术,会显著提高海量结构化数据的查询效率;(2)充分利用、挖掘分布式环境下的并发、并行计算能力,是提高面向大数据集、复杂查询条件查询效率的主要途径。

MDSS系统在查询效率方面虽然取得了一定的成效,对数据存储发挥了重要的作用,但是还存在一些限制,需要进一步改进。主要的改进方向包括,如何提高元数据的管理、访问效率;如何建立分布式环境下面向复杂条件的高效查询规划,减少中间结果集的传递、结果集汇总等时间消耗,都是进一步提高系统查询效率的主要方面。

参考文献

[1]吴广军.海量结构化数据存储检索系统[J].中国科学院计算机研究,2010(09