文摘

大数据时代的城市举行的大规模城市数据创建有价值的信息和数字增强服务。城市数据来源通常分为三种类型之一:官员,社会,和感觉的,从政府、企业、公民、社会网络和传感器网络。这些类型通常相互差别很大但智能城市服务整合在一起。基于复杂的整合方法,我们认为,一个新的挑战,片段代表一个完整数据的复杂性有合适但断断续续的模式,很难查询,被忽略的城市数据管理技术发展水平。使用预定义的和僵化的模式,比较零碎的模式意味着数据集包含数以百万计的属性,但非正交分布在表,当然,这些属性的值更大。作为一个查询而言,定位这些属性在哪里存储第一个遇到的问题,而传统的基于价值的查询优化没有贡献。为了解决这个问题,我们建议上大规模索引属性作为attributes-oriented优化,即属性索引。属性指数是一个次要目标属性的索引查找文件存储。它包含三个部分:ATree搜索键,DTree定位键之间的文件,和ADLinks ATree和DTree之间的映射表。本文指标体系结构、逻辑结构和算法,实现细节,创建过程中,集成到现有的键值存储,和城市应用程序场景。 Experiments show that, in comparison withB+树、LSM-Tree和avl树,查询时间ATree 1.1倍,1.5倍,分别快1.2倍。最后,我们将我们与HBase的命题,即UrbanBase的查询性能比原HBase快1.3倍。

1。介绍

城市大数据是大量的动态和静态数据生成的主题和对象包括各种城市设施,组织和个人。随着移动互联网的不断发展和成熟和大数据技术,城市数据的类型和规模有显著增加1]。使用数据分析城市数据创建有价值的信息和数字增强服务也成为近年来关注的焦点(2,3,4]。城市数据来源通常分为三种类型之一:官员,社会,和感觉的。城市官方数据指的是政府和企业的数据,如人口基本公共数据、交通、土地、住房、和地理;公共管理事务的数据,税收和收入,支付,和登记;和保密微数据对个人就业、医疗、福利和教育。社会城市数据参考数据生成的城市居民在日常生活中,如社交媒体的使用记录和全球定位系统(GPS)数据生成的用户活动。知觉的数据参考传感器数据在城市基础设施和移动物体,比如历史和实时数据记录传感器系统的环境、水、交通、气体和建筑,以及监控摄像头拍摄的图片和视频。城市数据由这三个来源多样,规模大、覆盖城市生产和生活的各个方面5]。

作为官方、社会和感觉的城市数据通常是非常不同的数据类型在每一个他们也非常复杂,城市的数据往往是分散和混乱6]。因此,从大数据管理的角度,原始的城市数据是巨大的、分布式的、异构的和不一致的。根据智能城市服务的需要,城市需要合并来自不同数据源的数据存储,检索和分析(7]。在这方面,最新的城市数据管理研究提出了许多具体的集成方法和架构城市数据(8,9,10]。与复杂的数据预处理方法,如数据清洗和集成、分散和混乱的城市数据合并到分布式和none-relational数据存储,如NoSQL数据库。然而,我们认为,城市数据库包含微小和大规模属性之间的非正交分布表,查询效率的,这种特性带来了新的挑战。共同的数据库,有相对少量的属性,这些属性分为几个表。然而,一个城市的数据库有大量不同的属性,有两个原因:首先,它存储质量物体,这些官员,社会,和知觉的对象都有不同的属性;第二,可能代表不同的语义一致的属性。例如,有850万多人,110大学,平均每天500000出租车旅行在纽约(11]。每天产生的数据量非常巨大,涉及许多完全不同的领域,包括大量不同的属性。首先,属性视为值的模式,然后,本文的模式意味着数据库包含数以百万计的属性,但非正交分布在表。其次,数据库查询依赖的模式,然后,断断续续的模式会带来新的城市数据库查询的复杂性,命名为片段的复杂性。

在计算机科学中,零碎的用于描述大,小,和断开连接的部分。摘要断断续续的模式包含两个含义:第一,有一个none-predefined和灵活的模式,满足的NoSQL数据库;其次,有大量的属性,它是通过城市的数据。断断续续的模式是由数据整合过程的原因很多,如地理多样性,“语义多样性,和格式“多样性”。所有的多样性都表示为数据整合后的零碎的模式。因此,巩固官员、社会和感觉的城市数据到NoSQL数据库导致碎片复杂性,代表一个完整的数据有一个适当的但是零碎的模式,难以查询。有许多复杂数据库查询的研究;例如,查询的复杂性是关于查询算法的特点,复杂性和存储数据的功能。在这篇文章中,片段是关于复杂性的特征模式。已知的查询优化,如索引值或分区值不能解决片段的复杂性,因为查询属性应该首先执行。 Such complexity is ignored in the state-of-the-art urban data management. An urban database with a fragmentary schema has two weaknesses.(1)给定一个属性和一个值范围内,没有任何机制来支持从大量属性检索属性。一个属性指数促进查询是必要的。(2)由于大量的属性,没有一个结构可以索引所有属性;因此,属性索引应该分发和管理。二次指数本地索引是必要的。

