透过空间角度 理解GiST索引的构造

标签

PostgreSQL , GIS , PostGIS , Greenplum , 空间检索 , GiST , B-Tree , geohash


背景

可以支持空间检索的GiST索引的数据结果到底是什么样的呢?

本文为以下两篇文档的增补:

《Greenplum 空间(GIS)数据检索 B-Tree & GiST 索引实践 - 阿里云HybridDB for PostgreSQL最佳实践》

《PostGIS空间索引(GiST、BRIN、R-Tree)选择、优化 - 阿里云RDS PostgreSQL最佳实践》

GiST索引的构造

我们可以用空间的思想来理解它,比如我在这篇文档中讲解了为什么我们需要通过数据规整来提高geohash b-tree的检索效率。

《Greenplum 空间(GIS)数据检索 B-Tree & GiST 索引实践 - 阿里云HybridDB for PostgreSQL最佳实践》

因为这样可以让每个heap block的bound box(包含这个HEAP BLOCK中所有空间的最小BOX, 平面对象。如果是多维对象,使用多维对象的立体BOX或者多维BOX表示。)尽量的缩小,同时让不同heap block之间的边界更加的清晰,重叠少。从而提高空间数据检索的过滤性。

实际上GiST索引思想与之类似,只不过它不是通过编排HEAP BLOCK来实现这一的划清边界的,而是通过R-Tree结构来表示的。这一的话,用户在写入数据时,对应的空间对象写到哪个GiST索引分支就非常的明朗。(当然,GiST索引和其他索引一样,随着数据的写入会出现SPLIT的需求。)

GiST索引对写入性能的影响(时间越小越好)

postgres=# create unlogged table test_gist (pos geometry);
CREATE TABLE  

postgres=# create index idx_test_gist_1 on test_gist using gist (pos);
CREATE INDEX  

postgres=# insert into test_gist select st_setsrid(st_makepoint(random()*360-180, random()*180-90), 4326) from generate_series(1,5000000);
INSERT 0 5000000
Time: 67127.758 ms  

postgres=# drop index idx_test_gist_1 ;
DROP INDEX
Time: 1056.465 ms  

postgres=# create index idx_test_gist_1 on test_gist using gist (pos);
CREATE INDEX
Time: 58945.677 ms

B-Tree索引对写入的性能影响(时间越小越好)

postgres=# create unlogged table test_btree (pos geometry);
CREATE TABLE  

postgres=# create index idx_test_btree_1 on test_btree using btree(st_geohash(pos,11));
CREATE INDEX  

postgres=# insert into test_btree select st_setsrid(st_makepoint(random()*360-180, random()*180-90), 4326) from generate_series(1,5000000);
INSERT 0 5000000
Time: 30199.098 ms  

postgres=# drop index idx_test_btree_1 ;
DROP INDEX
Time: 50.565 ms  

postgres=# create index idx_test_btree_1 on test_btree using btree(st_geohash(pos,11));
CREATE INDEX
Time: 7746.942 ms

BRIN索引对写入性能的影响(时间越小越好)

postgres=# create unlogged table test_brin (pos geometry);
CREATE TABLE  

postgres=# create index idx_test_brin_1 on test_brin using brin(pos);
CREATE INDEX  

postgres=# insert into test_brin select st_setsrid(st_makepoint(random()*360-180, random()*180-90), 4326) from generate_series(1,5000000);
INSERT 0 5000000
Time: 7476.996 ms  

postgres=# drop index idx_test_brin_1 ;
DROP INDEX
Time: 1.604 ms  

postgres=# create index idx_test_brin_1 on test_brin using brin(pos);
CREATE INDEX
Time: 1697.741 ms

GiST实际上是一个通用的索引框架,支持多种数据类型

不仅仅空间类型,更多复杂的类型GiST或者SP-GiST索引也支持。

小结

GiST直接构建在空间列上,对性能影响最大。

Btree直接构建在空间列上,使用表达式(st_geohash)构建btree索引,对性能影响较小。

BRIN直接构建在空间列上,对性能影响最小。

参考

《Greenplum 空间(GIS)数据检索 B-Tree & GiST 索引实践 - 阿里云HybridDB for PostgreSQL最佳实践》

《PostGIS空间索引(GiST、BRIN、R-Tree)选择、优化 - 阿里云RDS PostgreSQL最佳实践》

Flexible Indexing with Postgres

时间: 2024-11-01 12:52:27

透过空间角度 理解GiST索引的构造的相关文章

Greenplum 空间(GIS)数据检索 B-Tree & GiST 索引实践 - 阿里云HybridDB for PostgreSQL最佳实践

标签 PostgreSQL , GIS , PostGIS , Greenplum , 空间检索 , GiST , B-Tree , geohash 背景 气象数据.地震数据.室内定位.室外定位.手机.车联网.还有我们最喜欢的"左划不喜欢.右划喜欢",越来越多的位置属性的数据.将来会越来越多. 基于GIS的数据分析.OLTP业务也越来越受到决策者的青睐,例如商场的选址决策,O2O的广告营销等.有很多基于多边形.时间.用户对象属性过滤的需求. 阿里云HybridDB for Postgr

