在lucene空间4中，我想知道geohash索引如何在幕后工作。我理解基本上需要2点（lat，lon）的geohash的概念，并创建一个单独的“字符串”散列。geohash索引如何在Lucene中工作
索引只是一个“字符串”索引（r-tree或quad-tree）或沿着这些行的东西（比如只是索引一个姓氏）.....或者是有什么特别的东西。
对于预固定式搜索做的所有n克散的被索引，例如如果一个地理散列是
drgt2abc做到这一点得到索引为d，博士，DRG，drgt等。
是否有我们可能需要索引的缺省n-gram数？
使用这种类型的索引将搜索具有100万条记录的查询诗歌1亿条记录对空间查询具有相似的查询性能。 （如框/多边形，或距离），或者我可以预期随着大量记录的添加，一般/典型的索引缓慢退化。
感谢
最好的网上的解释是我的视频：Lucene/Solr 4 Spatial deep dive
是该指数只是一个“串”指数（R-树或四叉树）或东西 沿着这些线路（例如就像索引一个姓氏一样）.....或者是否有 特别的东西。
从根本上说，Lucene只有一个用于文本，数字和空间的索引。你可以说这是一个字符串索引。这是一个字节/字符串的排序列表。从更高层次来看，以这种方式使用空间是计算机科学中“尝试”AKA“前缀树”的家族。
对于预固定式搜索做的所有的n-gram的哈希获取 索引，例如，如果一个地理散列是
drgt2abc做到这一点得到索引为d，博士，DRG，drgt等...
是的。
是否有我们可能需要索引的缺省n-gram数？
您可以根据您的精度要求方便地进行说明，它会查找需要多长时间。或者你可以通过长度来说明。
在这种类型的索引将搜索查询与10万个 记录诗句1亿条记录有 空间查询类似的查询性能。 （如框/多边形，或距离），或者我可以预期 索引的一般/典型缓慢退化，因为大量记录 添加。
事实上，这种类型的索引（更具体地说是使用它的聪明的递归搜索树算法）意味着您将具有可扩展的搜索性能。100米是一个过滤器匹配的文件吨，所以它当然会比仅匹配10万个文档的文档慢，但它绝对是线性的。明年将会更快，因为今年夏天正在进行一项新的PrefixTree编码加上正在进行的空间基准测试，这将使我可以进一步优化我的计划。