如图1,本研究旨在解决官员的片段的复杂性,社会和感觉的城市数据通过面向属性索引。我们建议上大规模索引属性作为attributes-oriented优化,即属性索引。属性指数是一个次要目标属性的索引查找文件存储。本文指标体系结构、逻辑结构和算法,实现细节,创建过程中,集成到现有的键值存储,和城市应用程序场景。我们还整合HBase命名为UrbanBase属性索引,用于存储城市数据,并比较它与原来的查询性能。此外,实验结果表明,该指数是更有效的比B+树、树LSM和avl树的查询性能和存储成本。

剩下的纸是组织如下。部分2介绍了相关的工作。部分3介绍了指数体系结构作为我们的解决方案的总体描述。部分4给出了属性索引的结构和算法的详细信息。部分5讨论了实现数组作为内存结构等问题,系统集成,加速分析。节6我们评估和比较几种索引的性能,分别显示在HBase关键指标的应用结果。最后,总结了结论和未来的工作部分7。

2。相关的工作

在先前的研究在智能城市,许多具体的解决方案提出了解决城市数据的存储和分析。程等人介绍了一个名为CiDAP的城市数据和分析平台(12]。在CiDAP, couchDB是用于存储传感器生成的json格式的数据,和所有的非结构化数据都保存为文件到HDFS。然而,完整的城市数据不仅包括一些特定的格式也多种多样。我们设置一个合适的存储平台为每个格式的数据,然后,那些无法轻易集成应用于城市来自多个数据源的数据。马可等人提出了一个模型称为冰冻饮料,它使用空间,时间,内容,和源代表事件和使用网格和框架来统一的粒度空间和时间(13]。但是,完整的城市数据包括的不仅仅是时空数据。同时,在建模的过程中均匀粒度的数据,一些详细的信息就会丢失。为了解决城市数据片段的复杂性,需要构建一个新的数据模型。

许多研究在索引中可以找到相关的数据库,提出了很多经典指标,如密度指数、稀疏索引,多级指数结合密度指数、稀疏索引,和B -树,以及B⁺树,和高效的哈希索引。然而,据我们所知,没有研究索引属性,但所有的价值观。因为属性和值之间的关系类似于键-值模型,我们研究一些研究索引的键值存储。

马等人最近提出了一个可伸缩的内存中的键值存储利用索引结合一个HashTable指数和SkipList指数、支持范围查询和查询点(14]。他们建造了内存中的关键空间索引的一个散列表,然后,并行访问和请求调度的键分区。在我们的属性索引和散列表的解决方案是不可行的,因为所有数据已分区索引是建立前磁盘上的数据文件。张等人提出了一个内存中的SkipList索引键值存储的(15]。索引值,有两层:上层是一个树形结构,底层是SkipList。在我们的方案中,属性指数还包含顶层ATree DTree底层。高等人提出了一个可伸缩的多维索引(MD-Index)键值存储(16]。在磁盘上的一个索引键值对的钥匙在哪里建模为维度。在查询过程中,查询键减少维度的多维模型。的弱点MD-Index键必须是建模为维度,而是一个多维数据集不适合大规模的钥匙。Spkv也是一个类似的研究在多维指数(17]。大好提出了分区方法价值指数在正常操作和维护一致性(18]。我们的解决方案是通过索引分区。也就是说,每个数据节点包含一个属性索引。然而,一致性并不是一个问题,我们的解决方案,因为一个属性指数仅为属性在自己的服务器上,这是一个自然并行索引分区数据显示位置。

当我们采用HBase作为主机系统,我们也回顾研究二级索引HBase和相似。在基于表格的索引方法,二级索引是一个特殊的系统表,而在一个托管内存二级索引方法,二级索引条目存储在相同的节点对应的基表记录。因此,每个节点负责维护部分的二次指数(19]。ITHBase [20.)开发的一个开源实现修改基地HBase源代码,包括事务和二级索引支持。它是一个基于索引的解决方案。IHBase [21)是一个内存中的二级索引HBase的解决方案。它是一个内存托管的索引方案。他们建造了基于索引键的索引表。索引表中的键值对从原始数据中检索集。当执行查询时,索引访问表首先,然后匹配所在的数据索引表和索引键之间的映射。二级索引对查询性能只要索引键被包含在查询条件(22]。

属性指数上大规模索引属性,与托管二级索引的方法。方法是选择几个注意事项。首先,我们专注于内存中索引,索引驻留在内存中。第二,相同属性的值将被存储在任何数据节点,也就是说,属性节点和自然分区节点之间的传播;因此,托管的方法比基于表格的方便方法。此外,二次指数的共同弱点是所有数据不能被索引或有太多的本地索引维护。然而,这个弱点属性指数并不明显,因为查询值可以通过传统的指数而属性索引索引只过滤数据文件不包含查询属性;同时,索引是完全共享和数据节点的属性维护自己的索引。两级索引框架包含了一个本地索引和全局索引(23]。本地索引维护每个节点上的信息,而全球指数由一些选择本地索引,以节省存储空间,提高查询效率。属性指数是一个本地索引属性和属性的挑战指数是定义一个高效的查询和存储结构。

