由于ByteHouse的数据是按照列式存储，相比于传统的行级别索引，我们会对S2排序后的经纬度数据，先按照小块粒度切分，再利用RTree来索引每个小块数据。这样，基于小块粒度的RTree索引的存储开销更小，加载和查询效率更高。给定一个查询的多边形或圆，RTree能快速索引到匹配的数据块。由于每个数据块内的经纬度数据是按照二维层面聚集，这样使得相邻的点在二维空间上更加紧密，数据局部性更好。

ByteHouse GIS索引结构

针对某个具体场景中给出的一个圈选范围，需要返回范围内的所有POI (Point of Interest)点。下面两幅图分别展示了传统经纬度排序方式（Order By latitude, longitude）和ByteHouse GIS索引排序方式（Order By point）的圈选效果。其中，图中黑色的框代表了所有数据块，红色部分代表了圈选命中的数据块。

从结果中看出，传统经纬度排序命中的范围会横跨很广的纬度，造成读取许多无用的数据。而按照ByteHouse GIS索引搜索出的数据块只集中在北京地域，正好满足圈选所需的最小数据块集合。

传统经纬度排序方式的搜索效果

ByteHouse GIS排序方式的搜索效果

兼容OGC标准数据类型

按照OGC标准，新增7种几何类型，包括Point、LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection。

存储层面上，传统GIS数据库（例如，PostGIS）将几何数据序列化为Blob类型，读取时需要额外花费反序列化的开销。而ByteHouse GIS则按照数值数组和列式方式存储，减少存储量、序列化和反序列化开销。

空间函数

功能上，ByteHouse GIS目前已支持超过50个通用的空间函数，下面表格列举了几大函数分类。另外，我们针对个别高频使用的空间函数进行了基于列式数据存储格式的性能优化。

存量数据迁移

同时，ByteHouse GIS也支持常见数据格式的导入与导出，包括WKT、WKB、GeoJson、ShapeFile、Parquet、CSV和Arrow等文件格式。

Benchmark 测试标准NYC Taxi数据集

为了说明性能效果，我们基于两个关键的 GIS 函数，使用 NYC Taxi 数据集，选取纽约的 3 个地理区域，将ByteHouse、ClickHouse、StarRocks、PostGIS、DuckDB进行了性能对比（以上对比的版本参照发文日期的最新版本）。

在本次测试中，我们选取了两个关键的 GIS 函数：ST_DistanceSphere 和 ST_Within；并使用 NYC Taxi 数据集（Size：21GB；条数：169,001,162），数据集将纽约拆分成多个地理区域（比如 Brooklyn，Manhattan），本实验选取其中 3 个不同大小的地理区域（按照过滤度区分：zone 1、zone 2、zone 3）进行了性能对比。

ST_Within 函数性能对比：在 ST_Within 函数的测试中，从查询延迟来看，OLAP引擎的整体查询延时低于1s，由于二维空间索引和向量化的数据处理方式，ByteHouse查询延时最低；当前版本的DuckDB由于没有空间索引，同时采用了BLOB的存储方式，数据扫描和反序列化开销比较大，查询性能不好；采用行存的PostGIS在大范围搜索的情况下（zone3），虽然有索引加持，依然会有较重的读放大，查询延时超过6s。从每秒吞吐量来看，ByteHouse通过索引降低了数据读取和反序列化开销，展现出明显优势，其次为PostGIS，在小范围搜索（zone1和zone2）情况下表现优秀。

ST_Within函数性能对比

ST_Within每秒处理空间查询数

ST_DistanceSphere 函数性能对比：在 ST_DistanceSphere 函数的测试中，在处理相同数据集和查询时，ByteHouse具备二维空间索引过滤和向量化计算的优势，性能控制在0.1s以内。ClickHouse和StarRocks同样具备较好的0.1s-1s内的较好性能表现。

ST_DistanceSphere 函数性能对比

基于标准数据集的测试结果来看，对比传统的PostGIS：

对比社区ClickHouse：

业务数据集

在电商场景中，ByteHouse GIS能力不仅满足平台商家运营快速分析商家经营状态、管理商家的需求，还将数据读取量减少超过50%，进一步降低了磁盘IO以及计算带来的CPU开销。

总结

本文具体拆解了ByteHouse GIS能力的技术实现方案，并将ByteHouse、ClickHouse、StarRocks、PostGIS、DuckDB五款数据库产品的性能进行分析和比较。

结论总结如下：ByteHouse在ST_DistanceSphere 函数及ST_Within 函数的查询延迟低于其他产品，查询吞吐量更高，具备比较明显的性能优势。

需要注意的是，性能测试结果取决于多个因素，在实际应用中，需要综合考虑各种因素，如数据规模、可扩展性、易用性、稳定性、安全性以及是否需要与其他系统集成等其他因素进行综合选择，并对数据库进行合理的配置和优化，以获得最佳的性能表现。

对于专注于地理空间数据分析的项目，PostGIS能提供了全面的地理空间功能支持，是一个比较好的选择。然而，如果地理空间数据只是大数据分析的一部分，且如果性能是首要考虑因素，那么ByteHouse、ClickHouse、StarRocks、DuckDB是合适的选择，其中ByteHouse GIS 功能不仅提供了高性能的地理空间分析能力，还具有易于使用、实时分析和云原生等特点，这使得企业可以更灵活、更高效地利用地理空间数据。

参考PostGIS: /OGC: …Google S2: s2geometry.io/Geos: //docs/en/sql…Cuda: /cuda-toolki…/rapidsai/cu…/arctern-io/…/go_spatial_…