共 3 篇相关文章
这篇讲的是如何在Solr中实现高性能的地理位置搜索。作者从纯使用GeoHash过滤效率不高的问题出发，介绍了一种结合**笛卡尔层（Cartesian Tiers）与GeoHash**的组合方案。 核心思路是分两步走：在构建索引时，同时为每条记录计算其所属的不同精度层级的网格ID（tierBoxId）。查询时，先用笛卡尔层根据查询范围快速定位一个大致的网格集合，将这些网格下的文档ID存入一个BitSet，完成初步粗筛。随后，再将这个BitSet作为输入，传递给GeoHash距离过滤器。该过滤器遍历粗筛后的文档，通过GeoHash解码出精确经纬度，计算其与查询点的实际球面距离，并过滤掉超出范围的结果。 实现上的一个巧妙之处在于利用了Lucene的FieldCache来缓存GeoHash值，并通过过滤链（Filter Chain）将两层过滤逻辑无缝衔接。作者还展示了一个本地查询实例，验证了这套方案在查询指定经纬度500公里内数据时的有效性。整体来看，这种“粗筛+精算”的两级过滤模式，显著减少了需要进行精确距离计算的文档数量，从而提升了查询性能。
这篇讲的是Solr+Lucene实现空间搜索中GeoHash方案的源码级剖析。作者从索引构建和查询解析两个阶段切入，展示了如何将经纬度转换为Base32的GeoHash编码存入索引，以及查询时如何通过`SpatialFilterQParser`解析用户的距离查询语法。 核心聚焦在查询阶段的实现链条：从`GeoHashField.createSpatialQuery`生成查询，到`ValueSourceRangeFilter`和`GeohashHaversineFunction`协作过滤文档。作者特别指出了流程中一个可能影响性能的环节——过滤逻辑会遍历索引中的所有文档（从docId=0开始），逐一计算每个文档坐标与查询点的球面距离，并判断是否在指定范围内。源码中也有“TODO: optimize this”的标注，表明作者对这种全量遍历加计算的效率有所疑虑。 整体来看，文章像一次带读者拆解黑盒的代码导读，不仅说明了“怎么做”，也提出了对当前实现效率的思考，为理解Solr空间查询的内部机制提供了扎实的细节。
这篇文章从实际应用中的性能瓶颈出发，探讨了如何用 geohash 这一精巧的数据结构，来解决传统经纬度范围搜索在大型系统中遇到的难题。 文章开头就点明了旧有方案的痛点：直接用经纬度范围查询，在数据量大时速度慢、索引效率低，并且生成的 SQL 语句高度动态，几乎无法被数据库有效缓存。针对这些问题，作者引入了 geohash 这一方案。它的核心思想是将二维的经纬度坐标，通过一种空间填充曲线算法，映射为一维的、具有空间邻近特性的字符串。这串字符本身就可以直接用来建索引、做前缀匹配，从而将“附近的点在哪”这个二维空间搜索问题，巧妙地转化为一次高效的字符串范围查询。 通过这种方式，geohash 不仅提升了查询速度，更重要的是让查询条件变得稳定可控，使得查询计划的缓存成为可能，这对高并发、大数据量的应用架构意义重大。文章还隐含地指出了技术选型中的权衡：geohash 通过牺牲一点精度（将点映射到网格内）来换取巨大的性能收益，并且在处理网格边界附近的“邻居”时需要进行额外处理。这种从实际问题出发，逐步推导解决方案，并揭示其工程权衡的叙述方式，为面临类似挑战的开发者提供了清晰的思路。
