MySQL和Klustron的GIS相关特性

引言

随着移动互联网的迅猛发展，地理空间信息系统（GIS）的数据被广泛应用于各种场景中。为了支持GIS数据管理，MySQL提供了诸如空间索引，空间处理函数等特性；PostGIS是PostgreSQL生态最强大的功能被广泛应用，但是受单机资源限制的约束。Klustron利用PostgreSQL的PostGIS扩展来提供GIS数据管理功能，极大提升了PostGIS的数据管理规模和性能，同时也采用MySQL对GIS数据的存储及处理能力。

本期的Tech Talk，我们将围绕着这些特性，详细介绍MySQL在GIS方面的底层实现技术，以及Klustron对GIS的支持及优势，让大家对于这些特性的原理，实现方法有个比较深入的了解。

本文金句： MySQL提供的空间数据索引和空间数据处理函数为地理信息系统提供了重要的底层支持。

01 MySQL GIS特性简介：

**地理信息系统（Geographic Information System 简称GIS）：**是以地理空间数据库为基础，在计算机硬件支持下对空间相关数据进行采集，管理和分析的计算机技术系统。

[图片: GIS相关图表]

而MySQL从4.1版本开始支持了基本空间数据类型及部分空间对象函数。后续，MyISAM存储引擎支持了空间索引。

5.7版本，InnoDB引擎支持了空间索引，并采用Boost.Geometry库对GIS提供支持。

8.0版本进行了进一步优化，如：支持空间参考系统（SRS）等。

[图片: GIS相关图表]

KunlunBase（Klustron）采取了存算分离的分布式架构，上层计算节点采用的PostgreSQL，下层存储节点则是MySQL实例，中间通过数据通道通信。为了支持GIS，Klustron分别在计算层和存储层都相应的做了处理，主要是：

• 计算层Kunlun-server节点由于基于PostgreSQL，所以可以挂载PostGIS为用户提供GIS服务，并帮助PostGIS突破了单机服务器资源限制。Kunlun-server的分布式查询处理机制与存储层Kunlun-storage实例按照其内部格式做GIS数据的存取。
• 存储层Kunlun-storage充分利用了MySQL对GIS数据的处理能力，实现GIS数据的事务性及索引能力。

以下是Klustron分布式数据库的整体架构图：

[图片: GIS相关图表]

02 MySQL GIS特性详解：

MySQL的空间数据类型及函数

MySQL支持的空间数据格式主要有两种，即：WKT（文本格式）和WKB（二进制格式）两种GIS数据格式，在InnoDB存储引擎内部实际是以BLOB方式存储；

MySQL支持的空间数据数据类型主要包括：

GEOMETRY（总类）, POINT（点），LINESTRING（线）,POLYGON（多边形）, MULTIPOINT（点集合）, MULTILINESTRING（线集合）, MUTIPOLYGON（多边形集合）, GEOMCOLLECTION（对象集合）；

MySQL操作空间数据的主要函数分类包括：

构造：Point(x,y), LineString(…)…；

格式转换：ST_GeomFromText(…), ST_LineFromText(..),…;

对象属性：ST_Dimension(), ST_GeometryType()…;

关系计算：ST_Contains(), ST_Crosses(), ST_Within()…;

对象生成：ST_Union()…;

其他：ST_GeoHash(), ST_IsValid()。

空间参考系统（Spatial Reference System）

空间参考系统（SRS）指确定地理目标平面位置和高程的平面坐标系和高程坐标系的统称。

SRID（Spatial Reference ID）:是指空间参考系统的ID。

[图片: GIS相关图表]

如上图所示，当无SRID或SRID为0时，空间对象处于一个单纯的笛卡尔平面坐标系，也就是没有一个给定的坐标位置。而SRID=X或Y时，则空间对象处于一个给定的坐标系中，其位置在坐标系中可以确定。

常用的SRID主要有：

