非结构化数据存储(共9篇)
非结构化数据存储 篇1
企业应用系统中存在大量的非结构化数据, 通常企业机构使用基于网络的分布式文件服务器维护非结构化数据, 并在企业应用系统中授权访问。
文件服务可以作为多种企业应用系统的基础服务。一方面, 我们需要基于网络的分布式文件服务实现大量数据的存储。另一方面, 集中的管理、监控和使用文件服务, 将在降低企业应用系统开发的难度和工作量的同时, 简化企业应用系统的部署、管理和维护工作。
上述结构在保证了文件服务器安全性的同时, 存在下列不足: (1) 文件传输的处理将极大的占用应用服务器的处理能力及网络带宽, 应用服务器很可能因此成为企业应用的瓶颈。 (2) 按照用户界面中是否执行文件传输操作, 最终用户预期的界面平均响应时间也不同, 通常用户更难忍受非文件传输时的界面延迟。因此上述结构可能导致的文件传输挤占其他业务的处理能力的情况, 将对企业应用系统的用户体验带来较大的影响。
参考互联网应用的文件处理机制, 本文提出对分布式文件服务器结构的改进, 主要包括: (1) 将文件流数据传输的负载从应用服务器分散到多个文件服务器; (2) 由于在基于B/S架构企业应用系统中, 企业应用系统的客户端浏览器只能基于http (s) 与服务器通信, 因此要求文件服务器实现基于http (s) 的访问接口, 以标准的方式完成与客户端浏览器的通信; (3) 为适应企业应用系统中频繁的数据变更和细粒度访问控制需求, 确保直接面向最终用户的文件服务器的安全性; (4) 通过分布式文件服务器中逻辑存储单元的定义, 以及存储单元与物理存储位置的映射管理, 实现不同企业应用系统间的隔离, 进而支持建立企业级文件服务, 降低企业应用系统开发难度和工作量, 简化企业管理和维护文件的工作。
1 基本概念
1.1 分布式文件系统
分布式文件系统是指文件系统时间共享模式的分布式实, 通过一个公共文件系统为地理上分布的计算机用户提供数据和存储资源的共享。分布式文件系统的主要特征为网络透明性、位置透明性、可扩展性以及容错。
1.2 电子仓库
电子仓库DV (data vault) 是指在PDM系统中实现产品数据存储与管理的元数据库及其管理系统, 它是连接数据库和数据使用界面的一个逻辑单元, 它保存所有与产品相关的物理数据和文件的元数据, 以及指向物理数据和文件的指针。通过建立在数据库之上的关联指针, 建立不同类型的或异构的产品数据之间的联系, 实现文档的层次与联系控制。
1.3 HDFS
Hadoop分布式文件系统 (Hadoop Distributed File System, HDFS) 是一个运行在普通的硬件之上的分布式文件系统。HDFS具有高容错性, 可以部署在低成本的硬件之上, 同时HDFS放松了对POSIX的需求, 使其可以以流的形式访问文件数据, 从而提供高吞吐量地对应用程序的数据进行访问, 适合大数据集的应用程序。
2 分布式文件服务器设计
2.1 架构设计
当文件服务完全通过应用服务器实现时, 所有文件流都经过应用服务器中转提供给最终用户。文件传输具有占用带宽大, 占用服务器连接时间长特点, 属于长交互过程。企业应用系统中频繁进行文件操作会给应用服务器带来较大的网络压力, 同时大量的长交互过程将大量占用应用服务器的服务线程, 从而降低了服务质量。由此提出以下部署方式, 图1是分布式文件服务器的结构模型:
如图1, 文件服务器与应用服务器同时对用户提供服务。应用服务器与文件服务器之间存在操作指令交互, 客户端存取文件的时候由文件服务器直接对用户提供文件服务, 文件流不再经过应用服务器, 文件传输压力完全由多个文件服务器承担, 并不对应用服务器产生影响。应用服务器只需要满足大量并发的短交互过程, 以及实现与文件服务器间的操作指令交互, 可以大大提高无文件交互时的服务质量, 或者支持更多的并发用户。而文件服务器功能比较单一, 可以简单的扩展文件服务器数量以增加文件吞吐能力以及文件存储的能力。下文将分别讨论文件服务器安全性方面的设计。
2.2 应用服务器与文件服务器相互认证
为保证文件服务器的安全性, 即文件服务器只与配置指定的应用服务器交互操作指令, 增加了文件服务器与应用服务器的认证机制。
文件服务器只认证应用服务器, 首先应用服务器会安装一个由文件服务器提供的插件, 实际上认证过程发生在插件与文件服务器之间。而文件服务器对应用服务器的认证基于配置指定和证书, 即文件服务器可以持有指定应用服务器的证书, 确保发放的ticket只有指定的应用服务器可以使用, 从而杜绝冒充应用服务器申请ticket的可能。
对于没有ticket的访问, 文件服务器拒绝提供文件服务。
这样认证机制保证了对于文件服务的的访问者都是来自经过认证的应用服务器的用户, 从而保证了文件服务器的安全性。
2.3 存储单元及映射管理
企业机构可以在网络上部署一套分布式文件服务器系统提供企业范围的文件服务, 其他企业应用系统共用此文件服务, 从而实现集中的管理和维护文件数据。
分布式文件服务器系统中包含多个实现文件存取的文件服务器, 同时每个文件服务器内部可以划分为多个逻辑存储单元, 每个企业应用系统可以使用多个文件服务器中的部分存储单元, 从而在逻辑存储单元级别实现了企业应用系统间的隔离。
每个存储单元均可以对应一个或者多个文件系统中的路径, 不同存储单元对应的文件系统路径均不同, 从而实现了不同企业应用系统间文件物理存储位置层面的隔离。
三元组 (File Server IP, File Server Port, Cell ID) 唯一定位了分布式文件服务器系统中的某个逻辑存储单元。与此相应, 四元组 (File Server IP, File Server Port, Cell ID, File ID) 唯一确定了分布式文件系统中某个文件。在存储单元范围内, File ID唯一确定了一个文件。由于企业应用中不同的文件可能是重名的, 因此不能使用原始的文件名作为File ID。每个文件服务器均负责生成UUID作为本服务器范围内的File ID, 进而此File ID将用作对应文件系统中的文件名, 从而确保File ID可以在某个文件服务器范围内唯一标识一个文件。
文件服务器中File ID Mapper组件完成File ID与文件系统中存储路径的映射运算, 基于映射运算的文件定位方式具有如下优点: (1) 无需存储File ID与文件系统存储位置对应关系, 降低实现复杂度的同时提高了并发性; (2) 映射算法简单; (3) 可以在映射算法实现过程中添加简单的逻辑控制每个子路径下存储文件的数量。
3 实现
3.1 认证过程
认证过程发生在应用服务器与文件服务器之间, 首先认为应用服务器与文件服务器之间的通讯是安全可靠的, (可以采用https协议确保安全性) 。其次只有合法的应用服务器才拥有文件服务器插件。
认证中采用公钥私钥认证, 在应用服务中的文件服务器插件中存贮着公钥, 在文件服务器上存储着对应的私钥。认证过程, 应用服务器请求认证, 文件服务器接到请求后生成一个随机数并通过自己的私钥加密, 将加密过的随机数传给应用服务器, 应用服务器通过公钥将加密串解密, 并将解密结果返回给文件服务器进行认证, 通过这种认证方式认证应用服务器。详细认证过程如图2。
3.2 存储映射
文件服务器的File ID基于随机的UUID, File ID本身不含有任何有意义的信息, 不可能根据File ID推断其存储位置、类型、大小等文件信息。其核心思想是:将File ID分割为{n/3}组, 在存储路径中递归创建子路径, 每级子路径对应其中一组, 最低一级子路径即是文件最终的存储路径。算法对应的伪码如下:
仔细分析上述实现后发现File ID的随机性将导致在文件系统中大量创建子路径, 但每个子路径中存储的文件数量非常有限, 因而将给文件系统造成较大压力, 同时降低了文件定位的效率。File ID Mapper组件通过在UUID的基础上附加序列数, 支持在每个UUID生成的子路径中存放序列数允许个数的文件。如基于10进制的两位序列数将允许存放 (00~99) 范围的共100个文件, 而基于16进制的两位序列数将允许存放 (00~FF) 范围的共256个文件。File ID Mapper组件最终使用16进制序列数的生成UUID算法对应的伪码如下:
上述算法保证文件系统中某个子路径下将至多存储256个文件, 在保证不会产生过多的子路径的同时, 也避免任何路径中保存过多的文件。
3.3 文件服务器客户端组件
文件服务器客户端是文件服务器对外提供操作文件服务的接口, 即所有对文件服务器的操作都可以通过文件服务器客户端组件完成。标准文件服务器客户端组件采用flash技术和javascript技术编写, 提供基于两种技术的客户端组件, 使用者可以根据情况选择使用。
下面介绍客户端的具体功能, 向应用服务器申请ticket, 申请到ticket后定向到指定文件服务器, 带上ticket申请文件服务。由于客户端组件都是放在浏览器中执行的, 所以在与服务器数据交互过程中采用Ajax技术提高用户体验。下面以用户上传为例, 通过伪代码介绍客户端组件的实现过程。
客户端组件的其他操作的流程基本相同, 都需要先上应用服务器申请ticket, 如果没有申请成功则终止下一步操作。
4 测试
测试多用户文件上传对服务器性能的影响, 通过多用户同时上传文件测试文件上传对服务器性能的影响。
4.1 测试环境
文件服务器配置
内存:4G
网卡:千兆网卡
操作系统:window server 2003
客户端配置
内存:4G
网卡:百兆网卡
操作系统:window server 2003
4.2 测试方法
首先采用一台测试机进行上传一个一千兆的文件测试, 记录文件服务器带宽使用率。然后采用两台测试机同时上传一个一千兆文件, 记录文件服务器带宽使用率。
4.3 测试结果
如图3, 记录了文件服务器网络带宽使用率
图中1区域表示单独一台测试机上传文件, 图中区域2表示两台测试机同时上传。
4.4 测试结论
由图3可以看出当一台测试机上传文件的时候占用服务器带宽与两台测试机同时上传占用的带宽是成线性增长的。所以将文件传输部分单独由文件服务器提供, 能够有效分担应用服务器的压力。
5 结论与展望
分布式文件服务器系统是企业应用系统的基础组成部分, 本文提出的改进方案在保证安全性的基础上, 支持在企业中分布式部署文件服务器群供其他企业应用系统共用, 为企业中非结构化数据的管理和维护提供了完整的解决方案, 可以有效的降低企业应用系统的研发、部署和维护成本, 并提高企业应用系统服务质量。在作为企业中统一管控的文件服务器群应用时, 目前的方案还存在不足, 解决下面列举的问题将是后续的研究重点。
对于某个逻辑存储单元, 其存储安全性有待继续加强, 主要包括: (1) 文件服务器加解密算法可替换, 每个企业应用系统均可能使用特定的加解密算法满足不同的安全需求, 目前统一的DES算法无疑难以满足, 因此文件服务器需要实现基于存储单元的加解密算法配置, 并且算法的关键参数 (如密钥) 应该由企业应用系统自行管理; (2) 基于企业应系统的存储单元激活机制, 在没有企业应用系统认证时, 文件服务器自身也不能访问加密存储单元中的文件内容, 而对于未加密存储单元, 非激活状态下文件服务器将拒绝提供文件访问服务。
参考文献
[1]李武.面向现代服务业的大规模分布式文件存储系统设计和实现: (硕士学位论文) .杭州:浙江大学, 2008.Sanjay Ghemawat, Howard Gobioff, Shun—Taka Leung.The Googlefile system.
[2]Proceedings of the Fifth NASA Goddard Space Flight CenterConference on Mass, Storage Systems and Techn0109i es, 1996.
[3]http://hadoop.apache.org/common/docs/current/hdfs_design.html.
[4]http://code.taobao.org/p/tfs/wiki/intro/.
[5]周志华, 何萍, 尹建伟.基于Web的海量存储柔性分布式文件服务器设计[期刊论文].计算机应用研究, 2002 (11) .
[6]任蜀焱, 何玉林, 曾慧娥.基于Web的PDMS电子仓库关键技术研究[期刊论文].机械与电子.2006. (4) .61-62.
[7]Pro Hadoop.Jason Venner.Heidelberg:Springer.2009.
非结构化数据存储 篇2
班级: 2010XXX 姓名: HoogLe 学号: 2010XXXX 专业: XXXX
2858505197@qq.com
一、实验目的:
(1)掌握单链表的基本操作的实现方法。(2)掌握循环单链表的基本操作实现。(3)掌握两有序链表的归并操作算法。
二、实验内容:(请采用模板类及模板函数实现)
1、线性表链式存储结构及基本操作算法实现
[实现提示](同时可参见教材p64-p73页的ADT描述及算法实现及ppt)函数、类名称等可自定义,部分变量请加上学号后3位。也可自行对类中所定义的操作进行扩展。所加载的库函数或常量定义: #include
LinkList(T a[],int n);//利用数组初始化带头结点的单链表构造函数实现
~LinkList();int length();//求单链表表长算法
T get(int i);//获得单链表中第i个结点的值算法
int locate(T temp);void insert(int i,T temp);//在带头结点单链表的第i个位置前插入元素e算法
T Delete(int i);//在带头结点单链表中删除第i个元素算法
void print();//遍历单链表元素算法
bool isEmpty();//判单链表表空算法
void deleleAll();//删除链表中所有结点算法(这里不是析构函数,但功能相同)private: Node
前置条件:无
动作:初始化一个带头结点的空链表 输出:无
后置条件:头指针指向头结点。
//初始化带头结点空单链表构造函数实现 template
(3)利用数组初始化带头结点的单链表构造函数实现 输入:已存储数据的数组及数组中元素的个数 前置条件:无
动作:利用头插或尾插法创建带头结点的单链表 输出:无
后置条件:头指针指向头结点,且数组中的元素为链表中各结点的数据成员。//利用数组初始化带头结点的单链表构造函数实现 template
动作:在带头结点的单链表中第i个位置之前插入元素e 输出:无
后置条件:单链表中增加了一个结点
//在带头结点单链表的第i个位置前插入元素e算法 template p=p->next; count++;} if(p==NULL)cout<<“i不合法,越界!”;else{ Node s->data = temp; s->next = p->next; p->next = s;} }(5)在带头结点单链表中删除第i个元素算法 输入:删除第i个结点,待存放删除结点值变量e 前置条件:单链表不空,i的值要合法 动作:在带头结点的单链表中删除第i个结点,并返回该结点的值(由e传出)。输出:无 后置条件:单链表中减少了一个结点 //在带头结点单链表中删除第i个元素算法 template p=p->next; count++;} if(p==NULL)cout<<“i不合法,越界!”;else{ Node T x= s->data; p->next = s->next; return x;} }(6)遍历单链表元素算法 输入:无 前置条件:单链表不空 动作:遍历输出单链表中的各元素。输出:无 后置条件:无 //遍历单链表元素算法 template cout< data<<“ ”; p=p->next;} cout< (7)求单链表表长算法。输入:无 前置条件:无 动作:求单链表中元素个数。输出:返回元素个数 后置条件:无 //求单链表表长算法 template p=p->next; count++;} return--count;} (8)判单链表表空算法 输入:无 前置条件:无 动作:判表是否为空。 输出:为空时返回1,不为空时返回0 后置条件:无 //判断非空 template (9)获得单链表中第i个结点的值算法 输入:无 前置条件:i不空,i合法 动作:找到第i个结点。 输出:返回第i个结点的元素值。后置条件:无 //获得单链表中第i个结点的值算法 template p=p->next; count++;} if(p==NULL)cout<<“i不合法,越界!”;else{ return p->data;} } (10)删除链表中所有结点算法(这里不是析构函数,但功能相同)输入:无 前置条件:单链表存在 动作:清除单链表中所有的结点。输出:无 后置条件:头指针指向空 //删除所有元素 template Node p=p->next; t->next=NULL;} } (11)上机实现以上基本操作,写出main()程序: 参考p72 void main(){ int a[10]={1,2,3,4,5,6,7,8,9,0};//测试带参数的构造函数(前端插入!) LinkList if(list1.isEmpty()){ cout<<“链表不为空!”< cout<<“链表为空!”< 2、参考单链表操作定义与实现,自行完成单循环链表的类的定义与相操作操作算法。template void insert(int i,T temp);//在带头结点单循环链表的第i个位置前插入元素e算法 T Delete(int i);//在带头结点单循环链表中删除第i个元素算法 void print();//遍历单循环链表元素算法 private: Node 动作:利用头插或尾插法创建带头结点的单循环链表 输出:无 后置条件:头指针指向头结点,且数组中的元素为链表中各结点的数据成员,尾指针指向头结点。 //利用数组初始化带头结点的单循环链表构造函数实现 template s->next = head->next;head->next=s; length++;} } (2)在带头结点单循环链表的第i个位置前插入元素e算法 输入:插入位置i,待插入元素e 前置条件:i的值要合法 动作:在带头结点的单循环链表中第i个位置之前插入元素e 输出:无 后置条件:单循环链表中增加了一个结点 //在带头结点单循环链表的第i个位置前插入元素e算法 template while(count p=p->next; count++; } Node s->data = temp; s->next = p->next; p->next = s;} }(3)在带头结点单循环链表中删除第i个元素算法 输入:删除第i个结点,待存放删除结点值变量e 前置条件:单循环链表不空,i的值要合法 动作:在带头结点的单循环链表中删除第i个结点,并返回该结点的值(由e传出)。输出:无 后置条件:单循环链表中减少了一个结点 //在带头结点单循环链表中删除第i个元素算法 template if(i>length)cout<<“i不合法,越界!”< while(count p=p->next; count++; } Node T x= s->data; p->next = s->next; return x;} } (4)遍历单循环链表元素算法 输入:无 前置条件:单循环链表不空 动作:遍历输出单循环链表中的各元素。输出:无 后置条件:无 //遍历单循环链表元素算法 template cout< data<<“ ”; p=p->next;} cout< (5)上机实现以上基本操作,写出main()程序: void main(){ int a[10]={1,2,3,4,5,6,7,8,9,0};//测试带参数的构造函数(前端插入!) LinkList 3、采用链式存储方式,并利用单链表类及类中所定义的算法加以实现线性表La,Lb为非递减的有序线性表,将其归并为新线性表Lc,该线性表仍有序(未考虑相同时删除一重复值)的算法。模板函数: template if(p1->data>p2->data) { this->insert(++num,p1->data); p1=p1->next; } else{ this->insert(++num,p2->data); p2=p2->next; } } if(!p1){ p1=p2;} while(p1){ this->insert(++num,p1->data); p1=p1->next;} } void main(){ int a[5]={1,2,5,6,9};int b[5]={0,3,4,7,8};LinkList 选做题: 1、按一元多项式ADT的定义,实现相关操作算法: ADT PNode is Data 系数(coef)指数(exp)指针域(next):指向下一个结点 Operation 暂无 end ADT PNode ADT Polynomial is Data PNode类型的头指针。Operation Polynomail 初始化值:无 动作:申请头结点,由头指针指向该头结点,并输入m项的系数和指数,建立一元多项式。 DestroyPolyn 输入:无 前置条件: 多项式已存在 动作:消毁多项式。输出:无 后置条件:头指针指向空 PolyDisplay 输入:无 前置条件: 多项式已存在,不为空 动作:输出多项式各项系数与指数 输出:无 后置条件:无 AddPoly 输入:另一个待加的多项式 前置条件:一元多项式pa和pb已存在。动作及后置条件:完成多项式相加运算,(采用pa=pa+pb形式,并销毁一元多项式pb)输出:无 end ADT Polynomial 2、实现一元多项式的减法,操作描述如下: SubPoly 输入:待减的多项式pb 前置条件:一元多项式pa和pb已存在。 动作及后置条件:完成多项式减法运算,即:pa=pa-pb,并销毁一元多项式pb。输出:无 3、参考P74-P79页双向链表的存储结构定义及算法,编程实现双向链表的插入算法和删除算法。 [关键词]多线程;处理器;计算机技术;访存款带 [中图分类号]F224.39 [文献标识码]A [文章编号]1672-5158(2013)06-0053-01 多线程和向量技术是当前计算机技术发展的一个重要的趋势,也是现代化社会发展中研究最多的处理器设计要点。这种设计工作中,是通过提出一个多现场向量处理其设计要点为基础,利用多线程切换数据的方式来隐藏访存延迟现象的出现,并使得向量数据在运行中能够直接访问到二级cache从而提高宽带运行效率的一种结构。基于这些优势,因此在目前的向量处理器工作中,这些技术的应用较为常见,也是实现现代化计算机技术发展的核心内容。 一、向量处理器与多线程技术分析 在目前的社会发展中,多线程技术和向量技术一直深受着业内人士的关注,是处理器结构体系中结构和编程模式的技术要点,其在整个处理器发展中扮演着重要的角色。 1、向量处理器分析 向量处理器也被人们广泛的称之为阵列式处理器,是在工作中能够同步进行多种数据综合处理和运算操作的一种复杂的计算机结构。然而截至目前的社会发展中,多数计算机组装中都仍然是采用纯良处理器为主,这种处理器在应用中只能够一次处理一个要素,而无法对多套数据进行处理和归纳。向量处理器的出现使得计算机领域发生了翻天覆地的变化,它的出现使得整个计算机结构、构成和功能发生了重大变化,尤其是在上个世纪八十年代至九十年代着一段时期内,其更是成为各种超级计算机运行和主要基础。当今社会中,大多数的商业处理器仍然是以向量处理器为主的,已成为整个社会领域中最为常见的一项。 2、多线程技术分析 所谓的多线程技术主要指的是多个线程能够同时、并发运行的一项综合性技术体系,具有多线程能力的计算机因为有重组的硬件和软件系统的支撑能够在同一时间运行多个不同的软件和线程,进而提高了计算机的处理效率和处理质量,同时从整体上提升了计算机技术的应用优势。截至目前,我们在工作中可以将多线程技术分为以下三个方面:主要指的是细粒度多线程体系结构、粗粒度多线程体系结构和同时多线程体系结构。这三种结构体系的相互促进、相互协调运行使得整个计算机体系呈现出巨大的发展态势,也为计算机技术的全面、综合、统一迈进提供了扎实的基础平台。 3、向量技术 向量技术从诞生以来一直应用在高性能计算机当中,是计算机技术发展的指导依据和基础平台。随着科学技术的发展和计算机技术的进步,向量技术也得到了极大的迈进,其已经广泛的应用在各类处理器结构当中,成为处理工作中的指导依据和应用基础。经过多年的实践证明,向量技术的能够更好的适应计算机技术、处理技术和自动化技术的发展要求,从阿尔达到更高的实际应用性能的优势。 二、多线程向量存储结构设计 1、多线程向量体系结构 多线程处理器中设计有多套独立的线场,包括PC、通用寄存器、浮点寄存器、向量寄存器、状态寄存器等。每个线程从软件的角度看都是一个独立的处理器,线程的数量可以很多。多线程处理器设计有专门的向量部件,执行扩展的宽向量指令。多线程向量处理器通过将来自多个线程的指令交叉执行来隐藏长延迟操作带来的流水线阻塞,当来自某个线程的指令由长延迟操作而阻塞的时候,其他线程的指令仍可以继续执行,从而保持流水线的满负荷工作。 2、多线程向量存储结构 将多线程与向量技术结合,可以隐藏向量数据访问的存储器延迟,但需要处理好向量数据与标量数据的存储结构和数据相关性。我们设计了一种向量与标量混合访问的存储层次,一级数据缓存只缓存标量数据,不缓存向量数据。向量访存操作将不进入一级数据缓存,直接通过二级缓存访问。这样做是基于两点考虑:首先,L1D容量小而向量数据规模大,这样避免了向量数据与标量数据争夺有限的LID资源,避免LID的数据抖动,利于充分发挥标量处理部件的计算性能;其次,由于有多线程的延迟隐藏机制,二级缓存高速缓存的访问延迟可以得到很好的隐藏,不会对向量处理部件的性能造成过大的影响。高速缓存数据块的大小与向量寄存器的位数一致。这样,每个向量访存操作都能够消耗或生成一个完整高速缓存块,便于高速缓存的控制及向量访存部件的设计。 三、多线程向量处理器中向量数据存储结构实现 向量处理器是通过向量操作来支持数据并行性的处理器。为了有效地利用向量计算中的数据并行性,向量处理器的结构通常包括向量寄存器文件、深度流水的ALU和一维的SIMD组织形式的多种组合。向量寄存器文件存储的是数据向量,而不是单个的数据字,它们是在对向量进行操作时,顺序地进行传送的。不仅图像处理采用向量处理器技术,当前世界上处理速度最陕的超级计算机——日本NEc的《地球仿真测试系统》,也是以0.15mm工艺实现的向量处理器为基础,由5120个向量处理器(共有640个节点,每个节点有8个向量处理器)组成的。 1、多线程向量处理器中向量数据存储结构的回顾 整个计算机界似乎总是在不停的重复着“前进-回退-再前进”的步调。很多基础性的创新结构在很早之前都被提出了,但由于市场、技术和现实条件的限制最终只有很少的技术在一段时间内成为主流。一种主流技术在走到生命尽头之后,以前一种被遗忘技术可能被人们从故纸堆中翻出来,以崭新的面目引导新的技术革新。 在处理器体系结构设计中的上一次回归是RISC。当VAX开启了变长指令,多寻址模式等CISC技术之后,处理器设计变得越来越复杂,纯粹的CISC很难设计,也难以实现;这时提倡精简的RISC替代了VAX处理器体系结构称主流技术。在80 90年代,RISC思想JL5e遍布所有厂商的处理器。 2、桌面优化 在开始详细分析向量处理器的结构之前,不妨先看一下近30年的发展过程中桌面系统体系结构的变迁。除了CPU而外,桌面系统的其他部件的功能也不断增强。在向量处理器中以内部互连EIB总线为核心,8个完全相同的SPE(synergistic Processor Element)向量处理核心和一个PowerPC兼容的PPE(Power Processor Element)核心围绕在环状数据总线四周。XIO接口提供与Rambus XDR内存的高速互连,FlexIO提供了高速I/O通道,同时在应用中也为整个计算机工作的持续进行提供了方便。 四、结束语 本文提出一种多线程向量的存储结构,该结构支持标量数据和向量数据的混合存储,利用多线程切换来隐藏访存延迟,并让向量数据直接访问cache来提高带宽。模拟实验表明多线程能提高实用带宽,所提出的存储结构能支持高带宽的向量数据访问。 参考文献 [1]孙彩霞同时多线程处理器中的资源分配策略研究[学位论文]2006 2010年6月大庆油田建成并投入使用国内首座同行业中最大的、基于Oracle数据库的录井专业数据库。近年随着录井专业化逐步成熟, 专业内涵不断延伸, 录井数据也向着多样化发展, 种类越来越丰富, 资料采集和数据存储管理均走向标准化和集成化。作为采集勘探第一手资料的单位, 各种仪器设备和应用系统每天都会产生大量的数字信息, 包括传统录井的结构化数字信息 (气测、工程、地质数据) 以及录井新技术应用产生的非结构化数字信息 (定量荧光、岩石热解分析图片, 地质报告、解释图片等) 。这些信息汇集了所有与勘探工作过程相关的数据, 如果其中一部份被孤立在设备和应用系统自身的存储空间中, 形成各个信息孤岛, 得不到及时合理的应用, 数据量的持续爆增也会给企业带来诸多隐患。随着时间的推移, 我们越来越多的意识到合理整合利用数据对油田勘探开发生产的重要性。 Oracle数据库是一种功能非常强大的关系型数据库, 它除了可以有效的管理结构化数字信息, 做好对其的存储、安全备份、共享及应用外, 也提供了针对非关系型数字信息的强大管理功能。在Oracle数据库中, 非结构化数据可以用大对象数据类型LOB (Large Object, 大型对象) 涵盖[1]。这种类型的容量很大 (最多能容纳4GB的数据) , 且在一个二维表格中可以多次使用, 非常灵活, 正适用于像录井这种数据资料庞大的勘探服务领域。 二、Oracle非结构化LOB类型的特殊性 与传统的结构化数据类型相比较, LOB类型数据无论在管理上还是空间利用上, 都有很多特殊之处。对于传统的数据表 (结构化数据) 而言, 一个数据表只会对应一个存储数据段Data Segment对象。当数据表中包括LOB类型的数据列时, 则会创建多个数据段。由图1所示命令结果, USER_SEGMENTS中产生了两个由系统命名的段对象:LOBSEGMENT和LOBINDEX类型, 分别对应LOB段和LOB索引段。 LOB段用于存放数据表LOB列上的数据。LOB索引段是Oracle为每一个LOB类型列强制生成的索引, 主要作用是用于进行LOB类型数据检索加速的操作。它们彼此共生, 如果强制进行删除操作, 是会报错的。因此, LOB类型不能够用简单的DML语句 (INSERT、UPDATE、DELETE) 来完成数据与表的交互操作, 而是需要使用DBMS_LOB包。Oracle提供了许多内置程序包, 它们用于扩展数据库的功能。 三、利用Oracle存储过程实现BLOB类型的上传和下载 我们选择在Oracle 10g R2下进行试验。首先构建出一个试验TABLE, TABLE要建立在普通用户下, 这个普通用户应该具有可以创建和读取任意DIRECTORY的权限, 这里将表命名为TEST。 (图2) 这里选取三个字段, ID用做主键并记录数据个数, BL用于存放BLOB类型非结构化数据体, CMT用于存放BL数据的备注内容。DBMS_LOB包中提供了很多功能强大的过程和函数供用户对内部的LOB字段进行维护。这里针对BLOB的存储操作, 主要用到LOADFROMFILE () 、READ () , 即向LOB中写入数据和从LOB数据中读取指定长度数据到缓冲区的过程。 (1) Oracle存储过程实现上传。首先创建一个存储文件的DIRECTORY (图3) 。注意这个DIRECTORY隶属于Oracle数据库, 是一个“虚拟”路径, 其作用是方便用户可以在Oracle数据库中灵活的对文件进行读写操作。‘D:file’这个路径属于我们计算机的操作系统, 所以注意需要手动在D盘建立这个文件夹。 下面我们来创建并简单分析一下BLOB类型上传至Oracle数据库的存储过程。如下: 执行上面的存储过程, 目录‘D:file’中的文件就可以根据pcmt这个参数找到并上传至Oracle数据库中了。 (图4) (2) Oracle存储过程实现下载。与上传的过程相类似, 在执行下载BLOB存储过程之前, 也要先建立好一个存放下载的BLOB数据的DIRECTORY, 并将读写这个DIRECTORY的权利赋予给用户。 (图5) 与将BLOB类型数据上传至Oracle数据库不同的是, 在下载的过程中还需要用到UTL_FILE包, UTL_FILE包提供了在操作系统层面上对文件系统中文件的读写功能。在引用文件的时候, 要使用到一个文件句柄来表示对文件的读或写。文件句柄是通过UTL_FILE包[2]中名称为UTL_FILE.FILE_TYPE的公有变量来定义的, 必须声明一个类型为FILE_TYPE的变量来接收通过函数FOPEN () 返回的文件句柄。这个文件句柄将用于之后在文件上的所有操作。 下载到操作系统文件的存储过程。如下: 执行上面的存储过程, 就可得到根据pcmt这个参数找到相应的Oracle数据库BL字段中存放的BLOB类型数据内容, 并将其下载到操作系统的‘D:loadfile’文件夹下。 (图6) 四、.Net/Winform工具实现对BLOB类型数据的上传和下载 与Oracle存储过程相比, 利用代码实现对LOB类型的上传和下载更加简单方便, 且可通过代码循环实现批量处理, 速度上和用户体验度上更为良好, 这里只将设计思做简要介绍。 在设计Oracle数据表时需要注意, 除要有主键及唯一性约束条件, 对于包含有LOB类型的Oracle数据表, 必须要有一个常规字段。程序设计思路是, 通过代码连接并操作Oracle数据库, 实现数据库中BLOB类型数据与计算机操作系统中文件的交互。 .Net/Winform程序中主要用到了以下几个重要的类:System.Data.Oracle Client命名空间下的Oracle Connection类 (用于连接) , Oracle Command类 (用于执行SQL语句) , Oracle Transaction类 (数据库中事务处理) , Oracle Data Reader类 (读取数据行的只进流) , Oracle Lob类 (表示数据类型) , 以及System.IO命名空间下的用于读写文件的File Stream类。上传BLOB的过程, 其本质是将操作系统文件打开后, 读取文件内容, 写入Oracle数据库中相应BLOB字段内的过程;与此相反, 下载BLOB的过程, 实际是将二进制数据流写入新创建的系统文件中。 (图7) 五、结论 录井公司承担着为油田勘探数据采集资料并分析化验的重任, 是勘探资料有效收集, 整合利用的关键环节。对应用者而言, 非结构化数据远比结构化数据要直观, 但结构化数据同样占有及其重要的地位。在信息技术飞速发展的今天, 伴随大数据及云存储等概念的提出, 我们应当把目光更多的投向非结构化数据, 除了对其合理的应用外, 存储管理应也当将会成为未来深入研究的方向。 摘要:本文简要分析了勘探录井行业数据组成现状, 从Oracle存储过程及.Net平台下Win Form工具开发思路两个角度, 以BLOB类型为例, 研究非结构化录井数据在Oracle数据库中的存储及下载, 以实现庞大录井资料的标准存储应用, 有效提升用户对非结构化录井数据的访问速度。 关键词:非结构化数据,Oracle DBMSLOB包,存储过程,.Net/Win Form 参考文献 [1]路川.Oracle 10g宝典 (第2版) [J].电子工业出版社, 2011. 半结构化数据是指那些结构隐含或无规则、不严谨的自我描述型数据,介于严格结构化数据(如关系数据库和对象数据库中的数据)和完全无结构的数据(如声音、图像文件)之间[1]。由于半结构化数据缺乏类型信息,只有有效地将其存储之后,才能对其进行索引及查询处理,从而方便管理,因此,半结构化数据存储策略将是一个十分重要的研究课题。 近年来大量国内外相关研究机构致力于半结构化数据的存储与查询处理的研究。目前,提出并实现了的存储技术主要有:文本文件方式、RDB方式及OODB等方式。其中,文本文件的存储方式存储难度较大,不利于数据的检索和管理。RDB存储方式运算效率低,即使一个非常简单的查询也将会产生较多的联结。OODB存储方式在事先不知道数据的类型信息时,数据加载的代价可能会很高,并且一旦类型发生了变化,将会导致代价更高的模式更新,而半结构化数据正是一种缺乏类型信息,并且数据类型和模式不固定的数据,因此也不适合用OODB方式存储。 针对以上各种方式的局限性,本文提出一种动态树结构的半结构化数据存储模型,以有效解决半结构化数据类型和模式不断变化的问题,并将此模型映射到关系表中,实现了半结构化数据在关系数据库中的存储与查询。 1 半结构化数据描述模型 在将半结构化数据存储之前,首先要找到一个高度灵活的数据模型,它能够表达不同类型数据,并对半结构化数据的模式进行描述。而对此目前已经提出了多种描述形式,有基于图的描述形式和基于逻辑的描述形式。在这里采用比较有代表性的基于图的OEM模型。 OEM是斯坦福大学Serge Abiteboul教授等提出的用来描述半结构化数据的描述模型。该模型中所有的实体均为对象,由表示对象的结点和带标签(label)的有向边构成[2]。每个OEM对象都可用一个4元组表示:(oid,label,type,value)。其中oid是对象的唯一标识。label是对象的标签描述,为一字符串表达对象的含义。type是对象类型,OEM对象类型有两类:原子对象和复杂对象。原子对象是不可再分的基本类型,具有integer、string等类型的值。复杂对象是对象引用的集合,每一个对象引用指向另一个对象,不失一般性。 现结合村镇土地审批流程处理中的相关数据,在分析了流程数据具有半结构性的基础上,构造出一个有关宅基地的OEM描述模型。 由于村镇土地流转业务复杂、审批处理流程标准不统一,会使相同的土地审批处理在各村镇间有着各异的流程,甚至因为某项政策的改变,同一个村镇的某项审批处理流程也会随之发生变动。比如同样一个关于宅基地申请的处理流程,有的村镇只需“农民申请”、“村委审议”和“乡镇政府审批”三个业务点组成,有的村镇还需“实地调查审核”这个业务点,即相同的流程数据可能具有不规则的结构,并可能随时处于变化之中,从而说明土地审批处理中涉及的流程数据具有半结构性。为简单起见,在一定程度上简化了对宅基地的描述,只对其部分主要属性进行了OEM模型表达,如图1所示,认为它由用户标识符、所有者、面积、宅基地申请审批流程以及宅基地建房审批流程描述,并且每个流程业务点也只列出其中比较重要的几个属性,例如规划主体(Subject)、规划操作(Operation)、规划客体(Object)等。其中,用户标识符由用户根据其不同的含义进行定义,例如此块宅基地记为zjd1。 2 半结构化数据的动态树存储模型 半结构化数据的模式是用于描述数据结构信息的,而不是对数据结构进行强制约束[3],但由于半结构化数据的模式与数据是混淆在一起的,为此模式抽取就成为找到半结构化数据中的结构,发现数据对象间关系,从而将其存储到关系数据系统中的首要步骤。基于这样的思想,本研究提出一种动态树存储模型,此模型可体现半结构化数据的模式信息,方便我们发现半结构化数据的结构。下面仍以图1为例,首先对半结构化数据的模式进行定义,明确模式抽取的目标对象,然后详细介绍如何利用层次结构思想和累加计数原则,生成具有半结构化数据模式的动态树存储模型。 2.1 模式的定义 模式定义的提出需要引入一些OEM相关概念知识,现结合图1给出几个定义和符号表示如下: 定义1 简单路径表达式spe 令li是对象引用中的一个标签,其中i=1,…,n( n≥1),则spe=l1, l2,…,ln就是一个长度为n的简单路径表达式。 定义2 最大简单路径表达式mpe 若有一个简单路径表达式集合{spe1,spe2,…,spen},对于某个spei在集合中不存在任何spei的超集,则称spei是该集合中的最大spe,记作mpe。 例:ShengQ.PlanPoint.Subject是一个长度为3的简单路径表达式;集合S={ spe1=ShengQ.PlanPoint ;spe2=ShengQ.PlanPoint.Subject},则spe2即为该集合的mpe,ShengQ为spe1与spe2的共享前缀。 定义3 频繁简单路径表达式fpe spe出现在OEM模型中的个数,称作spe的支持度计数,记作sup(spe)。当sup(spe)≥min_sup(最小支持度阈值)时,spe就为频繁的spe,记作fpe。 定义4 数据路径表达式dp 令Oi是一个对象i=0,1,…,n,对象Oi和标签li以逗号为间隔并交替出现的序列,即dp=O0, l1,O1,l2, …, ln, On, dp就称为一个源于O0的止于On的长度为n的数据路径表达式。 例:dp={1.ShengQ.4.PlanPoint.6.Subject.17},是一个源于1的止于17的长度为3的数据路径表达式。 半结构化数据的模式抽取是为了找到数据中的结构,发现数据对象间关系,因此对OEM模型中的连接对象要比对象本身更感兴趣。而根据上面的概念可知,spe要比dp更能反映半结构化数据的一般结构。为此,将待抽取的数据模式定义为OEM中所有频繁的最大简单路径表达式(mpe)[4]。 2.2 生成具有层次结构的最大简单路径表达式集合 为了找到OEM中所有频繁的mpe,本文需首先试图生成一个由所有mpe构成的集合。由于OEM模型具有层次性,所以可充分利用深度优先遍历的优势,对图1中的OEM模型进行深度优先遍历,找出所有mpe并生成集合。借鉴文献[4]提出的分层结构的思想,可有效解决OEM模型的分支问题。因此本文同样采用此思想,将遍历得到的mpe添加层次标记,从而生成一个具有层次结构的mpe集合,记作S。这样,图1中的OEM模型经深度优先遍历之后,即可生成集合S{uid1-1,Area1-2,Owner1-3,ShengQ1-4.PlanPoint2-1.Subject3-1……}。 2.3 构造动态树结构的存储模型 得到集合S之后,便期望从中找到所有频繁的mpe,即提取出半结构化数据的模式。为此本研究提出一种累加计数原则,将S中各个元素mpe依次作为树的分支,最终生成一个动态树。由于通过此原则生成的树可方便地对数据的模式进行提取,找到半结构化数据的隐含结构,发现对象间的关系,从而将半结构化数据进行存储,于是本文提出将此树结构作为半结构化数据的存储模型。 根据OEM模型的基本特点并结合图1,可对树的结构进行如下定义: 接下来,根据上述结构定义,开始构造动态树。其中根节点的level-code和count都为0,label记为“ZJD”,id记录该宅基地的oid信息。而在将集合S中的各个元素mpe作为分支依次添加到树中时,需依据累加计数原则,以便日后提取数据的模式信息。即:添加mpe元素时,判断此元素所含的节点与当前树中的前一个节点之间是否有共享前缀,即它们的label是否相同。若无共享前缀(label不同),则创建新的分支,即直接将此元素添加到树中;若有共享前缀(label相同),则需再进一步判断它们的level-code的值是否相同。若level-code的值相同,则说明此时在添加的是OEM模型中的一个分支,即只需在原有节点下添加一个分支即可。例如:在添加元素ShengQ1-3.PlanPoint2-1.Object3-3时,因为当前树中的前一个元素为ShengQ1-3.PlanPoint2-1.Operation3-2,判断出它们的label (ShengQ.PlanPoint)以及level-code(1-3和2-1)值都相同,说明此时添加的是PlanPoint节点的一个分支,只需在原有节点PlanPoint:2-1:16:1下添加Object:3-3:19:1这一分支。若判断它们的level-code值不同,则说明此时添加的元素与之前节点不是兄弟节点,则count值加1,并将此元素涉及到的每个节点添加一条新纪录,记录保存着label、level- code、id和count的新值,进而转入开始处理新的分支。例如:在添加元素ShengQ1-3.PlanPoint2-2.Subject3-4时,判断出其与当前树中的前一个元素ShengQ1-3.PlanPoint2-1.Object3-3的label值相同,但level-code值不同,因此说明此时在添加的是一个新的分支,需要为PlanPoint节点添加一条PlanPoint:2-2:7:2的新纪录。依此类推,直至集合S中的所有元素添加完毕,此时一个由mpe构成的树就构造完成。 为了节省空间,对构造出的树又做了进一步的改进:将每个结构节点的定义信息level-code、id以及count等作为一个元素依次链成一个以各相应节点label为名字的队列。具体改进过的树结构如图2所示。 根据累加计数原则可知,通过此树各节点的count值即可方便地找出所有频繁的mpe,抽取出半结构化数据的模式,发现数据的结构。 该存储模型除了可方便我们提取数据的结构信息以外,还有着动态性,可随时方便地进行更新,以适应半结构化数据的高度灵活扩展和不规则性。比如从图2可以看出,此时的宅基地建房审批流程是由“农民申请宅基地使用权”、“村委会对农民提交材料复核”、“镇土地管理所现场勘测宅基地”以及最终的“县级政府正式批准宅基地建房”这4个业务点组成。但若某村镇的宅基地建房申请审批处理中,又规定建设单位或个人必须在用地经批准后,要由镇土地管理所现场验线,核实无误后方可施工,为此需要对宅基地建房申请审批流程增加“镇土地管理所现场验线”这个业务点,则只需在图2所示的树结构基础上,对JianF下的PlanPoint节点及其分支节点各添加一条记录:{PlanPoint:2-8:38:5;Subject:3-22:39:5;Operation:3-23:40:5;Object:3-24:41:5},而无需改变整个树结构。 由此可见,借助此动态树的存储模型,即可方便地发现半结构化数据的结构,又可实现半结构化数据的动态存储,解决其往往不规则,并且经常处于变化之中的问题。 3 半结构化数据的存储与查询 3.1 半结构化数据的存储 生成存储模型后,下一步需要解决的问题就是半结构化数据如何进行物理存储。由于关系数据库技术已发展成为一种成熟的数据库技术,所以若能利用关系数据库来存储半结构化数据,就可重用关系数据库的查询优化器和事务处理机制,以保证半结构化数据的一致性和完整性[5]。为此,本研究继续提出将生成的动态树存储模型映射到关系表中,以实现半结构化数据的存储。 首先,根据存储模型中节点的性质,将各节点划分为两类:模式节点和数据节点,对这两类节点将分别采用不同的方式映射到关系数据库中。为此,需要对存储模型中各节点的属性数据所具有的结构程度进行简单的判断,即根据节点出现的数目决定将该节点转化数据节点或模式节点。当节点数目大于某个阈值T1时,则将其定义为模式节点;否则,视为数据节点。阈值T1的确定必须合理,如果T1的取值太小,有可能形成大量元组数目较小的关系,从而影响数据存储和处理的效率;T1的取值过大,则不能充分地发挥出这种存储模型的优势。 判断出节点类型后,就可对这两类节点将分别采用不同的方式映射到关系数据库中。其中,由于数据节点和OEM描述模型中的数据节点类似,用来表示源数据中结构松散的数据。所谓“松散”是指这类节点常以属性值的形式出现在OEM描述模型中,而在存储模型中,也表现为叶节点,用来描述模式节点,因此它们大多数可以作为属性保存在对应模式节点的主关系表中。 根据节点划分规则可知,模式节点可理解为OEM描述模型中由类型相近的数据节点组成的集合,对于模式节点的存储是本研究存储映射工作中的难点和重点。每个模式节点都有一个对应的主关系表和从属关系表,用来保存集合中各源数据节点的相关信息。 在模式节点主关系表中,由于源数据节点在主关系表中唯一对应一个元组,因此可以用源数据节点的本身id作为主键。而该表中的其他属性域用来保存集合中多数节点的共有属性值,即某属性出现的次数较频繁,就将其作为一个属性域,这样可以保证表中大多数的元组具有该属性域,避免存储的浪费。为此,本研究设定一个阈值T2,并设定T2=0.5,如果具有某属性值的节点数目与总的节点数目的比值较大(大于T2),即该集合中有过半的节点都有该属性,则在主关系表中添加此属性域;而对于那些少量节点独有的属性域则需要创建单独的属性从属关系表。在该属性从属关系表中除了要保存那些少量节点的值和类型信息以外,还要根据节点队列中保存的child指针所指向的节点,保存这些节点的父节点id。 模式节点从属关系表,用来保存模式节点之间的从属关系,即该表的属性域为连接模式节点的边的开始节点id和目标节点id。通常情况下,主关系表中的一个节点可对应其他主关系表中的多个节点,因此,在模式节点从属关系表中,源数据节点的id是该表的外键。节点id作为主关系表和从属关系表的主键和外键,在数据查询时,经常用来确定关系元组,因此可在主关系表和从属关系表的ID属性域上建立哈希索引。 根据以上的映射思想,并结合图2生成的存储模型,具体的映射过程及生成的表结构如下: (1) 节点类型的划分 宽度优先遍历图2的存储模型,根据规则找出模式节点ZJD(宅基地)、Yewu_SQ(申请业务点)和Yewu_JF(建房业务点),其他节点视为数据节点。如表1、表2和表3所示。 (2) 模式节点主关系表和属性从属关系表的生成 分别对ZJD、Yewu_SQ和Yewu_JF这三个模式节点生成各自的主关系表:ZJD_main、Yewu_SQ_main以及Yewu_JF_main。在生成模式节点主关系表时,关键的步骤就是确定关系表的属性域,以Yewu_JF模式节点为例简略说明Yewu_JF_main属性域的确定过程。由于JianF分支下的PlanPoint模式节点的总节点数目为4,而Object的count为3,判断具有此属性值的节点数目与总的节点数目的比值,显然3/4大于本研究设定的阀值T2(T2=0.5),则将Object添加到PlanPoint的主关系表的属性域中。而对于Date属性,其count为1,由于1/4小于0.5,则Date的值将保存在PlanPoint的属性从属关系表Yewu_JF_AttSub中,并根据图2中节点PlanPoint和Date保存的child指针,存储属性域YuanId和ToId的值,以便日后能够对少量节点独有的属性进行查询。如表7所示。 (3) 模式节点从属关系表的生成 结合图2生成的存储模型,确定三个模式节点ZJD、Yewu_SQ和Yewu_JF之间的从属关系,从而生成模式节点从属关系表ZJD_Sub、SQ_Sub以及JF_Sub。如表4、表5和表6所示。 (4) 建立索引 分别在ZJD、Yewu_SQ和Yewu_JF的主关系表和从属关系表的ID属性域上建立哈希索引,方便数据的查询。 用关系表来存储半结构化数据必须保证不破坏或丢失原来数据的结构信息和数据信息,因此,除了要存储节点对象值之外,还要存储对象之间的关系。本研究在上述的存储映射规则中也注意了这方面的内容。从上面的存储映射规则可以看出,其中,模式节点的主关系表就是用来对节点对象的存储,而模式节点从属关系表和属性从属关系表都是对对象间关系的存储。 综上所述,本研究提出的这种存储方法将半结构化数据在很大程度上转化为关系数据,在转化的过程中既保证了半结构化数据的完整性,又没有对半结构化数据结构复杂、灵活易变的特点进行过多的限制,为利用半结构化数据的结构信息提供了有效途径。 3.2 半结构化数据的查询 通过上面的存储映射,已将半结构化数据存储到关系数据库中,因此日后对半结构化数据的查询就可转化为我们所熟知的关系表的查询,同时,也可应用传统的关系查询优化的思想和查询技术来选择具体的查询执行计划。 例如,要查询此块宅基地(uid为zjd1)建房的流程,只需写基于关系的SQL查询语句:select Subject,Operation,Object from Yewu_JF_main where ID in (select SubId from JF_Sub where ID in (select SubId from ZJD_Sub where ID in (select ID from ZJD_main where uid=zjd1)))即可查询到此块宅基地的所有建房流程。同样,也可以对宅基地的其他属性信息进行查询。 由此可见,将此动态树结构的存储模型映射到关系表中之后,即可利用关系数据库系统对半结构化数据实现查询与分析处理。 4 应用实现 将本研究提出的动态树存储模型应用到村镇土地审批处理系统中,可有效地对土地审批处理过程中涉及的各流程数据进行动态存储,实现流程的动态定制。该实例系统的具体实现技术路线包括以下几步:首先,借助OEM模型针对不同村镇的实际情况进行流程数据的动态定义,以解决流程数据的描述问题。然后,利用本研究提出的思想,生成一个具有流程数据模式信息的动态存储模型。最后,将模型映射到关系表中,实现流程数据的动态存储。以此技术路线为准则,制定了系统流程图,如图3所示。 5 结束语 本研究遵循着从概念模型到逻辑模型,再到具体物理存储的思路,逐步研讨如何实现半结构化数据的存储与查询。首先借助OEM模型(概念模型),并结合模式的定义,构造出半结构化数据的动态树存储模型(逻辑模型),然后根据一定的映射规则,将生成的存储模型映射到关系数据库中,实现了半结构化数据在计算机内部的物理存储。该存储模型不仅能够体现半结构化数据的模式信息,方便抽取数据结构,还可针对半结构化数据类型信息缺乏、描述结构不严格且不断变化等特点,随时灵活地进行更新,克服了半结构化数据存储的不确定性。另外,将此模型应用到村镇土地审批处理系统中,有效解决了个性化流程数据的动态存储问题,实现了审批处理流程的灵活定制,通过实践证明此模型的可行性和有效性。下一步工作的重点将是半结构化数据的增量更新。 参考文献 [1]Stefankis E.Modelling semi-structured geographical data[J].Interna-tional Journal of Geographical Information Science,2003,17(6):517-546. [2]Abiteboul S.Querying Semi-structured Data[C]//Proc.of ICDT Del-phi,Greece:[s,n.],1997. [3]吕橙,魏楚元,张瀚韬.基于OEM模型的半结构化数据的模式发现[J].计算机工程与应用,2006,34:162-165,181. [4]叶飞跃,蒙德龙,员红娟.一种用于存储与查询半结构化数据的新方法[J].计算机工程,2006,32(19):91-93. 云存储是一种新型的网络公用数据存储架构和服务模式,具有低设备投入、低管理成本、可扩展容量等优点,已成为构建新一代数据中心的核心技术和必然趋势。对于大型云计算服务提供商来讲,云存储可以安全地存储、管理、共享和分析大量的复杂数据,是未来存储系统发展的趋势。 然而,将数据迁移至云中,会致使用户数据的安全性和可用性面临着巨大挑战。其最大的安全问题是数据拥有者不能控制数据被存放在哪里,也对数据的访问优先权没有决定权,资源分配和调度策略的掌握在云服务提供商而不是终端用户手里。云存储适应了商业化信息存储库的需要,要确保云应用的安全,就需要维护在这种不受信任处理过程中的云存储数据安全。 2008年5月,趋势科技在美国正式最早提出“云安全”这一概念[3],推出了“云安全”技术。瑞星、江民科技、卡巴斯基、趋势、金山、SYMANTEC等也相继推出了云安全解决方案,而且中国厂商在“云安全”的技术应用上走到了世界前列。 从目前各大安全厂商推出的基于云技术的安全产品来看,云安全是云计算技术的重要分支,是基于云计算商业模式应用的安全硬件、软件、用户、机构和安全云平台的总称,是P2P技术、网格技术、云计算技术等分布式计算技术的综合应用和发展。 1 云数据存储结构 1.1 云存储的特点 与传统的存储相比,云存储利用了计算机网络技术,是将存储设备以“云”的形式组织在一起组成的复杂系统,由服务器、网络设备、存储设备、接入网、公用访问接口和应用软件等构成。云存储系统采用虚拟化技术进行存储和数据管理,资源访问按需分配,数据存储和业务访问服务通过应用软件来实现。 1.2 云存储系统的体系结构 云存储系统体系结构包括4层,即存储层、管理层、接口层和访问层,如图1所示[4,5]。 1)存储层是云存储系统的基础,由存储管理系统、存储设备和网络设备组成。存储层采用虚拟化技术对数据进行存储,并对存储硬件设备进行集中管理。 2)管理层是位于存储层之上,大量采用了集群管理技术和分布式存储技术,可以实现内容分发、数据压缩和P2P功能,并能完成数据加密、备份和容灾等任务。 3)接口层在管理层之上访问层之下,给访问层提供统一的协议和编程接口,以进行应用程序的开发,并对用户的网络接入方式、身份认证和访问权限进行管控。 4)访问层是应用程序的入口。所有授权用户都可以通过标准的公用应用接口来登录云存储系统,共享云存储所提供的服务。 2 云数据安全目前存在的问题 云数据安全存在的问题从总体上可分为三方面,一是云存储系统中数据自身的安全保护,如数据的机密性、完整性、可用性的保护等;二是提供云存储的云计算的平台安全,主要涉及到云服务提供商及其所提供的服务的安全,如云计算应用系统安全、云计算应用服务安全等;三是基于云存储的应用安全,如云计算技术在安全领域的具体应用、采用云计算技术来提升安全系统的服务效能的安全解决方案等。 2.1 云数据隐私安全 首先,存储云数据的服务器分布在世界各地,地位位置具有随意性,用户将自己的数据上传到云存储系统之后,但并不清楚自己的数据具体被存储在什么位置。用户本来就应该对自己的数据具有最优访问权,但当终端用户把自己的数据交付给云计算提供商之后,数据的优先访问权变转移到了云计算的服务提供商,而数据所有者的访问权限反而下降。因此如何保护用户对自己数据的最高访问控制权和隐私权就变得非常重要。 2.2 数据隔离安全 云计算和资源共享是通过虚拟化技术实现的,一台物理服务器上可能安装有多台虚拟机,多个用户的数据可能存储于同一台物理服务器上。在这种情况下,如果恶意用户通过不正当手段取得合法虚拟机权限,就有可能威胁到同一台物理服务器上其他虚拟机,从而非法访问其他用户的数据。因此必须对不同的用户数据进行有效隔离。 2.3 云计算平台的安全隐患 云计算平台的安全性是整个云安全的基础和重中之重。云存储系统中大量的用户业务数据、隐私信息或其他有价值信息,易引起黑客的兴趣而受到攻击。如果云存储系统遇到严重攻击,将可能面临崩溃的危险,无法提供高可靠性的服务,会导致用户数据的泄露或不可用,造成的经济损失甚至政治损失将不可估量。因此,云计算平台提供商应加固其平台,尽可阻止各种网络安全威胁,如以窃取服务或数据为目的的恶意攻击者、云计算提供商内部人员的非授权访问、合法云计算用户的滥用资源等行为。 2.4 用户数据的云安全管理问题 由于用户数据存储在云端,但用户无法知道具体的存储位置,因些很难为用户的数据安全风险评估。用户数据的安全主要取决于云计算提供商的服务或者将数据交给云计算提供商,但云计算提供商在对数据进行安全管理时,又不可能对使用云的用户进行全面而有效的监控和管理,诸多不可靠因素都会带来很多的安全管理问题。 2.5 对云计算提供商的依赖程度过高 用户将数据上传到云上之后,数据的安全几乎完全依赖于云计算提供商。如果云计算技术供应商出现破产等现象或者其提供的服务无法保证安全性,甚至导致服务中断或不稳定时,用户将面临数据存储安全等问题。因此在选择服务提供商时,应考虑其存在的风险因素。 3 云数据安全解决方案 从信息保密的角度看,云数据存储安全可以从以下几方面来考虑。 3.1 数据加密技术 由于除软件即服务(SaaS)运营商之外[6],目前云计算运营商一般不具备隐私数据的保护能力,那么对数据隐私保护的任务就落到了用户身上。为保证云数据的机密性和完整性,无论是企业用户还是个人用户,对自己上传到云上的数据尤其是敏感数据都应进行加密。但是,加密往往会降低数据的利用率,同时还涉及到密钥管理等问题,因些用户在对数据加密时应权衡保密和效率二者的关系。 3.2 数据隔离技术 由于用户对于自己的数据到底存储在云中的什么位置一无所知,自己的数据能和其他用户的数据共存于一个虚假机上。如果能利用数据隔离技术将自己的数据与其他数据隔离开,则可以更加有效地保护数据安全。 3.3 访问权限控制 由于用户将数据传输到云端服务器之后,数据的优先访问权由用户迁移至云计算提供商,用户对自己数据的访问权难以控制。因此应限制云计算服务商的访问权限,将用户的访问权限设为最优先级,由用户决定其数据的访问控制权,这样才能保证自己的数据安全。 3.4 安全云认证 在云架构中,防止用户信息的外泄,保证数据安全,可建立安全云,用于存储有安全需求的用户的数据,最终构建成可信任云。对安全云中数据的访问,可以采用多种认证方式和访问控制方式相结合的方法。 3.5 云安全风险评估 云计算服务提供商首先制定自己的安全服务等级,建立公有云和私有云,也可建立不同级别的安全云。针对不同用户对安全的不同需求,对用户数据进行安全分级,将其数据存储于对应级别的云中,对整个云数据进行风险评估,以此为依据向用户提供相应等级的安全服务。 3.6 统一威胁管理 云安全同计算机网络安全一样,面临着黑客攻击、木马、病毒、内部人员误操作等威胁。为保证云计算的可用性、可靠性及用户信息的安全,有必要建立统一威胁管理,整合数据加密技术、VPN技术、身份认证等技术手段,建立统一威胁管理平台,解决云计算架构安全、虚拟化技术安全、分布式计算安全等问题。 4 结论 云存储是未来网络存储模式的发展趋势,其安全性成为制约云存储发展的最大障碍,是用户最关心的核心问题。为最大限度确保云数据安全,可以采取提高用户的安全意识、加固云服务提供商平台的安全、对云存储数据进行加密和访问控制、建立分级的私有云并进行安全评估等手段。可以相信,在不久的将来,云存储将成为最安全最快捷的数据存储模式。 参考文献 [1]Feng D.Network storage key technology of research and progress[J].Mobile Communication,2009,33(11):35-39. [2]施珺,李慧,周立东.基于云计算的安全数据存储研究[J].南京师范大学学报:自然科学版,2012,35(3):138-142. [3]CSDN网.云计算安全最关注[EB/OL].http://www.CSDN.com [4]边根庆,高楹,邵必林.面向分散式存储的云存储安全架构[J].西安交通大学学报:自然科学版,2011,45(4):41-45. [5]杨振贤.基于云计算的安全数据存储研究与设计[J].信息安全与技术,2011(10):13-15. 关系型数据库中的表都是存储一些格式化的数据结构,每个元组字段的组成都一样,即使不是每个元组都需要所有的字段,但数据库会为每个元组分配所有的字段,这样的结构可以便于表与表之间进行连接等操作,但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储,它的结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。 随着互联网技术的发展以及企业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. 据浪潮集团存储产品部资深工程师分析, 目前, 制造业的存储数据一般被分为以下几种类型:其一, 产品设计数据, 这类数据的典型特点是以文件为主, 非结构化, 共享要求比较高, 保存时间也比较长;其二, 企业生产环节的业务数据, 其特点是以数据库等结构化数据为主, 这些数据的重要性不言而喻, 它们不仅表现企业目前运行的状况, 而且为企业进一步发展决策提供有价值的分析;其三, 生产监控数据, 其特点是数据量非常大, 对存储空间以及I/O吞吐要求高。鉴于制造业以上数据特征, 浪潮存储建议在构建数据存储平台时, 一方面要确保核心业务系统的高性能、高可靠性数据访问需求及未来扩展的灵活性, 另一方面, 要在消除信息孤岛, 实现真正的存储信息、存储资源整合方面做足功课。 另外, 从应用方面考虑, 制造行业用户的数据价值以及数据抗风险能力需求在逐步递增, 如何根据制造业的特点和需求提供数据容灾解决方案, 以保证制造业核心数据价值和业务连续性成为制造业数据存储建设的新趋势。据浪潮存储工程师介绍, 做到真正的有“备“无患绝对是一个体系化的信息系统工程, 与制造企业信息化进程的诸多因素息息相关。浪潮认为, 通过对需求的深度分析, 结合企业需求提供和实施定制化的解决方案, 完全可以满足制造业用户对于数据安全以及业务连续性的需求, 同时也能够帮助用户最大限度的降低在容灾上的成本投入。 随着我国互联网的飞速发展,据中国互联网信息中心(CNNIC)最新发布的调查报告显示,我国网络购物用户年增长达到6.0个百分点。电子商务已经成为一种重要的市场行为和生活方式,人类社会活动正在从传统的物理空间延伸到数字空间。目前,针对虚拟资产的犯罪和破坏活动日益猖獗,虚拟资产的保护和管理对维护社会安定具有重要意义。我们结合虚拟资产用户操作数据流的特点, 在数据流处理技术基础上构建流立方体,介绍其模型和聚集方法,为下一步的审计和追溯提供数据模型支持。 数据流是实时、连续、有序的数据项序列(顺序由到达时间隐含地表示或显式地由时间戳指定), 具有几个方面的特点:(1)流中的数据元素实时到达;(2)系统无法控制新到达的数据元素的顺序;(3) 数据流的潜在大小是无限的,系统的存储能力相对数据流的大小是有限的;(4)数据流模型中查询是相对不变的,而数据是时刻变化的;(5)数据流的扫描处理是一遍的,但是处理过的数据元素可能需要再次被访问。 流数据方其实是多维数据表。由于存储空间和计算能力的限制,一般采用单遍扫描的处理算法对数据流进行多维、多层次聚集,构建虚拟的数据立方体。这种聚集结果也是分析人员最感兴趣的内容。 2 相关研究 近几年随着数据仓库和OLAP技术的发展,数据仓库和数据立方体已经成功应用在了许多领域,数据立方体成为了 数据仓库 系统中的 关键部分 。数据仓 库和OLAP技术是基于静态数据提供快速的在线数据分析 ,静态数据以关系或多维数组的形式进行存储。 数据流上的数据立方体和传统数据仓库上的数据立方体的最主要区别是数据立方体的更新模式不同: 数据流上的数据立方体更新必须是即时的, 这样才能满足数据流实时查询最新数据的要求。数据立方体的计算时间和数据的维数成指数关系, 数据流快速变化意味着数据立方体的更新将非常频繁,需要消耗大量的计算资源。 最近出现了很多以数据流为信息承载模式的应用系统,这些系统都主要用于具有连续性、顺序性、实时性和海量性等特点的数据流处理。目前较为著名的项目主要有加州大学伯克利分校的Telegraph CQ、AT&T实验室的Gigacope、布朗大学和麻省理工大学合作的Aurora项目以及Wisconsin大学的Niagara CQ等。 3 主要工作 3.1 问题描述 虚拟资产保全系统的数据来源于各个虚拟资产平台,通过对数据格式进行规范后再进行保存。大部分虚拟资产数据是用户操作日志,日志里包括用户每次登录后所访问的页面、点击以及购买的商品等数据。其格式如表1所示。 操作日志 数据可以 划分多个 维度 , 如用户账 号(Buyer ID)、用户登录的IP、登录时间、退出时间和操作时长等。各个维度自身又可以被抽象为不同粒度的概念层次,由此得到该维度的层次树。如图1所示,展示了虚拟资产操作日志数据IP维的层次树。 定义1追溯维度是虚拟资产审计追溯所检测到的用户数据流中的相关维度。 定义2追溯视角是在一组追溯维度中分别选定某抽象层的对象所组成的流筛选条件。 海量虚拟资产数据管理模块进行审计追溯时通常是根据所关注的问题在几个追溯维度上各选择一个抽象层次进行组合成为筛选条件,即选定追溯视角作为限制条件,满足条件的操作记录作为追溯结果。 例如, 某一安全管理员需要追踪某个三星级用户user1在时间段[0:00,02:00]上的活动记录 ,则其选取的追溯视角为用户维的三星级用户层和时间维的小时层。 基于追溯视角选定的子数据流,虚拟资产数据管理系统可以根据具体审计追溯过程所定义的需求对该子数据流进行深层分析挖掘。例如,对于某个时间段内虚拟资产用户动态进行挖掘,可能的追溯内容包括:(1)某个用户在T时间段内登录的IP分布;(2)某个用户在某个IP上的活动 时间段 ; (3)Buyer ID =aaa,IP=10.0.0.6time=[02:00,10:00], 基于该追溯视角下 , 查看aaa用户的活动记录等。 在后面的实验中,我们将对(2)、(3)类型的追溯内容作为测试对象。 3.2 流数据的预处理 数据立方体[9]有效计算的一般优化技术有四种。 (1)排序、散列和分组。应当对维属性使用排序 、散列和分组操作,以便对相关元组重新定序和聚类。在立方体计算中, 对共享一组相同维值的元组进行聚集,有利于聚集的计算。 (2)同时聚集和缓存中间结果。在立方体计算中,从先前计算的较低聚集而不是从基本事实表计算较高层聚集是有效的。 (3)当存在多个子女方体时 ,由最小的子女聚集。当存在多个子女方体时,由先前计算的最小子女方体计算父母方体通常更有效。 (4)可以使用先验剪枝方法有效地计算冰山立方体[]。 根据统计, 我们可以知道用户、IP和时间在维度层次上存在的关系:IP> Buyer ID >Time。因此我们把虚拟资产用户操作数据流依次按照IP、Buyer ID和Login DT进行分组得到数据流Group_DS。 虚拟资产用户操作数据包括用户ID、登录IP、登录时间、操作类型(浏览商品、加入购物车、结算、货运方式、提交订单、付款方式、查看订单、付款)、退出时间、执行时长。这些数据可以分为属性数据和操作序列数据两部分。在数据流立方体构建前,我们首先要对用户操作数据进行预处理,划分成用户属性集和操作序列集。属性集包括用户ID、登录IP、登录时间、退出时间、执行时长;操作序列集包括用户ID、浏览商品、加入购物车、结算、提交订单、货运方式、查看订单、付款方式、付款。处理步骤如下: 输入:Group_DS。 输出:属性集list1、操作序列集list2。 1) load(Group_DS)// 加载数据流。 2) for(i=0;i<|Group_DS|;i++) 3) drill_info (Group_DS) by Buyer ID、IP、Login DT、Out DT、OPT_TYPE、Last Time// 对数据流进行信息抽取。 4)Create table list1, inser Buyer ID, I P,Login DT,Out DT, Last Time into list1 ;Create table list2, insertBuyer ID, Login DT ,OPT_TYPE into list2//list1和list2分别用来存储日志的静态属性集和操作序列集。 5)end。 经过处理可疑得到静态属性集list1和序列集list2,其结构如表2和表3所示。 在虚拟资产用户流数据立方体构造中,我们首先根据表list1进行分区,再根据表list2进行聚集计算。 3.3 模型结构构造 虚拟资产数据流立方体是虚拟资产数据审计和追溯中常用的支持多维和层次数据分析的模型,支持上卷和下钻等操作,可以从不同追溯视角审查当前虚拟资产用户的动态和分析预测安全形势。 定义3给定一个数据集D、一组维度Z={Z1,Z2,… ,Zn | n>0}和各个维度的层次集合H={H1,H2,… ,Hn| n>0}, (Hi (0<i≤n) 是维度Zi层次关系的集合 ,Hj i表示维度Zi的第j个抽象层次)。在H的分量{H1,H2,… ,Hn}中各取一个层次进行组合 , 对所有这样的组合{Hj11,Hj22,…,Hjnn}在数据集D上执行分组聚合操作而得到的一组立方体单元构成一个数据立方体 (表示为CZ)。 定义4一个立方体单元是一个二元组 (A,M),其中A是在每一个维 度Zi上具体抽 象层次的集 合 ,A={Hj11,Hj22,… ,Hjnn}其中Hji i可以用 * 来表示最高抽象层次,表示立方体单元在该维度上不取维度值。M是对A进行聚集操作后得到的结果。 设T、U、I分别表示时间、用户和IP地址三个不同属性,T2、U2、I2是比T1、U1、I1在其相应属性上更高的抽象层,一个三维虚拟资产数据立方体格如图2所示。 虚拟资产用户操作数据流可以划分为多个如图2所示的日志维度,每个维度自身又可再细分为多个不同的抽象层次,从不同维度、层次上对流立方体进行查询分析,可以得到不同粒度级的数据信息。构建立方体可以用SQL查询说明,如下面的例子所示。 Compute cube eid_iceberg as Select Buyer ID,Login DT,ip,add(*) From eid Info Cube by Buyer ID,Login DT,ip Compute cube语句说明立方体eid_iceberg的预计算,使用维Buyer ID、Login DT、ip和聚集度量add(*),其中add()函数是对操作序列进行串联。 在构建虚拟资产数据流立方体时,我们可以采用多维聚集算法 (Multi Way),Multi Way计算从基本方体开始,逐步向上到更泛化的祖先方体。Multi Way算法的伪代码表示如下: 输入:list1,list2;迭代的起始维Z1; 全程量:维度层次H,分流维度Z; 输出:用于追溯的流立方体SCZ。 (1)for(d=dim;d<|Z|;d++) // 划分每个维; (2) C=cardinality[d]; //d维的基数; (3) Partition(input,d,c,data Count[d]) // 对维d创建数据的C个分区; (4) K=0; (5) for(i=0;i<C;i++)do // 对每个分区; (6) C=data Count[d][i]; (7) Multi Way(input[k..k+c-1],d+1); // 在下一个维上聚集; (8) K+=c; (9) endfor; (10)output Rec.dim[d]=all; (12)endfor。 经过上面算法构建的立方体是全立方体,它存储着当前时间段内所有用户的操作记录。由于运算和存储的限制,我们可以根据实际条件选择时间窗口的大小和构建策略。 4 实验及分析 为了验证此模型的性能, 我们使用实际数据进行了实验。 实验环境 为AMD Athlon 64 PC 3600+(2.09GHz)、2GB内存、Window XP。实验所用用户行为数据源于开源电子商务交易平台ECMALL, 数据集包含7000条用户操作数据。我们分别基于My SQL数据库和流立方体对某一个用户的行为进行追踪。其测试结果如图3所示,可以看出构建流立方体可以有效地提高虚拟资产数据追溯性能。 5 结束语 本文根据虚拟资产用户操作日志数据流的特点,先对操作日志流数据进行分组和分割预处理,在此基础上应用多路聚集算法Multi Way,构建用户操作日志数据流立方体。这个算法采用多路聚集策略,能提高聚集速度实验证明本文的构建方法能提高审计追溯效率。由于流立方体的存储空间限制, 审计追踪侧重于可疑操作,因此下一步工作重点是研究如何缩小存储体积和提高追踪精确度。另外,虚拟资产保全系统是为管理者提供异常预警功能,如何快速审计追踪是我们研究的重点。 摘要:随着电子商务的深入发展,基于虚拟资产用户操作数据流立方体的构建技术成为了当前研究热点。文章针对虚拟资产用户操作数据流的特点,首先对数据流进行分组操作,并从中抽取属性集和操作序列集,然后构建流立方体模型。在流立方体构建中采用多路聚集算法,提高聚集性能。在真实数据集上进行实验测试表明,该模型能有效提高异常操作追溯性能。 【非结构化数据存储】推荐阅读: 基于关系数据库的地籍空间数据存储结构07-18 数据结构实验报告三线性表的链式存储09-02 非结构化问题07-17 随机非结构化05-31 非结构化道路11-17 非结构化流程图07-13 非结构信息06-28 非结构构件08-06 非结构网格11-05 建筑非结构构件07-04非结构化数据存储 篇3
非结构化数据存储 篇4
非结构化数据存储 篇5
非结构化数据存储 篇6
非结构化数据存储 篇7
非结构化数据存储 篇8
非结构化数据存储 篇9