CN106156338A - 一种信息发现服务器的数据存储方法和信息发现方法 - Google Patents

Abstract

本发明公开了一种信息发现服务器的数据存储方法和信息发现方法，主要包括：所有的DS数据都存储在一个单一的大表中，表中的每一行都有一个行健，整个表按照行健物品编码进行排序，每一行包含可变数量的单元，每个单元以一个事件时间戳命名，行和列的交叉单元（cell）内容是一个DS事件描述。对表的所有访问都需要通过行键。新列可以被实时地追加，不同行所包含的列的数量及列的名称互不影响。对表的所有访问都需要通过行键，找到行后读取出所需要的列信息，并按照信息的类型进行处理后返回结果；从而可以克服现有技术中集中索引模式信息发现服务面临着海量数据和高并发读写访问的压力和限制。

Description

一种信息发现服务器的数据存储方法和信息发现方法

技术领域

本发明涉及技术物联网信息发现服务领域，具体地，涉及一种信息发现服务器的数据存储方法和信息发现方法。

背景技术

“物联网”应用的兴起必然会产生布于不同的信息服务器的海量数据和事件信息。在现实的应用环境中，为了实现“物物相连”以及智能地分享和处理信息，需要设计一个中间件从海量的动态信息中查找有用的数据，即便数据的获取地址和存储形式对于数据的请求者来说是未知的。以上是人们对于信息发现的概念性认识。EPCglobal项目已经发布了物品解析服务（ONS）和信息服务（IS）的较为详细的标准，然而对信息发现服务（DS）却因为其固有复杂性目前尚未给出具体的标准，而仅仅描述了它的职能。2007年，BRIDGE (BuildingRadio frequency Identification for the Global Environment)项目基于 EPCglobal标准，对单品级别的信息查询作出了进一步的研究并给出了信息发现的进一步定义，包括信息发现记录的分类、信息发现服务的输入输出、安全机制等，并对信息发现实现模式进行分析，总结得到了四种可行模式，分别是资源目录模式、资源通知模式、客户端通知模式和请求传播模式。IBM开发过一种Theseos搜索引擎以请求传播的方式来在IS链中追溯单品在供应链中的移动。Wen Zhao[11]将信息发现解决方案从数据存储方式的角度分成三种模式，分别是集中仓库模式、集中索引模式和追踪链式。以上这些可行模式大体上可以总结为两种，分别是P2P模式和集中索引模式。P2P模式是指将信息发现请求在多个上下游IS节点之间传播以获得结果集，而集中索引模式是指由IS节点将本地捕捉的事件以轻量级索引的形式托管给一个集中信息发现服务器，集中信息发现服务器接受发现请求得到本地检索结果后将请求重定向至目标IS结点。

信息发现提供了查找对象到其资源列表的映射关系的功能。对于“信息发现”的定义，目前业界还没有统一的定论。

在实现本发明的过程中，发明人发现现有技术中P2P模式信息发现服务的优点是可以较好地实现负载均衡，而却面临着固有断链问题，即供应链中某中间节点事件信息的遗漏将会下游事件信息链的全部丢失。集中索引模式信息发现服务则恰好相反，某中间节点事件信息的遗漏不会影响发现结果的整体质量，但却面临着海量数据和高并发读写访问的挑战。

发明内容

本发明的目的在于，针对上述问题，提出一种信息发现服务器的数据存储方法和信息发现方法，以实现提升信息发现服务的质量。

为实现上述目的，本发明采用的技术方案是：信息发现服务器的存储方法，主要包括：

a．基于HBase定义列族，创建数据表；

b．将行键存储在数据表的每一行，并按照行键进行排序，所述行键为物品编码；

c．用信息发现服务事件发生时间戳标示列名，并存储一个信息发现服务事件的索引文本；

d．每个行与列的交叉单元存储放置信息发现服务的事件描述。

进一步地，所述信息发现服务事件为只涉及一个对象集合的基本事件、涉及一个父对象和一个子对象集合的聚集事件以及涉及一个父对象集合和一个子对象集合的转化事件。

进一步地，步骤d中，所述信息发现服务的事件描述信息具体为事件的类型信息、来源信息服务器地址信息和相关物品集合的信息。

基于所述信息服务器的信息发现方法，包括以下步骤：

（1）状态初始化化为开始状态Level_0；

（2）按照输入的物品编码OID即行键和一个发现时间范围（ST, ET）即开始时间到结束时间的范围，读取与物品编码OID对应的行，并根据时间范围筛选出事件列表L；

（3）按照时间顺序依次读取时间列表L的元素并处理；

