3

最初に少し背景を説明します。GeoModelは私が作成したライブラリであり、AppEngineアプリに非常に基本的な地理空間のインデックス作成とクエリ機能を追加します。ジオハッシュへのアプローチも同様です。GeoModelの同等のロケーションハッシュは「geocell」と呼ばれます。

現在、GeoModelライブラリは、13のプロパティ（location_geocell__n_、n = 1..13）を各ロケーション認識エンティティに追加します。たとえば、エンティティは次のようなプロパティ値を持つことができます。

location_geocell_1 = 'a'
location_geocell_2 = 'a3'
location_geocell_3 = 'a3f'
...

これは、空間クエリ中に不等式フィルターを使い果たしないようにするために必要です。

13プロパティのアプローチの問題は、アプリが実行したい地理クエリに対して、13の新しいインデックスを定義して構築する必要があることです。プロジェクトのデモアプリを書き直しているときに痛々しいほど気づいたので、これは間違いなくメンテナンスの手間です。これは私の最初の質問につながります：

質問1：インデックスごとに大きなストレージオーバーヘッドはありますか？つまり、それぞれにn個のエンティティを持つ13個のインデックスがあるのに対し、13n個のエンティティを持つ1個のインデックスがある場合、ストレージの点で前者は後者よりもはるかに悪いですか？

この記事によると、（1）の答えはノーのようですが、誰かが別の経験をしたことがあるかどうかを確認したいと思います。

ここで、GeoModelライブラリを調整して、13個の文字列プロパティの代わりにlocation_geocellsと呼ばれるStringListPropertyが1つだけになるようにすることを検討しています。

location_geocells = ['a', 'a3', 'a3f']

これにより、はるかにクリーンになりindex.yamlます。しかし、私はパフォーマンスへの影響に疑問を持っています：

質問2：13個の文字列プロパティから1個のStringListPropertyに切り替えると、クエリのパフォーマンスに悪影響があります。私の現在のフィルターは次のようになります。

query.filter('location_geocell_%d =' % len(search_cell), search_cell)

新しいフィルターは次のようになります。

query.filter('location_geocells =', search_cell)

最初のクエリには_n_エンティティの検索スペースがあり、2番目のクエリには_13n_エンティティの検索スペースがあることに注意してください。

（2）の答えは、このブログ投稿のヒント＃6によると、どちらも同等のクエリパフォーマンスをもたらすようですが、これについても、実際の経験が異なる人がいないかどうかを確認したいと思います。

最後に、ストレージの使用率、クエリのパフォーマンス、使いやすさ（特に、wrt index.yaml）を改善するのに役立つ提案やヒントが他にある場合は、お知らせください。ソースはここにありますgeomodel＆geomodel.py

4

3 に答える 3

5

インデックスごとに大きなオーバーヘッドがないことは正しいです。1つのインデックスの13nエントリは、13のインデックスのnエントリとほぼ同等です。ただし、インデックスの総数には100の制限があるため、これにより、使用可能なインデックスのかなりの部分が消費されます。

とはいえ、ListPropertyを使用することは、使いやすさとインデックス消費の観点から、間違いなくはるかに優れたアプローチです。ご想像のとおり、両方のクエリが同じ数の行を返すと仮定すると、小さなインデックスとはるかに大きなインデックスのクエリの間にパフォーマンスの違いはありません。

個別のプロパティを使用するために私が考えることができる唯一の理由は、特定の詳細レベルでインデックスを作成するだけでよいことがわかっている場合ですが、リストに追加する詳細レベルを指定することで、挿入時にそれをより適切に達成できます。最初の場所。

いずれの場合も、ソート順または不等式フィルターと組み合わせてジオセルプロパティをクエリする場合にのみインデックスが必要になることに注意してください。ただし、他のすべての場合は、自動インデックス付けで十分です。

于 2009-08-03T12:40:46.033 に答える
1

最後に、ストレージの使用率、クエリのパフォーマンス、および/または使いやすさを向上させるのに役立つ他の提案やヒントがある場合

StringListpropertyは上記の理由からの方法ですが、実際の使用法では、複数のプロパティに対してクエリを実行できるように、既存のStringListを所有するジオセルにジオセルを追加することをお勧めします。

したがって、低レベルのAPIを提供する場合は、 billkatzのような全文検索の実装で機能する可能性があります。

def point2StringList(Point, stub="blah"):
    .....
    return ["blah_1:a", "blah_2":"a3", "blah_3":"a3f" ....]

def boundingbox2Wheresnippet(Box, stringlist="words", stub="blah"):
    .....
    return "words='%s_3:a3f' AND words='%s_3:b4g' ..." %(stub)

etc.
于 2009-08-03T15:47:37.923 に答える
0

16進数でエンコードしたため、最終的に13個のインデックスが作成されたようです（人間の読みやすさ/マップレベルのために？）。バイト（ByteString）の可能性を最大限に活用した場合、1文字（バイト）あたり16セルではなく、256セルになります。そこで、同じ精度でインデックスの数を大幅に減らします。

ByteStringはstrの単なるサブクラスであり、長さが500バイト未満の場合も同様にインデックスが付けられます。

ただし、レベルの数は少なくなる可能性があります。私にとって、「地球」のほとんどの状況では、4または5レベルで十分です。より大きな惑星の場合、または各砂粒子をカタログ化する場合、使用されるエンコーディングに関係なく、とにかくより多くの分割を導入する必要があるかもしれません。いずれの場合も、ByteStringは16進エンコーディングよりも優れています。また、インデックス作成を大幅に削減するのに役立ちます。

  • 40億個の低（最高）レベルのセルを表すために必要なのは、4バイトまたは4つのインデックスだけです。（基本的なコンピュータアーチまたはメモリアドレス指定から）。
  • 同じことを表すには、 16桁の16進数または16個のインデックスが必要です。

私は間違っている可能性があります。マップのズームレベルに一致するインデックスレベルの数がより重要である可能性があります。訂正してください。ここでたった一人の（他の）人がこれに意味があると思ったら、ヘックスの代わりにこれを試すことを計画しています:)

または、階層を下に行くにつれて、大きなセルが少なく（16）、多い（128,256）ソリューション。何かご意見は？

例えば：

  • [0-15] [0-31] [0-63] [0-127] [0-255]は、log2のサイズが減少する5つのインデックスを持つ1G低レベルセルを提供します。
  • [0-15] [0-63] [0-255] [0-255] [0-255]は、5つのインデックスを持つ16G低レベルセルを提供します。
于 2011-09-20T10:50:15.140 に答える