3所示。指标体系结构

有各种各样的数据类型在城市的数据。例如,企业的产品销售记录是结构化数据;传感器在空气监测站生成半结构式的JSON格式的数据;居民在社会媒体上发布的照片非结构化数据。我们建立一个统一的属性值为所有类型的城市数据的数据模型。在结构化数据,列名称被视为属性,和所有的值被认为是每一列值集。在半结构式数据,标签被视为属性,和相应的每个标签的价值被认为是属性的值。在非结构化数据,每个数据被认为是属性的描述,和数据本身被视为价值。例如,在一个由用户上传的图片,图片的名称和文件属性文件被视为属性,和照片本身和文件属性值被认为是值。通过上述方法,我们总结了复杂的城市数据到一个统一的属性-值模型,这城市的数据可以存储在相同的NoSQL数据库的数据查询和分析。构建属性值的过程模型如图2。

基于属性-值模型,我们定义一个索引在许多属性,如下所示。

定义1。索引属性。属性索引是建立在属性而不是价值,这是一个树形结构索引大量属性,即文字。一个属性索引查询属性映射到存储的数据文件属性。一个属性的索引是一个次要索引NoSQL数据库。这是居住在每个数据节点有三个子结构的记忆:(1)ATree: ATree是一个树结构,将一个属性映射到身份,命名为援助(2)DTree: DTree反向树结构,通过遍历生成数据文件的URL从其身份,命名为支撑材和叶节点表示为根(3)ADLinks: ADLinks艾滋病的链接,作为ATree的叶子,fid检测器,DTree的叶子一个属性树的应用场景是一个数据库存储城市数据的属性值模型。数据库的属性和值都是巨大的,和属性值存储在多个数据节点的数据文件。如果一个全球属性索引是建立在这些文件中,属性指数也是巨大的规模,不得储存在主节点的记忆。此外,分布式索引带来额外成本管理和查询;例如,查询索引节点之间的处理。因此,在这篇文章中,属性指数的数据节点,也就是说,一个属性索引的属性是一个数据节点,并放置在数据节点,在本地维护和查询。
当一个查询被提交到数据库,它包含两个属性和值,例如,“选择一个和b对于数据集c之间的是最小值和马克斯在查询”。一个,b,c属性,而最小值和马克斯;显然,搜索范围是包含属性数据文件一个,b,c。属性指数是每个数据节点共享,查询引擎将查询发送到每个数据节点,节点,首先,ATree艾滋病(包括搜索和匹配一个,b和c)检索,数据文件的路径包含这些援助是通过查询检索DTree支撑材,艾滋病在ADLinks联系在一起的。最后,查询引擎扫描这些文件和查找记录的属性c之间的是最小值和马克斯。属性指数的总体架构如图3。
属性索引价值指数一起工作。首先,属性指数是一个本地索引;因此,它输出文件的路径,命名为属性范围包含查询属性。如果该值指数也输出文件的路径,称为价值范围包含索引的查询值属性。然后,扫描文件,命名为扫描范围,十字路口的属性范围和价值范围。如果值索引是建立在每个数据行级索引文件,仅在属性上的索引文件搜索范围。如果没有值索引、数据文件的属性扫描范围。

4所示。属性指标和算法

对索引n属性,至少,日志₂(n)信息必须区分n不同的属性,然后,一个属性指标的需求,至少,n日志₂(n)一些空间n属性的理论。因此,索引空间开销只取决于数量的属性,但不是属性的长度。我们可以估计的数量属性的数据集和计算ATree的大小。在大数据环境中,如果指数的大小超过内存容量,我们共享数据集,在每个子集建立索引,原因n=n₁+n₂,n₁ 日志(n₁)+n₂ 日志(n₂)< (n₁+n₂)日志(n₁+n₂)。然而,共享方法不适用于属性索引,因为属性存储的值,不能共享。然后,为每个数据节点,可能驻留在各种属性。自一个ATree索引数以百万计的属性节点,每个节点空间索引结构是必需的,以确保它适合内存大小。基于树的索引的代表,如B+树、LSM-Tree和avl树,大内存开销。假设基于树的平均长度属性,索引必须在内存中存储所有属性,和存储复杂度是O (kn),而查询时间复杂度是O (k日志₂(n))。比较典型的树形结构指数,ATree的设计目标是尽量减少索引的存储成本,提高查询性能。