（4）判断时间列表的所有元素是否被处理完毕，如果处理完毕则结束发现并返回结果集。

进一步地，所述步骤（3）具体为，按时间顺序依次读取事件列表中的元素，如果所得是聚集事件，则跳转到状态Level_(x+1)所述x是当前状态，然后递归地执行对当前事件时间和ET的发现，将返回结果追加到结果集中，如果返回结果的最后一个元素等于L中的下一个元素，则跳过下一个元素并继续执行步骤d；否则说明OID的生命周期还未结束，结束当前发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如果所得是拆分事件，则跳转到状态Level_(x-1)所述x是当前状态，将这个时间加入结果集然后结束发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如所得是一个转化事件，结束发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如所得是一个基本类型事件，则不做状态改变，将当前事件加入结果集并继续执行步骤d。

本发明各实施例的，由于主要包括：所有的DS数据都存储在一个单一的大表中，表中的每一行都有一个行健，整个表按照行健物品编码进行排序，每一行包含可变数量的单元，每个单元以一个事件时间戳命名，行和列的交叉单元（cell）内容是一个DS事件描述。对表的所有访问都需要通过行键。新列可以被实时地追加，不同行所包含的列的数量及列的名称互不影响。对表的所有访问都需要通过行键，找到行后读取出所需要的列信息，并按照信息的类型进行处理后返回结果；从而可以克服现有技术中集中索引模式信息发现服务面临着海量数据和高并发读写访问的压力和限制。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。

下面通过实施例，对本发明的技术方案做进一步的详细描述。

具体实施方式

以下本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

具体地，集中索引式信息发现服务器处理大并发量读写请求效率的瓶颈来自其数据存储层，因此提升数据存储层对并发读写的支持效率能够直接提升信息发现服务的质量。

信息发现服务器所维护的事件索引的典型结构信息发现服务器所维护的事件主要有三种，分别是只涉及一个对象集合的基本事件（BasicEvent），事件动作包括LINK、CREATE、CLOSE、DESTROY等；涉及一个父对象和一个子对象集合的聚集事件（AggEvent），事件动作包括ADD和DELETE，一般指运输过程中的装包和拆包事件；涉及一个父对象集合和一个子对象集合的转化事件（TransEvent），记录了将父对象集合中的物品转化为子对象集合中的物品，一般是指生产加工事件。每个事件关联到一个信息服务器，该信息服务器存储着该事件的详细感知数据。每个信息服务器都有其唯一的ID、地址、类型等信息。

采用Key-Value存储模式将DS事件索引存储在分布式数据库中。所设计的存储结构。所有的DS数据都存储在一个单一的大表中。这个表中的每一行都有一个行健，即单品的物品编码，整个表按照行健物品编码进行排序。每一行包含可变数量的单元，每个单元以一个事件时间戳命名。行和列的交叉单元（cell）内容是一个DS事件描述。对表的所有访问都需要通过行键。新列可以被实时地追加，不同行所包含的列的数量及列的名称互不影响。对表的所有访问都需要通过行键，找到行后读取出所需要的列信息。

每个行与列交叉的单元记录一个DS事件描述，包括该事件的类型、来源信息服务器地址、相关物品集合等基本信息。

例如一个示例事件索引，记录了在2012-08-06 13:58:19这一时刻所发生的一个聚集事件，标示为x001, x002, ……，x010和 y001，y002，……，y020的30个物品被装载入标示为z001的容器，该事件的发布来源为IS_001信息服务器，地址是http://www.001.com/IS。当信息发现服务器收到来自可信IS服务器的事件索引发布请求时，将该事件索引追加到事件相关物品编码所对应的行中。当信息发现服务器收到来自合法用户的信息发现请求时，查找到目标物品编码所对应的行，读出相关的事件索引列表，提取出相关信息摘要返回给用户。

物联网信息发现过程可以定义为一个分层的寻址模型。定义在第n个寻址层的对象标示是X_n；寻址服务器是S_n；而资源地址是Y_n，寻址服务器负责将对象标示转化为资源地址或资源地址集合。定义在第n个寻址层的资源转化函数为TS_n，则有：

在函数TS_n中，对象标示和寻址服务器是输入，而转化等到的资源地址是输出。对于相同的输入，输出的资源地址一定相同；而对于相同的输出，输入的对象标示不一定相同。定义在第n个寻址层的资源寻址函数为AS_n,

在函数AS_n中，资源地址是输入而下一层的寻址服务器地址是输出。对于相同的输入，输出的寻址服务器一定是相同的；而对于相同的输出，所输入的资源地址不一定相同。假设寻址层的总数是M，则完整地寻址过程可以被通用性地定义为：

