Postgres中的快速汉明距离查询

我有一个大型数据库（1600万行），其中包含图像的感知哈希。

我希望能够在合理的时间内按汉明距离搜索行。

目前，据我所知，我认为最好的选择是自定义SP-GiST实现，该实现可实现BK-Tree，但这似乎需要大量工作，但我仍然对实用性感到困惑正确实现自定义索引的详细信息。计算汉明距离很容易，但是我确实知道C。

基本上，这里合适的方法是什么？我需要能够在哈希的特定编辑距离内查询匹配项。据我了解，长度相等的字符串的Levenshtein距离在功能上是汉明距离，因此，尽管没有明确的方法可以从中创建索引（请记住，我正在查询的值），至少存在一些对我想要的支持。我无法预先计算与固定值的距离，因为那只会对那个值有用。

哈希当前存储为64个字符的字符串，其中包含哈希的二进制ASCII编码（例如“ 10010101 ...”），但是我可以很容易地将它们转换为int64。真正的问题是我需要能够相对快速地进行查询。

似乎可以通过达成与我想要的目标类似的东西pg_trgm，但是我不清楚三联词匹配机制的工作原理（特别是，它返回的相似性度量实际上代表了什么？看起来有点像编辑距离）。

插入性能并不关键（计算每行的哈希值在计算上非常昂贵），因此我主要关心搜索。

好吧，我花了一段时间看待编写自定义的postgres C扩展，最后写了一个Cython数据库包装器，该包装器在内存中维护了BK树结构。

基本上，它维护数据库中phash值的内存副本，并且对数据库的所有更新都将重播到BK树中。

全部都在这里的 github上。它还有很多单元测试。

在1000万个散列值的数据集中查询距离为4的项会导致触摸树中〜0.25％-0.5％的值，大约需要100毫秒。

沼泽答案！

好的，我终于花了时间写一个自定义的PostgreSQL索引扩展。我使用了SP-GiST接口。

这颇具挑战性，主要是因为Posgres 很大。

无论如何，和往常一样，它在github 这里。

在性能方面，目前比我在此问题的其他答案中的纯内存实现慢大约2-3倍，但是使用起来要方便得多，我会很高兴地吃掉性能下降带来的麻烦（实际上大约是50毫秒/查询-150毫秒/查询，这仍然很小）。