作为Trie-tree ATree设计用于存储属性。属性的字符序列。通常情况下,一个字不包含太多的字符,这有利于搜索的复杂性相关的长度属性的数量,而不是属性。不像一个二叉搜索树,没有节点ATree商店与该节点相关联的属性。相反,它在树中的位置定义了属性和它关联。所有节点的后代有一个共同的前缀与该节点相关的序列,和根与空序列。在树中,找到一个序列的时间不依赖于树的节点的数量,而是序列的长度。举个例子,如果一组属性是“池”“奖”,“预览”,“准备”,“生产”和“进步”,快照可以构建如图4。找到一个属性的时间复杂度Trie-tree是由单词查找树的深度而不是属性的数量,和单词查找树的深度是由长度属性。通过分析,的时间复杂性和空间复杂性Trie-tree是O (k)和O (kn),分别。

ATree的逻辑结构是由Trie-tree启发。Trie-tree,根节点不包含数据,和所有其他的节点包含一个字符。从根节点到某一节点,遍历所有的节点连接的特点,相应的记录。孩子的每个节点包含不同的数据,按照一定的顺序排列。所有节点的后代有一个常见的前缀与节点相关联的序列。如果一个节点在一个Trie-tree只有一个none-leaf子节点,那么两个节点被压缩成一个。由这个方法,一些常见的英语前缀和后缀,如“前”,“,”和“ing”可以被压缩。此外,数据集的属性也可能包含多个词,如“物体色”和“对象大小”,然后,上述压缩方法可以进一步减少ATree的大小。压缩节省空间,减少了遍历深度,降低时间复杂度。然而,当一个新属性,介绍了节点ATree更新; thus, the compression method is reversible. Figures5 (b)和5 (c)显示ATree的压缩。

在ATree,一方面,叶节点,作为最后一个节点的属性,是ADLinks的根节点和DTree映射到相应的叶节点;另一方面,如果nonleaf节点没有ADLinks和DTree链接,然后他们内部节点的空间浪费。充分利用节点的ATree,我们引入一个通配符” 。“对于所有节点除了根,通配符”“添加到节点值。它表明,一个节点匹配字符串的条件节点值是字符串的后缀。然而,当检索属性ATree,自顶向下遍历是停在匹配节点的孩子节点都是无与伦比的。例如,当叶子节点一个={前}是节点的子节点b={不相上下}、节点b查询时将被选中“准备”和“准备”,和节点一个查询时将被选择“预览”和“传”。的优势引入通配符是ATree空间的复杂性从O(减少kn)O (n)。同时,ATree可以支持添加新的属性无需修改结构。然而,这是有代价的undistinguishing none-existing属性。幸运的是,一般的数据查询条件近似的价值,而不是属性。例如,查询是没有意义的,如果查询属性是模糊的。此外,该属性索引最终将返回数据文件包含的查询引擎,不仅包含这些属性;因此,模糊匹配属性不会影响最终的查询效率和正确性。图5 (d)显示了ATree的通配符。

在属性值存储属性可以包含任何字符。除了常见的数字和英文字母,希腊字符、汉字,日本平假名,和其他语言字符可能出现在属性。很难直接索引属性的基础上,包含各种各样的角色。因此,有必要使用一个方法来统一字符和促进排序和搜索,从而建立索引的属性。在ATree属性存储和检索在十六进制的utf - 8编码。基本存储单元是一个或多个编码。utf - 8是一种最广泛使用的Unicode实现在互联网上和变长编码而闻名。一般来说,属性不包含太多的人物和主要由字母和数字,这样获得的utf - 8编码的转换不会太长了。与直接在不同的角色设置Trie-tree相比,使用utf - 8编码不仅稍微延长编码的大小,还允许特殊字符与数字或字母有一个共同的前缀。这种编码方法充分利用Trie-tree的特点,不仅可以节省存储空间,还可以减少空间的复杂性。

ATree搜索算法算法所示1。算法遍历的概念属性的utf - 8编码和比较它与ATree中的节点到节点的路径完全匹配的编码是最后选择;否则,它选择通配符的最长公共前缀节点如果所有节点不匹配。算法”,Y“是属性查询”,在“生成的ATree,”节点“是在当前ATree节点,“codeInquire“是相匹配的字符段ATree每一步。首先,Y转换为utf - 8编码吗codeY、循环通过每个字符的编码codeInquire更新;如果当前节点的子节点匹配codeInquire,节点子节点和重置codeTemp寻找下一层。否则,在当前没有匹配的节点codeInquire,然后,codeInquire继续更新并再次搜索。循环结束后,如果匹配失败,选择节点的通配符查询结果。

图6是该指数的一个例子。ATree,每个节点为一个或多个十六进制数字,代表一个或多个字符的utf - 8编码属性,包括“税收、任务、标签、文本、团队和电话”,将它们转换为utf - 8编码,构造ATree。建设步骤如图6(一)和6(b), DTree图6(d)是一个简单的目录树结构。每个父节点存储一级目录信息,和叶节点存储文件名称。ATree相似,所有节点的后代有一个常见的前缀与节点相关联的序列,但不同之处在于,ATree遍历从根到叶,虽然DTree遍历从叶到根获得完整的文件路径。一般来说,有很多的文件存储系统存储城市数据,但一些这些文件的父目录。如果所有文件的绝对路径是完全记录,所以作为他们的父目录,因此浪费存储空间。

