lucene Spatial 4では、ジオハッシュインデックスが舞台裏でどのように機能するのか疑問に思っています。基本的に2ポイント（lat、lon）を取り、単一の「文字列」ハッシュを作成するジオハッシュの概念を理解しています。
インデックスは単なる「文字列」インデックス（rツリーまたはクアッドツリー）ですか、それともこれらの線に沿ったもの（姓のインデックスだけなど）ですか？....または特別なものがあります。
事前に固定されたタイプの検索の場合、ジオハッシュが
drgt2abcは、これをd、dr、drg、drgtなどとしてインデックス付けします。
インデックスを作成したいデフォルトのnグラム数はありますか？
このタイプのインデックス作成では、10万レコードのクエリを検索しますが、1億レコードは、空間クエリに対して同様のクエリパフォーマンスを示します。（ボックス/ポリゴン、距離など）または、多くのレコードが追加されるにつれて、インデックスの一般的/一般的な遅い劣化が予想されますか。
ありがとう
最高のオンライン説明は私のビデオです: Lucene / Solr 4 Spatial deep dive
インデックスは単なる「文字列」インデックス（rツリーまたはクワッドツリー）ですか、それともこれらの行に沿ったもの（姓のインデックス付けなど）ですか...それとも何か特別なものがありますか。
基本的に、Lucene には、テキスト、数値、および空間に使用されるインデックスが 1 つだけあります。文字列インデックスと言えます。これは、バイト/文字列のソートされたリストです。より高いレベルのビューから、空間をこのように使用することは、コンピューター サイエンスの「Tries」別名「PrefixTrees」のファミリーです。
事前に固定されたタイプの検索の場合、geohash が
drgt2abc は、これを d、dr、drg、drgt などとしてインデックス付けします。
はい。
インデックスを作成したい n-gram のデフォルト数はありますか?
あなたが持っている精度要件に関して都合よく伝えると、必要な長さを調べます。または、長さで判断できます。
このタイプのインデックス作成では、10 万レコードに対して 1 億レコードのクエリを検索すると、空間クエリに対して同様のクエリ パフォーマンスが得られます。(ボックス/ポリゴン、または距離など) または、多くのレコードが追加されると、一般的/典型的なインデックスの劣化が遅くなると予想できますか?
実際、このタイプのインデックス作成 (より具体的には、それを使用する巧妙な再帰的検索ツリー アルゴリズム) は、スケーラブルな検索パフォーマンスが得られることを意味します。100m は、1 つのフィルターが一致する大量のドキュメントであるため、もちろん、100k ドキュメントのみに一致するものよりも遅くなりますが、それは間違いなくサブリニアです。そして、来年までにはさらに高速になる予定です。これは、この夏に新しい PrefixTree エンコーディングと進行中の空間ベンチマークに関する作業が行われるためです。これにより、計画したチューニングの最適化をさらに行うことができます。