目录
5.3 针对复杂空间对象(如:LineString、Polygon等)的时间+空间索引(XZ3)
5.4 针对复杂空间对象(如:LineString、Polygon等)的空间索引(XZ2)
1. GeoMesa索引简介
GeoMesa 索引的基本原理是将三维(经度、纬度、时间)的数据按照Z曲线进行降维,得到一维数据作为Key使用,方便在key-value数据库中进行查询。 实际的Key结构比简单的键值对更复杂。在Accumulo中GeoMesa索引的结构如图:
2. 索引类型
索引名称 | 索引解释 |
Z2 [ z2] | Z2索引使用二维Z阶曲线来索引点数据的纬度和经度。如果要素类型具有几何类型,则将创建此索引 Point。这用于有效地响应具有空间组件但没有时间组件的查询。 |
Z3 [ z3] | Z3索引使用三维Z阶曲线来索引点数据的纬度,经度和时间。如果要素类型具有几何类型Point且具有时间属性,则将创建此索引。这用于有效地回答具有空间和时间组件的查询。 |
XZ2 [ xz2] | XZ2索引使用XZ-ordering [1]的二维实现来索引非点数据的纬度和经度。XZ排序是Z-排序的扩展,设计用于空间扩展对象(即非点几何,如线串或多边形)。如果要素类型具有非Point几何图形,则将创建此索引。这用于有效地回答具有空间组件但没有时间组件的查询。 |
XZ3 [ xz3] | XZ3索引使用XZ-ordering [1]的三维实现来索引非点数据的纬度,经度和时间。如果要素类型具有非Point几何并且具有时间属性,则将创建此索引。这用于有效地回答具有空间和时间组件的查询。 |
Record / ID [ id] | 记录索引使用功能ID作为主键。它用于ID的任何查询。此外,某些属性查询可能最终从记录索引中检索数据。 |
Attribute [ attr] | 属性索引使用属性值作为主索引键。这允许在没有时空组件的情况下快速检索查询。属性索引包括辅助时空密钥,其可以改进具有多个谓词的查询。 |
3. 传统空间索引方式
GeoMesa的数据存储使用 key-value数据库。key-value数据库是一种NoSQL数据库,其数据按照键值对的形式进行组织、索引和存储。 Accumulo,HBase和Google Cloud Bigtable对这些键进行排序,并可将它们存储在任意数量的节点(服务器)上。
当使用key-value数据库时,Key的良好设计可以使应用程序更高效的运行。与关系数据库不同的是,key-value数据库中会频繁的使用key进行查询。例如在订单数据库中,会以订单号作为key进行存储,当用户查询订单的时候,即可用通过订单号直接查询到订单数据并返回该条数据。Accumulo,HBase和Cloud Bigtable都是使用类似的机制进行工作,GeoMesa同样也是使用该机制来进行数据组织。GeoMesa根据时空数据的特点,实现了生成包含时空信息的Key的算法,算法的基本思想如图:
图中的红线被称为空间填充曲线,又称为Z曲线。该线顺序访问每个单元格一次,并且能够保证访问次序的唯一性。 Z曲线也能用于高分辨率地图,如图:
Z曲线上的每个点都可以赋予一个顺序值,通过这个顺序值,GeoMesa将经纬度表示为一个整数,这样就将二维数据降为一维数据,可以作为key-value数据库中的key使用。因为Z曲线支持多维数据,所以GeoMesa也支持将多维数据降为一维数据,作为key使用。
4. GeoMesa时空索引机制原理
如何对时间空间数据进行有效地编码,这是一个GIS研究工作者一直在研究的问题。只有让这些数据能够快速的被查询到,这样的体系才是有用的。而这个工作的关键在于query planner上了。
4.1 建立时空索引
在此处介绍的案例是基于accumulo data store(GeoMesa基本的一个data store)的。这个框架是一个分布式的键值对数据源。而在给时空数据建立索引的过程就是要将三维的数据进行降维处理,即让经度、维度、时间数据转化成为单一维度的数据。这个特定的降维过程就是被index-schema的格式所定义的。
下面的图片就展示了一个简单的利用空间填充曲线来进行降维的过程。在这个例子当中,index-schema的格式是10个比特,遵循的模式就是“YXTTYXTTYX”。在这个过程当中,三个维度都呈现在Z型曲线当中。这个编码方式就是GeoMesa当中默认的一种index-schema的编码格式。
在前面的两个条带就展示了逻辑顺序的存储过程和物理顺序的存储过程。
4.2 Query Planning
例如,我们需要进行一个查询,查询条件如下:
- -180 ≤ longitude < 45
- -90 ≤ latitude < 22.5
- 0 < time < 9 (on an arbitrary scale of 0 to 16 for this illustration)
这个对应的查询范围正好是三个维度的最低值。下图就可以展示出这些key对应的查询位置:
这个例子使用的是10 bit的编码格式,所以在立方体当中只有1024个查询结果。默认的GeoMesa index-schema利用了超过55 bit,而这样利用穷举来进行查询的效率会非常的低。不过幸运的是,Geohash在进行位置信息的编码时,对于String类型的字符串的存储是分层的,因此这样就可以大大的降低查询的资源开销。
5. HBase DataStore的rowKey设计
5.1 针对Point的时间+空间索引(Z3)
ShardKey(1 byte)+Epoch Week(2 bytes)+Z3(x,y,t)(8 bytes)+FeatureID
5.2 针对Point的空间索引(Z2)
ShardKey(1 byte)+Z2(x,y)(2 bytes)+FeatureID
5.3 针对复杂空间对象(如:LineString、Polygon等)的时间+空间索引(XZ3)
ShardKey(1 byte)+Epoch Week(2 bytes)+XZ3(minX, minY, maxX, maxY)(8 bytes)+FeatureID
5.4 针对复杂空间对象(如:LineString、Polygon等)的空间索引(XZ2)
ShardKey(1 byte)+XZ2(minX, minY, maxX, maxY)(8 bytes)+FeatureID
5.5 Attribute索引
IdxBytes(2 bytes)+ShardKey(1 byte)+AttrValue+SplitByte(1 byte)+SecondaryIndex(Z3/XZ3/Z2/XZ2)+FeatureID
5.6 ID索引
FeatureID