在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編碼加上正在進行的空間基準測試，這將使我可以進一步優化我的計劃。