JAVA装饰者模式(从现实生活角度理解代码原理)_java

装饰者模式可以动态地给一个对象添加一些额外的职责.就增加功能来说,Decorator模式相比生成子类更为灵活. 该模式的适用环境为: (1)在不影响其他对象的情况下,以动态.透明的方式给单个对象添加职责. (2)处理那些可以撤消的职责. (3)当不能采用生成子类的方法进行扩充时.一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长.另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类. 实现该模式的关键步骤: (1)Component(被装饰对象基类

从空间角度诠释安全体系架构:花瓶模型V3.0

["防护-监控-信任"体系:"五边界"."五控点"."三验证"] 入侵就是要意想不到,出现在你不注意的角度与方位:若你还没有看清楚入侵者是谁前就盲目动作,往往步步被动,被对手牵着走."用空间赢得时间"是安全设计的常用理念,空间换取的是你可以反应和准备的响应时间.在现实生活中这很容易理解,但在"虚拟的网络上",如何建立网络空间的概念,如何设计安全体系架构呢? 花瓶模型(V2.0)是从时间维

理解Lucene索引与搜索过程中的核心类

理解索引过程中的核心类 欢迎访问我的个人网站http://wuyudong.com/ 执行简单索引的时候需要用的类有 IndexWriter.Directory.Analyzer.Document.Field 1.IndexWriter IndexWriter写索引是索引过程的核心组件这个类负责创建新的索引或者打开已有的索引以及向索引中添加.删除或更新被索引文档的信息但不能读取或搜索索引.IndexWriter需要开辟一定的空间来存储索引该功能由Directory完成 2.Directory /

理解MySQL——索引与优化

写在前面:索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点.考虑如下情况,假设数据库中一个表有10^6条记录,DBMS的页面大小为4K,并存储100条记录.如果没有索引,查询将对整个表进行扫描,最坏的情况下,如果所有数据页都不在内存,需要读取10^4个页面,如果这10^4个页面在磁盘上随机分布,需要进行10^4次I/O,假设磁盘每次I/O时间为10ms(忽略数据传输时间),则总共需要100s(但实际上要好很多很多).如果对之建立B-Tree索引,则只需要进行log100(

Linux用户空间与内核空间(理解高端内存)

Linux 操作系统和驱动程序运行在内核空间,应用程序运行在用户空间,两者不能简单地使用指针传递数据,因为Linux使用的虚拟内存机制,用户空间的数据可能被换出,当内核空间使用用户空间指针时,对应的数据可能不在内存中.   Linux内核地址映射模型 x86 CPU采用了段页式地址映射模型.进程代码中的地址为逻辑地址,经过段页式地址映射后,才真正访问物理内存. 段页式机制如下图.   Linux内核地址空间划分 通常32位Linux内核地址空间划分0~3G为用户空间,3~4G为内核空间.注意这里

从Java的角度理解Ext的extend

在Java中,我们在实现继承的时候存在下面几个事实: 1.准备两个类,他们用extends关键字链接起来 2.如果超类没有默认构造函数,需要在子类构造函数中显式的super并传参,如果都是默认构造函数也可以super,不super虚拟机是自动的 3.子类可追加,覆盖,重载方法,子类可以有自己的私有属性,他们在子类构造函数中被构造 4.字段是数据,方法在代码区,和类建立方法表,同一个类的对象有自己的数据但是共享方法代码 比如有两个类,Plane和Space,Plane表示平面,Space表示空间,

从数据存放的角度分析INDEX索引总结

测试表结构:  代码如下 复制代码 CREATE TABLE TB1 (     ID INT IDENTITY(1,1),     C1 INT,     C2 INT ) 1. 聚集索引(Clustered index) 聚集索引可以理解为一个包含表中除索引键外多有剩余列的包含索引,为保证在DELETE/UPDATE操作的正确性,如果聚集索引未声明为唯一(UNIQUE),则系统会聚集索引键增加一个NULLABLE的INT类型标识列(UNIQUIFIER)以保证记录唯一性. 唯一聚集索引: C

PostgreSQL 空间st_contains,st_within空间包含搜索优化 - 降IO和降CPU(bound box)

标签 PostgreSQL , st_contains , st_within , 空间包含 , 空间bound box , GiST索引 , 空间索引结构 , IO放大 , BOUND BOX放大 背景 点面判断.按面圈选点或其他对象,是GIS几何应用中非常典型的需求. 在PostgreSQL中通过建立GiST索引可以加速这类判断,然而,建立索引就够了吗? 很多时候建立索引是不够的,性能没有到达巅峰,如果要更低的延迟,更少的CPU开销,还有什么优化手段呢? 实际上我以前写过一篇类似的文章,讲的