图6(c)显示了节点的例子的ADLinks指针ATree DTree的叶子。因为一个属性可能存储在多个文件和一个文件也可以拥有多个属性,之间存在多对多关系DTree ATree节点和叶节点。一般来说,大规模稀疏属性和满足Zipf地理分布:少量的高频和大量的低频属性。因此,ADLinks DTree部分中,我们添加了叶子节点“所有”。当一个特定的属性是一个高频属性(例如,超过70%的数据文件包含一个属性),它直接指向的节点,这意味着属性查询返回所有数据文件在服务器上。此外,尽管每个文件包含大量属性,每个属性对应于一个小数量的文件,并确保存储和查询的效率。

5。实现

在本节中,索引属性的实现问题进行了讨论,包括它的数据结构和创建;此外,它是如何集成到典型的NoSQL存储和为什么它可以提高查询性能进行了讨论。

5.1。数组的索引属性

ATree Trie-tree压缩。最简单的实现是构建一个multitree,每个节点存储一组其所有子节点。基于大量的数据,这种结构占用的空间会特别巨大。因此,ATree被实现为一个“双阵列的方法。”It greatly reduces the space cost by using only two arrays, namely,“基地”和“检查”来存储数据。的基地数组是负责记录状态,检查数组负责检查每个字符串是否相同的状态转换。假设两个字符一个和b都是性格的继任者t,一个。代码代表字符的编码值一个,一个。指数代表字符的索引位置一个在数组中。的值基地数组和检查阵列满足下列条件:基地(t.index)+一个。代码=一个。指数基地(t.index)+b。代码=b。指数检查(一个。指数]=检查(b。指数]=t。指数

