Postgresの高速ハミング距離クエリ

画像のハッシュを含む大規模なデータベース（16M行）があります。

妥当な時間枠で距離をハミングすることで行を検索できるようにしたいと思います。

現在、私が問題を適切に理解している限り、ここでの最良の選択肢はBK-Treeを実装するカスタムSP-GiST実装だと思いますが、それは多くの作業のように思われ、まだ実用的ではありませんカスタムインデックスの適切な実装の詳細。ハミング距離を計算すると、扱いやすい十分です、と私はやるけれども、Cを知っています。

基本的に、ここでの適切なアプローチは何ですか？ハッシュの特定の編集距離内で一致を照会できる必要があります。私が理解しているように、等しい長さの文字列を持つレーベンシュタイン距離は機能的にハミング距離です。そのため、そこからインデックスを作成する明確な方法はありませんが、少なくともいくつかの既存のサポートがあります（私が照会している値を思い出してください）変更：固定値からの距離を事前に計算することはできません。

ハッシュは現在、ハッシュのバイナリASCIIエンコード（たとえば「10010101 ...」）を含む64文字の文字列として格納されていますが、十分簡単に​​int64に変換できます。本当の問題は、比較的高速にクエリできる必要があるということです。

私が望むものの線に沿って何かを達成することは可能だと思わpg_trgmれますが、トライグラムマッチングメカニズムがどのように機能するかについては少しわかりません（特に、それが返す類似性メトリックは実際に何を表しますか？編集距離のようなもの）。

挿入のパフォーマンスは重要ではありません（各行のハッシュを計算するのは非常に計算コストがかかります）ので、私は主に検索を気にします。

さて、私はカスタムpostgres C拡張の作成にしばらく時間を費やし、メモリ内にBKツリー構造を維持するCythonデータベースラッパーを作成するだけで終わりました。

基本的に、データベースからのphash値のメモリ内コピーを維持し、データベースへのすべての更新がBKツリーに再生されます。

ここではすべてgithubにあります。また、単体テストも多数あります。

距離が4のアイテムの1,000万個のハッシュ値のデータセット全体でクエリを実行すると、ツリーの値の〜0.25％-0.5％がタッチされ、〜100ミリ秒かかります。

モアーの回答！

さて、ついに時間をかけてカスタムPostgreSQLインデックス拡張機能を作成しました。SP-GiSTインターフェースを使用しました。

主にPosgresが大きいため、これはかなり困難でした。

とにかく、いつものように、ここの githubにあります。

パフォーマンスに関しては、現在、この質問に対する他の回答のメモリ内の実装よりも2〜3倍遅いですが、使用する方がはるかに便利ですので、そのパフォーマンスヒットを喜んで食べます（現実的には、50 ms / query-150 ms / query、これはまだかなり小さいです）。