0

できればPython Webサーバープロセスが実行されている同じボックスのメモリに、2つの異なるpgsqlテーブルの2つのbツリーインデックスを実装する必要があります（クエリはできるだけ高速である必要があります）。これを実装する最良の方法を考えていました：

  1. プロセス内のメモリ内の b ツリーにインデックスを付けて維持します (手動で Python ライブラリを使用)。
  2. 別のメモリ内データベース (redis、mongo など) にインデックスを実装する
  3. neo4j や flock などのグラフ データベースを使用する (新しいホットさで遊ぶ言い訳)
  4. pgsql を微調整して、インデックス自体を実行します。(データベースに存在する他のデータのパフォーマンスが低下する代わりに?)

私のニーズは、重要な順に次のとおりです。

  • クエリ速度
  • 最近傍探索*
  • 索引サイズ
  • オープンソース
  • pythonバインディング:)

追記事項: ツリーは一度に数千のノードに達する可能性があり、高い挿入/削除レートに耐える必要があります

*したがって、756.837 を検索すると、755.928 と 757.113 しか存在しない場合、パラメーターに応じていずれかが返されます

明確にするために、この postgres データベースは、処理中のデータに加えて、従来の webapp crud データを提供します。Web アプリケーション データのパフォーマンスを維持するために、複雑さを追加しても構わないと思っています。

4

1 に答える 1

0

最初のステップは、PostgreSQL インデックスをどこまでプッシュして、目的を達成できるかを確認することです。典型的な btree インデックスは高速ですが、多くの機能はありません。特に、それらは knn 検索をうまく提供できません。必要に応じて、インデックスを Btree から GiST に変更することをお勧めします。GiST は KNN 検索を提供し (データ型がこれをサポートしていると仮定します!)、探している残りの多くのことを実行できます。欠点は、データ型によっては、一部のデータ型を適切にサポートするためにプログラミングを行う必要がある場合があることです。

GiST は、標準の btree インデックスよりも多くの検索オプションを提供しますが、クエリも少し遅くなります。ただし、主な利点は、GIN インデックスよりもはるかに高い挿入/更新レートをサポートし、knn 検索もサポートすることです。

それがうまくいかない場合....おそらくメモリ内キャッシュ（memcachedなど）を使用するか、単に古いSys V IPCと別のプロセスを使用して、メモリに何か他のものを実装することをお勧めします。ただし、メモリへの同時アクセスには注意してください。

于 2013-05-09T08:41:01.283 に答える