根据上述定义，本项目中物联网资源寻址和信息发现的可以看做是一个四层寻址模型，第一层是对象标示标准寻址层，负责将物品编码类别通过FDR库转化为标示解析规则FDR。第二层是物体标示寻址层，负责将物品编码经FDR转换后由ONS解析为信息资源地址，即对应DS服务器地址。第三层是发现服务寻址层，负责将物品编码由信息发现服务器转化为多个信息服务IS地址。第四层是数据寻址层，负责由信息服务器将物品编码转化为感知数据集。按照上述的形式化定义方式，可以由公式（6）-（10）描述该寻址模型将物品编码转化为感知信息集合的完整过程。

从流程的角度，整个信息发现过程其实可以分为三个主要步骤：溯源（查找Local_DS），发现（通过DS协作找到iotIS地址列表）和查询（Client向iotIS查询详细信息）。其具体执行方式如下所述：

步骤1.Client向Local_ONS查找Local_DS地址

Client提交查询商品的OID（商品的ID可以是各种形式的编码，例如SSCC，SGTIN，二维码等能够唯一标示商品的编码）向Local_ONS请求创建该OID的企业或者机构对应的Local_DS的地址。Local_ONS首先从自己维护的记录和缓存中查找Local_DS地址，如果找到了，则向用户返回查找到的Local_DS地址并执行步骤4。如果Local_DS在自己维护的记录中没有找目标Local_DS的地址到则执行步骤2。

步骤2.Local_ONS向Root_ONS请求Local_DS地址

Local_ONS将根据商品ID解析出Company_Prefix，然后Root_ONS根据Company_Prefix查询并返回维护此种商品编码的Local_ONS(N)的地址信息并执行步骤3。

步骤3.Local_ONS向Local_ONS(N)查询OID所在Local_DS服务器

Local_ONS在收到Root_ONS返回的Local_ONS(N)的地址后，向其查询Local_DS地址并将结果返回给Client。

步骤4.Client查询对象所在iotIS

Client根据得到Local_DS地址，向其查询包含OID的iotIS地址列表。在查询过程中将根据不同的发现机制返回由若干个iotIS地址组成的列表。

步骤5.Client向iotIS查询商品信息

Client根据DS返回的iotIS地址列表和相关附加信息，向感兴趣的iotIS服务器查询相关详细信息。例如：对于畜禽肉类产品，用户可能对冷链运输环节的信息比较感兴趣，那个可以从iotIS地址列表中提供查询冷链运输相关信息的iotIS服务器获取有关温度，时间，运输车辆等更加详细的数据。

搭建分布式HBase数据库的第一步是部署一个Hadoop集群，然后在集群上依次安装zookeeper分布式***管理工具和HBase数据库。一个HBase集群通常需要至少三台机器，其中一台配置为Master服务器负责管理整个集群、均衡负载等工作，其他机器配置为Region服务器负责存储数据和处理数据访问请求。Hadoop/HBase集群的具体安装和配置可参考Apache官方文档（http://hbase.apache.org/configuration.html）等资料，其中特别值得注意的是hadoop、zookeeper、HBase版本的选择必须互相兼容。

完成了分布式HBase数据库的安装后的第二步是根据设计好的存储结构在HBase中创建数据表。HBase数据表中的每一行必须有一个行健，所有数据访问都必须通过这个行键，没有二级索引，创表时要预先定义好表中的列族，HBase是列式存储数据库，同一列族下的所有数据将会被连续存储，列族中的列可以在数据表创建后动态地追加，不同行中的列不需要一致。行键、列族、列名决定一个数据单元。每个数据单元可以根据写入时间区分为多个版本的值，默认情况下一个数据单元最多可以有三个版本。当更多新版本写入后，最老的版本将会被覆盖。全表只有一个列族event,行键是物品编码OID，列族event中包含任意个列可动态追加，每个列存储一个DS事件索引文本，列名用事件发生时间戳进行标示。

通过HBaseShell来手动创建上述数据表。登陆HBase的shell环境。使用create命令创建数据表，create命令后跟的第一个元素是表的名称，后面的若干个元素是表中的列族，下方例子是创建一个包含一个列族event名称是EPC_Index的表。使用put命令可以手动向数据表中***数据，put命令后跟的第一个元素是表的名称，第二个元素是行键，第三个元素是列族和列名，第四个元素则是要写入的单元内容，下方例子是向EPC_Index表中的OID1这一行中的event列族下的20130810132453这一列写入信息eventExample。

