在 lucene spatial 4 中，我想知道 geohash 索引是如何在幕后工作的。我理解 geohash 的概念，它基本上需要 2 个点（纬度，经度）并创建一个“字符串”哈希。
索引是否只是一个“字符串”索引（r-tree 或 quad-tree）或类似的东西（例如仅索引姓氏）......或者它有什么特别之处。
对于预先固定的类型搜索，是否对哈希的所有 n-gram 进行索引，例如如果 geohash 是
drgt2abc 是否将其索引为 d、dr、drg、drgt 等。
是否存在我们可能希望索引的默认 n-gram 数量？
使用这种类型的索引将搜索具有 10 万条记录的查询，而 1 亿条记录对于空间查询具有相似的查询性能。（例如框/多边形或距离）或者我是否可以预期随着大量记录的添加，索引会出现一般/典型的缓慢降级。
谢谢
最好的在线解释是我的视频：Lucene / Solr 4 Spatial deep dive
索引是否只是一个“字符串”索引（r-tree 或 quad-tree）或类似的东西（例如仅索引姓氏）......或者它有什么特别之处。
从根本上说，Lucene 只有一个用于文本、数字和空间的索引。你可以说它是一个字符串索引。它是字节/字符串的排序列表。从更高层次的角度来看，以这种方式使用空间是计算机科学中“Tries”AKA“PrefixTrees”的家族。
对于预先固定的类型搜索，是否对哈希的所有 n-gram 进行索引，例如如果 geohash 是
drgt2abc 是否将其索引为 d、dr、drg、drgt 等。
是的。
是否存在我们可能希望索引的默认 n-gram 数量？
您可以根据您的精度要求方便地告诉它，它会查找需要多长时间。或者你可以通过长度来判断。
使用这种类型的索引将搜索具有 10 万条记录的查询，而 1 亿条记录对于空间查询具有相似的查询性能。（例如框/多边形或距离）或者我是否可以预期随着大量记录的添加，索引会出现一般/典型的缓慢降级。
事实上，这种类型的索引（更具体地说是使用它的聪明的递归搜索树算法）意味着您将拥有可扩展的搜索性能。100m 是一个过滤器要匹配的大量文档，因此它当然会比仅匹配 100k 文档的文档要慢，但它绝对是次线性的。到明年，它会更快，因为今年夏天在新的 PrefixTree 编码上进行了工作，加上正在进行的空间基准测试，这将使我能够进行我计划的进一步调整优化。