• SRID=0 笛卡尔平面坐标系（默认）
• SRID=4326 GPS坐标系
• SRID=3857 web地图投影坐标系

如下面的例子所示，可以建表时指定SRID。

[图片: GIS相关图表]

MySQL 8.0版本增加对空间数据的SRID约束。建立空间索引需要对应列NOT NULL且有具体的SRID，没有SRID属性的列称为非SRID约束，会接收任何SRID坐标系的值，但是优化器不能在这样没有SRID的列上使用空间索引。

下面是个这一约束的例子：

[图片: GIS相关图表]

空间索引（R-Tree）

MySQL5.7开始InnoDB对GIS数据提供了索引支持，采取的是R树索引。

R树结构：与B树索引类似，R树也是一种树形结构的索引，不同的是R树的索引key值是MBR（Minimum Bounding Rectangle）

叶子节点记录包含了MBR以及指向的聚集索引记录，非叶子节点记录包含了指向叶子节点的指针，及对应叶子节点记录所组成的MBR。

以下是一个典型的R树索引结构：

[图片: GIS相关图表]

可以看到，A和B两个叶子节点的记录的MBR被包括在其父亲节点的MBR-N中，也就是上方的图形的矩形N包含了A，B两个矩形。当做查询时，假设要找到A，则从根节点T开始，根据查询条件依次遍历T，N，A。

R树的并发控制：由于MBR没有顺序的概念，所以，和B树不同，R树需要采用谓词锁（Predicate lock）来实现并发控制和事务隔离。谓词锁指的是某个DML操作的逻辑谓词，比如：在A点的周围100米范围内，这个条件就是一个谓词，以此作为判断在访问某条数据时是否有访问冲突。

关于R树的操作和并发控制是一个比较深入的话题，后续如果大家感兴趣我们可以专门再讨论。

以下是一个建立空间索引的例子：

[图片: GIS相关图表]

03 MySQL GIS vs PostGIS or Klustron

下表是MySQL GIS和PostGIS在功能方面的一些对比：

[图片: GIS相关图表]

通过对比我们发现，总体来说，PostGIS在功能性方面还是比MySQL有着一定的优势。另外，postgis支持8500个srs，mysql支持5151个，有59个是mysql支持但是postgis不支持的，而且空间操作函数和运算符，postgis远比mysql丰富。

GIS in Klustron

前面我们已经介绍过Klustron的架构和在GIS方面的一些特性，详细来说。

Klustron对GIS的支持包括：

• Klustron支持PostGIS的所有gis函数和运算符；
• Klustron支持PostGIS和MySQL的SRS的交集；
• Klustron也支持PostgreSQL自带的geometry和geography类型，包括point, lseg, path, circle, polygon, box类型等；
• Klustron支持了多维数据，通过扩展MySQL使之可以存储多维数据；

Klustron中PostGIS插件的使用方式：

• 可以在计算节点查询表pg_mysql_srs_basics 来查看mysql支持的srs集合

• 在Klustron中创建postgis extension的方法：

• • set create_system_table=true;
  • create extension postgis;
  • set create_system_table=false;

04 Q&A

**q1：**PostGIS和mysql在GIS方面的性能对比怎么样？

**a1：**我们介绍过了，从功能性上来说，PostGIS相比MySQL是有着一定优势的。从性能上来说，我们并没有做过详细的评测，但从业界获得的一些信息来说，PostGIS在性能上也有一定的优势。毕竟PostGIS相对MySQL来说有着先发优势，成熟度也高一些，所以，在性能上有优势也不令人惊奇。

**q2：**Klustron后续在GIS方面会有哪些改进的工作？

**a2：**目前Klustron已经在PostGIS和MySQL GIS的基础上具备了处理GIS数据的能力，并相较两者有着分布式的加持，使得功能和性能更为优越。后续，Klustron会优先处理一些GIS方面兼容性的问题，比如对空值的处理问题等，然后，我们会继续寻找可能的优化点和功能增强，为用户提供更好的支持。

END