本发明中设计与实现的集中索引式信息发现服务器的主要功能包括管理海量DS事件索引，根据物品编码在海量DS事件索引中进行递归发现，动态接收来自合法信息服务器的事件发布请求等。信息发现服务器对外开放两类服务接口，第一类接口负责接收来自信息服务器的事件索引发布请求，第二类接口负责接收发现查询请求并返回发现结果。

信息发现服务器的三个主要接口的具体定义，第一个接口是对物品的非递归事件列表查询，输入参数是物品编码、起始时间和结束时间，返回结果是该物品在这段时间内所经历的所有直接相关（该物品直接被扫描）的事件列表。第二个接口是对物品的递归信息发现查询，输入参数也是物品编码、起始时间和结束时间，返回结果是该物品在这段时间内所经历的所有直接相关和间接相关（该物品未被直接扫描，但其所在容器被扫描）的事件列表。第三个接口是接受来自厂商信息服务器的事件索引发布请求，输入参数是事件动作、信息服务器标示、服务类型、服务地址、发生时间、关联父物品编码、关联子物品编码列表、关联父物品编码列表，以上参数根据不同情况有不同的设置和缺省方式，返回结果是发布求求的处理结果。

信息发现服务器遵循的业务流程处理发布事件索引请求。服务器接收到发布请求后，首先对发布者进行权限认证，认证通过后对其发布的事件数据进行处理，获得该事件所有相关物品编码列表并按照既定格式生成事件索引标准文本，然后将该文本写入所有相关物品编码在HBase表中对应的行末，以事件发生时间戳为标示。最后将请求处理状态返回给发布者。

非递归事件查询的业务逻辑比较简单，根据物品编码定位到数据表中的相应的行，然后从该行中筛选出在目标时间范围内的事件索引，按照查询者权限对数据进行处理后返回即可。递归发现查询的业务逻辑则相对负责，其执行需遵循递归发现状态机，其具体执行流程如下：

0. 将状态初始化为开始状态Level_0。

1. 输入一个物品编码OID和一个发现时间范围（ST, ET），记为（OID，ST，ET）。

2. 从数据表中读取该OID所对应的一行，并根据时间范围筛选出事件列表L。

3. 按时间顺序依次读取事件列表L中的元素，

a)如所得是一个将当前OID加入容器OID*的聚集事件，则跳转到状态Level_(x+1)(x是当前状态)然后递归地执行对(OID*, 当前事件时间，ET)的发现。假设该发现返回结果为R*，将R*追加到结果集中。如果R*的最后一个元素等于L中的下一个元素，则跳过下一个元素并继续执行步骤3；否则说明OID的生命周期还未结束，可结束当前发现并返回结果集。

b)如所得是一个将上一个物品OID*从当前OID中取出的拆分事件，则跳转到状态Level_(x-1)(x是当前状态)，将这个时间加入结果集然后结束发现并返回结果集。

c)如所得是将当前OID关闭或销毁或转化为其他物品，结束发现并返回结果集。

d)如所得是一个基本类型事件，不做状态改变，将当前事件加入结果集并继续执行步骤3.

如果L中所有元素都已经被处理，但发现还没有结束，说明OID的生命周期还没有完整，结束发现并返回结果集。

为了验证本发明设计的基于HBase数据库的DS服务器性能的提升。我们另外实现了两种基于关系型数据库MySQL的DS服务器原型进行对比试验。在接下来的实验中，我们将这两个DS服务器原型命名为Mode1和Mode2,而将本项目中设计并实现的DS服务器命名为Mode3。三个原型的业务逻辑层是相似的，区别在于数据持久层的实现。

为了充分验证性能，我们共进行了四组实验，分别记录三种模式下DS在不同业务数据量下单次递归查询的耗时、不同业务数据量下的磁盘空间占用、不同并发用户量下单位时间内处理的递归查询数、以及不同并发用户量下单位时间内处理的发布请求数。

第一组实验记录三种模式的DS服务器在随着数据库中数据量不断增加的情况下处理单次递归查询平均耗时的变化。随着数据库中追溯的单品数从1万逐渐增加到100万，Mode1下的单次递归查询耗时大大地增加，最大数据量时单次查询耗时200多秒，显然是难以接受的；Mode2下的单次递归查询耗时逐渐从十几毫秒增加到了100多毫秒，还是可以接受的水平；Mode3下的单次递归查询耗时没有明显的增长趋势，且远远低于前两种模式。