的节点t有后续节点时基地(t。指数)> 0;否则,节点t没有后续节点什么时候基地(t。指数< 0。让一个的后续节点t当两个基地(t。指数)+一个。代码=一个。指数和检查(一个。指数]=t。指数是真的。

我们选择一个ATree图的一部分6每个节点和马克,然后,图7描述了节点之间的关系①,②,③双数组表示。查询算法,算法1,实现双数组遍历查询属性和utf - 8代码转换,然后,确定每个查询节点可以对应于ATree反过来。“findNext“函数算法1显示下一个查询节点是否能对应ATree的后续节点。让输入查询节点u和前面的节点匹配ATreep;然后,u。指数=基地(p)+u。代码。返回的节点u存在于ATree如果检查(u。指数)=p。指数;否则,节点u没有一个完整的ATree匹配;因此,p返回,然后,u增长了一点下一个循环。最后,属性的遍历完成后,先前的通配符匹配节点选为查询结果最后如果没有完全匹配的节点。通配符设置为一个特殊的子节点的节点,它是用来匹配任何价值除了子节点的值。

我们采用两个数组”找到”和“的名字”实现DTree。的找到数组类型的整数并存储节点的父节点的索引。的的名字数组类型的字符串并存储节点的目录名或文件名。我们采用以下步骤来建立一个DTree。首先,我们确定数据库文件的范围,使用广度优先搜索遍历文件范围下,遍历的结果。然后,我们填补序列的结果的名字数组的顺序从根目录文件。同时,每个节点的父的指数是进入找到数组中。当一个文件路径查找而言,索引x检索特定文件的的价值找到(x确定),然后,的名字(找到(x]]结合的名字(x形成部分路径。这个过程是迭代,直至达到系统根目录,并检索完整的绝对路径。DTree如图6(d),两个数组表所示1构建。任何完整的绝对路径,如“/地方/数据1/ c。db“指数在表51可以检索。

ATree和DTree都是由数组实现,这样两个文件属性和数组索引。因此,在ADLinks,各自代表属性和索引文件。一般来说,有许多属性和文件。然而,每个属性对应的文件数量相对较小。会很稀疏,如果一个二维矩阵来表示的关系。因此,ADLinks用稀疏矩阵,也就是说,一个数组存储索引的属性,称为“属性指标,”和其他商店的索引文件,称为“文件索引。“ADLinks查询第一检索索引xATree目标属性的,其次检索索引我的值等于x属性指标数组中,然后,所有文件索引的值(我)相应的索引文件。通配符的节点而言,它将作为一种特殊的子节点和表示为节点的数组属性指标的负值。例如,如果属性“团队”的值为2的属性索引数组,它的通配符价值是−2。

在图6(c),索引值的“文本”,“团队”和“电话。”在一个n在ree is set to be 1, 2, and 3 in the ADLinks, respectively. Then, according to Table1建立了两个数组,如表所示2。其中,表的最后一列代表的通配符属性“团队”。让查询属性”电话。”和the index retrieved by the ATree be 3. In the Attribute-index array of ADLinks, the values of Attribute-index [3和属性指标4)= 3;因此,文件索引的值(3和文件索引4)的值对应的索引文件。根据表1对应的文件的绝对路径属性”电话。“是”/地方/ data1 / c。db”和“/local/data2/1.db”, respectively.

5.2。创建

总体步骤构建一个属性索引图所示8并解释如下:首先,ATree的基地和检查数组,找到和名称数组DTree, ADLinks属性指标和文件索引数组的初始化。第二,本地数据库文件检索的范围,遍历所有城市的数据文件,和找到的名称数组DTree更新过程中遍历,直到DTree完全建立。第三,DTree遍历,索引值的每个文件,读取文件中的所有属性,每个属性转化为utf - 8编码,它被添加到ATree先后。第四,所有属性的索引值ATree和相应文件的索引值DTree存储到数组属性指标和ADLinks文件索引数组,分别。在四个步骤中,ATree建筑是最复杂的步骤,包括插入、压缩和转换步骤。

在插入步骤中,multitree结构是建立ATree暂时。一个节点存储包含它的所有子节点列表对象本身的编码值和相应文件的索引列表在DTree如果节点是一个属性的终结。然后,这个初始化multitree Trie-tree形式的所有属性和管理。一个节点只存储一个比特的编码值。遍历的算法,utf - 8编码的属性,并将其插入到multitree反过来,算法所示2。遍历完成后,文件索引对应属性的值被添加到节点信息。在算法2,Y属性是插入,fileIndex是一个列表,它存储文件与属性相对应的索引值,在生成的multitree,节点在当前multitree节点。

在压缩步骤中,multitree与深度优先搜索遍历的方法。如果一个节点没有存储文件索引值和只有一个子节点,该节点及其子节点被压缩成一个节点,和两个节点的编码值拼接节点的编码值压缩。

在转换步骤,multitree转换以双数组ATree形式;与此同时,ADLinks由以下五个步骤:(1)基地[0]= 1初始化;中所有的值检查数组是0。(2)假设一个节点p在multitree ATree,群子节点 ,…, 。一个正整数开始发现和检查(开始+ .code… .code)= 0;也就是说,n可以找到免费的空间来存储这些子节点。(3)然后,检查这群子节点数组设置检查(开始+ .code… .code]=p.index,基地他们的父节点设置为数组值基地(p.index]=开始。(4)的节点存储文件索引值,ATree及其文件的索引值存储在索引值属性指标数组和文件索引分别ADLinks数组。(5)对于每个子节点,如果没有自己的子节点,它的价值基地数组是让为负;否则,它的所有子节点插入和迭代步骤(2)。

通配符是而言,它在索引更新处理,但不是在创建索引。通过这种方法,模糊匹配的新添加的属性可以无需修改ATree实现。当有一个新属性添加到属性指数,首先,DTree更新和相应的检索DTree索引值。后来,有三种可能的过程。(1)如果ATree包含新属性,然后ATree检索索引值的属性,结合新DTree索引值来更新ADLinks;(2)如果ATree不包含新的属性,它将被添加到通配符的最长公共前缀节点,只有ADLinks将被更新,而ATree保持不变;和(3)如果通配符ATree超过限制,整个索引重建性能的原因。

5.3。集成和城市应用程序

我们以HBase为例来描述属性索引和数据库的集成。HBase是一个高度可靠、高性能、用于可伸缩的分布式数据库,HDFS文件系统上运行。它使用rowkeys、列家庭,列限定符,和时间戳作为键,数据存储的内容作为值的键-值对。HBase使用主从结构,在这种结构中,许多HRegionServers HMaster管理数据是居住的地方。HBase数据文件数据分布在不同的节点在HDFS文件系统。它的基本文件单元叫做StoreFile,存储在HDFS HFile格式。

对于每个HRegionServer,一个属性索引构建和居住在基于本地文件服务器的内存。服务器的创建过程遵循前面描述的。服务器上的所有HFiles迭代。HFiles由许多部分组成的物理结构。其中,只有DataBlock存储用户的键值数据,进行扫描。每个键值数据由四部分组成:关键的长度,长度值,键和值。关键部分是一个复杂的结构,包括rowkey的长度,rowkey的内容,列族的长度,列族的内容,列的内容限定符、时间戳、和keyType,其中列限定符的元素属性索引。属性指数的构建过程,包括ATree DTree ADLinks,是相同的所有HRegionSevers和执行MapReduce的地图任务并行模式。

HBase提交一个查询时,例如,查询问是扫描”人”,{过滤器= >“QualifierFilter(“名字”)和SingleColumnValueExcludeFilter(“信息”、“年龄”、>、二进制:28)”}。

查询问是找到的名字一个人在桌子上人谁的年龄大于28。HBase客户机首先定位地区在桌子上人是居住在RegionServer,hbase:元表,动物园管理员。不失一般性的,假设一个地区1,一个2RegionServer一,也地区B1,B2RegionServer B是匹配的。一个地区包含一个内存memstore和磁盘storefiles这是HFiles存储在HDFS中。然后,如果有二级索引的列年龄映射的值年龄行属性,地区B2,一些storefiles在地区一个1,一个2,B1过滤的查询条件“年龄> 28”。因此,扫描范围是缩小首先通过索引值。接下来,在两个属性索引RegionServer一和B之前操作storefiles在一个地区1,一个2,B1扫描。通过查询属性索引,只退还storefiles在每一个RegionServer并行扫描。总之,属性指数进一步缩小扫描范围不包括storefiles不包含属性的名字或年龄。本文中描述的查询过程如图9。

HBase的应用场景和一个属性指数也清楚。城市来自不同数据源的数据通常有大量的非正交分布的属性。有许多类型的属性,但大多数属性只存在于一些来源的数据。属性事务量存在于事务的记录存储和购买企业列表,而属性存在于一些天气温度传感器。如果城市所产生的所有数据源的数据存储在一起,属性将是巨大的。SmartSantander就是一个很好的例子,一个世界上最大的智能城市实验台。这个实验已经部署在桑坦德的城市,位于西班牙北部。SmartSantander基础设施包括一个持续发展的物联网设置遍布城市,目前包含10000多个不同的物联网设备(固定和移动传感器节点,近场通讯(NFC)标签,网关设备,智能手机和公民)[24]。风速计是一种物联网设备在SmartSantander,和数据文件,其中包含实时风速,风速计的独特属性,只占一小部分的整体数据文件。如果这些数据集存储在HBase、城市的数据可以存储在表单属性列限定符和属性的值的值。在这种情况下,属性查询索引可以大大加快。

6。实验

在本节中,属性索引的性能及其集成在HBase评估和比较。在6.1节中,我们描述的基础实验,包括实验目的和实验计划。

6.1。设置

但是。范围

我们比较属性指数的核心组件,ATree,在一个独立的环境中现有索引。我们整合ATree HBase,即UrbanBase,比较其查询性能与原始HBase。

6.1.2。实验环境

我们执行一个集群实验6物理机器。每个节点有相同的配置,即。,Intel Core i7, 1 TB hard disk, 8 GB memories, CentOS 7, and moderate I/O performance. The Gigabit Ethernet is connected by the Dell PowerConnect 5548.

6.1.3。选择竞争对手

我们比较ATree和B⁺avl树树,LSM-Tree指数的替换属性索引。在B⁺树,根代表整个范围的值树,每个内部节点是子区间[25];LSM-Tree,搜索树,保持属性-值对的两个或两个以上的独立结构,其中每个优化各自的底层存储介质[26];有效地两个结构之间的数据同步,在批次。AVL树是一种自平衡的二叉查找树。任何节点的两个子树的高度不同,最多一个。因为大多数指标治疗支持磁盘存储,没有失去公平,我们放弃,把所有的数据放在内存磁盘操作。我们甚至注意到四个指标是设计用于不同的目的在他们的应用程序场景中,他们采用了维护和查询大量的属性,表示为短字符串,在这个实验。此外,UrbanBase当然,相比之下,HBase评估优化效果。

6.1.4。断断续续的模式

断断续续的模式在实验中由两种方法:第一,是巨大的和随机的字符串的属性;第二,属性之间的非正交分布表,表的每一行包含稀疏的半空属性。

6.1.5。实验数据

索引的数据集实验包含大量的随机字符串作为属性。在生成数据,随机选择的属性包含8个字符从95个不同的字符(ASCII代码32到126年,键盘字符),和属性设置包含50 k, 100 k, 200 k, 400 k, 800 k的字符串。HBase的数据集和UrbanBase属性值数据集。我们准备一个词集NLTK自由在Python中包括10000个英语单词。我们提取五个词集的子集与不同尺度,即。,1000, 2000, 4000, 6000, and 8000 words, and set them to be the candidates of attributes. For generating an attribute-value pair, the attribute is selected from the candidate set, and the value of an attribute is random strings whose length, together with its attribute, is 100 byte. By this approach, we could generate a 50 GB dataset which contains about 5 10⁸记录和控制他们的独特属性是五个尺度。因此,五个数据集在HBase和UrbanBase实验都是50 GB,但它包含了1000年,2000年,4000年,6000年和8000年不同的属性,分别。

6.1.6。实验的情况下

对于指数的实验,测试用例包括建筑、查询和添加和存储四个指标。实验UrbanBase,查询子句节中的示例相同5.3和图9。

6.2。结果

对于比较ATree, B⁺树、LSM-Tree和avl树在三个操作,建筑,查询,添加,标准时间消费和存储消耗。总的来说,B的构建时间⁺树和avl树平均1.23倍和1.89倍的时间比ATree,分别。LSM-Tree和avl树的查询时间平均1.11 x 1.5 x 1.2 x长于ATree,分别。B的存储⁺树、LSM-Tree和avl树是平均1.21倍和1.61倍大于ATree,分别。结果如图所示10。

图10(一个)显示结果如下:(我)当数据量增加时,avl树的建立时间较长,增加的速度比其他索引。建设时间和数据量几乎是除了avl树的线性相关性。(2)LSM-Tree HBase、快速插入数据的优化,新数据暂时存储在内存和合并文件。即使在我们的实验中,数据并不是真正的合并到磁盘,但留在内存中,并创建LSM-Tree是非常有效的。(3)有太多的I / O操作创建一个更高的avl树由于旋转操作即使这些内存中执行I / O操作在我们的实验。这就是为什么avl树最糟糕的建筑性能。(iv)ATree的建筑时间小于B⁺树因为ATree较小的节点,ATree也低于B+树。

图10(b)显示结果如下:(我)ATree的查询性能最好,而LSM-Tree最差的一个。遵守时间复杂度,结果和level-wise LSM-Tree不适合属性查询的查询机制。(2)avl树的查询时间和LSM-Tree与数据量迅速增加,但其他两个索引的查询时间几乎是稳定的。(3)avl树,查询遭受高于I / O操作B+树和ATree。(iv)由于结构简单,ATree比B更好的查询性能⁺树。(v)的附加时间四个指标,如图所示10(c),遵循相同的规律的创建时间。另外,图10(d)显示结果如下:(vi)当数据量增加时,avl树的存储更大,增加的速度比其他索引。同时,他们几乎是线性相关的。(七)B⁺树比ATree需要的存储空间更少,但是他们也很近,因为ATree采用压缩减少存储节点。然而,对于比较,通配符是残疾,也在实践中,需要与ADLinks和DTree ATree的存储未被计入。直观地说,存储为一个完整的属性指数翻了一番。(八)比ATree LSM-Tree需要更大的存储和B⁺树因为它的压实机理和读和写放大问题。

我们比较的查询性能和存储消耗HBase和UrbanBase相同的查询情况和运行时环境。实验结果如图所示11。通常,查询时间是由不同属性的数据量而不是数量的查询性能HBase和UrbanBase都是稳定的。总的来说,UrbanBase执行查询比HBase快1.3倍。几乎一半的数据文件中跳过扫描处理,因为属性指标区分文件不包含查询属性。除此之外,不同的属性的数量影响K-HBase属性索引的查询效率;然而,与查询成本数据集相比,这种影响可以忽略不计。

实验结果证明,与大规模分布式属性值存储属性,使用一个属性索引可以大大提高查询效率。UrbanBase, HBase综合属性指数显示,属性的自适应性指数也很好。在最初的HBase中,可以优化查询二级索引值,因为查询范围以外的跳过一些数据文件,而在我们的解决方案,数据文件也可以跳过的属性指标,因为它们不包含查询的属性。此外,属性索引和索引值都可以一起工作。此外,由于属性索引是建立在每个数据节点,它不影响分布式查询的并行性。此外,相对较短的长度属性,保持ATree的效率,ATree也是精心设计的存储成本,适合内存的大小。属性搜索属性的时间消耗指数远低于所保存的时间缩小扫描范围。

7所示。结论

城市大数据管理的应用,本文提出了一个属性-值模型来代表所有类型的。模型的基础上,我们提出的设计、实现和评价属性的索引,和面向属性优化方法提出了解决官员的片段复杂性社会和感觉的城市数据。属性索引被设计为一个二级索引不是价值观,但属性。它驻留在内存的数据节点,它区分数据文件不包含在并行查询属性管理器和,最后,加速查询跳过这些文件的扫描过程。我们提出了以下模型、算法和实现的属性指数:(1)属性指标的三个部分,即,ATree DTree, ADLinks,以及它们如何一起工作(2)的逻辑结构和算法ATree、DTree ADLinks,尤其是压缩,通配符,多语言支持,为ATree和复杂性分析(3)双数组实现、创造和属性的更新索引(4)选择HBase主机系统和解释如何将属性索引HBase和潜在的大规模城市数据的存储应用程序场景

实验结果表明,相比B+树、LSM-Tree和avl树,查询时间ATree 1.1倍,1.5倍,分别快1.2倍。此外,HBase综合属性指数,即UrbanBase的查询性能比原HBase快1.3倍。

在未来,属性指数可以进一步优化如下:更多调查属性提取根据属性分布,调整ATree根据属性的频率,和集成多个数据库的索引属性。

数据可用性

数据用于支持这项研究可以获得相应的作者的请求。

的利益冲突

作者宣称没有利益冲突。

确认

作者要感谢王Chengwen,毕业于软件学院,东北大学,获得了硕士学位。他导致了部分解决方案中提到的部分4。作者要感谢那些评论家的反馈在纸上。本文是研究拨款支持的中国国家自然科学基金(批准号61662057)和中央大学的基础研究基金(N182504017)。