第二组实验记录随着业务数据量从对1万单品的追溯增加到对100万单品的追溯，三种模式的磁盘空间消耗情况。很明显Mode1是最节省磁盘空间的，Mode2所消耗的磁盘空间大爷是Mode1的近三倍，Mode3所耗磁盘空间大约比Mode2高30%，这是在数据没有被备份的情况下。生产环境下部署HBase数据表时，一般建议设置将数据重复存储3次，以提高可用性和可靠性。虽然Mode3消耗磁盘较大，但考虑到磁盘价格低廉以及带来的大幅度的性能提升，我们认为还是可以接受的。

第三组实验记录随着并发用户数量的增加，DS服务器单位时间内能处理并发查询的总数。由于在第一组实验中我们已经排除了Mode1的可行性，因此第三组和第四组实验没有包含Mode1。另外由于MySQL软件所允许的最大并发连接数为100，因此并发用户数超过100的实验我们只对Mode3执行。随着并发用户数从1逐渐增加至400，Mode3每秒钟所能处理的递归请求数从100左右增加到了近2000，而Mode2始终位置在10左右的水平。可以说Mode3处理并发查询请求的能力是远远超过Mode2的。

第四组实验记录随着并发用户数量的增加，DS服务器单位时间内能处理的新事件索引发布请求的总数。出于同样的原因，并发用户数超过100的实验只对Mode3执行。随着并发用户数从1逐渐增加至400，Mode2每秒钟最多能处理70多个发布请求，而Mode3每秒钟最多能处理300个以上的发布请求，大约是Mode2的五倍，因此Mode3处理发布请求的能力也是大大优于Mode2的。

以上四组实验证明了本项目所设计并实现的基于新存储模式的信息发现服务器比较以往的信息发现服务器不管是在单次查询效率还是处理多用户并发查询和发布请求的能力上都是大大优先的，虽然该存储模式导致的数据冗余使得占用磁盘空间较多，但我们认为冗余的磁盘消耗程度还是可以接受的。

至少可以达到以下有益效果：提出并实现了基于HBase的集中索引式信息发现服务器，大大提升了信息发现服务处理海量数据和高并发请求的能力，提升了信息发现服务的质量，并且充分的实验数据证明改进方案切实可行的，在功能和性能上具有非常大的优势。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种信息发现服务器的数据存储方法，其特征在于，包括以下步骤：

a．基于HBase定义列族，创建数据表；

b．将行键存储在数据表的每一行，并按照行键进行排序，所述行键为物品编码；

c．用信息发现服务事件发生时间戳标示列名，并存储一个信息发现服务事件的索引文本，所述列可被实时动态追加；

d．每个行与列的交叉单元存储放置信息发现服务的事件描述。

2.根据权利要求1所述的物联网集中索引式信息发现服务器的数据存储方法，其特征在于，所述信息发现服务事件为只涉及一个对象集合的基本事件、涉及一个父对象和一个子对象集合的聚集事件以及涉及一个父对象集合和一个子对象集合的转化事件。

3.根据权利要求2所述的信息发现服务器的数据存储方法，其特征在于，步骤d中，所述信息发现服务的事件描述信息具体为事件的类型信息、来源信息服务器地址信息和相关物品集合的信息。

4.一种基于权利要求3所述的信息发现服务器的信息发现方法，其特征在于，包括以下步骤：

（1）状态初始化化为开始状态Level_0；

（2）按照输入的物品编码OID即行键和一个发现时间范围（ST, ET）即开始时间到结束时间的范围，读取与物品编码OID对应的行，并根据时间范围筛选出事件列表L；

（3）按照时间顺序依次读取时间列表L的元素并处理；

（4）判断时间列表的所有元素是否被处理完毕，如果处理完毕则结束发现并返回结果集。

5.根据权利要求4所述的基于信息发现服务器信息发现方法，其特征在于，所述步骤（3）具体为，按时间顺序依次读取事件列表中的元素，如果所得是聚集事件，则跳转到状态Level_(x+1)所述x是当前状态，然后递归地执行对当前事件时间和ET的发现，将返回结果追加到结果集中，如果返回结果的最后一个元素等于L中的下一个元素，则跳过下一个元素并继续执行步骤d；否则说明OID的生命周期还未结束，结束当前发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如果所得是拆分事件，则跳转到状态Level_(x-1)所述x是当前状态，将这个时间加入结果集然后结束发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如所得是一个转化事件，结束发现并返回结果集；

按时间顺序依次读取事件列表中的元素，如所得是一个基本类型事件，则不做状态改变，将当前事件加入结果集并继续执行步骤d。