用于快速查找字符串之间差异的数据结构或算法

我有一个100,000个字符串数组，长度均为。我想将每个字符串与其他每个字符串进行比较，看看是否有两个字符串相差1个字符。现在，当我将每个字符串添加到数组时，我正在将其与数组中已有的每个字符串进行比较，该字符串的时间复杂度为。$k$$\frac{n(n-1)}{2} k$

是否有一种数据结构或算法可以比我已经做的更快地将字符串相互比较？

一些其他信息：

• 顺序很重要：abcde和xbcde相差1个字符，而abcde和edcba相差4个字符。

• 对于每一个相差一个字符的字符串对，我将从数组中删除其中一个字符串。

• 现在，我正在寻找仅相差1个字符的字符串，但是如果可以将1个字符的差异增加到例如2个，3个或4个字符，那就太好了。但是，在这种情况下，我认为效率比提高字符差异限制的能力更为重要。

• $k$通常在20-40的范围内。

有可能达到最坏情况下的运行时间。$O(nk \log k)$

让我们开始简单。如果您关心一个易于实现的解决方案，该解决方案将在许多输入（但不是全部）上有效，那么这是一个简单，实用，易于实现的解决方案，在许多情况下在实践中就足够了。但是，在最坏的情况下，它确实会回到二次运行时间。

取每个字符串并将其存储在哈希表中，该哈希表键入该字符串的前半部分。然后，遍历哈希表存储桶。对于同一存储桶中的每对字符串，请检查它们是否相差1个字符（即，检查其后半部分是否相差1个字符）。

那么，这一次键入的每个字符串，并将其存储在一个哈希表，第二个字符串的一半。再次检查同一存储桶中的每对字符串。

假设字符串分布均匀，则运行时间可能约为。此外，如果存在一对相差1个字符的字符串，则会在两次遍历中的一个过程中找到（因为它们仅相差1个字符，因此相异的字符必须位于字符串的前半部分或后半部分，因此字符串的后半部分或前半部分必须相同）。但是，在最坏的情况下（例如，如果所有字符串都以相同的字符开头或结尾），这会降低为运行时间，因此其最坏情况下的运行时间并不能改善暴力破解力。$O(nk)$$k/2$$O(n^2 k)$

作为性能优化，如果任何存储桶中的字符串太多，则可以递归重复相同的过程，以寻找相差一个字符的一对。递归调用将在长度为字符串上进行。$k/2$

如果您担心最坏的运行时间：

通过以上性能优化，我认为最坏情况下的运行时间为。$O(nk \log k)$

我的解决方案类似于j_random_hacker的解决方案，但仅使用单个哈希集。

我将创建一个哈希散列字符串。对于输入中的每个字符串，将其添加到设置的字符串中。在每个这些字符串中，用一个特殊字符替换一个字母，这些字符在任何一个字符串中都找不到。添加它们时，请检查它们是否尚未在集合中。如果是，则您有两个仅相差最多（最多）一个字符的字符串。$k$

字符串为“ abc”，“ adc”的示例

对于abc，我们添加“ * bc”，“ a * c”和“ ab *”

对于adc，我们添加“ * dc”，“ a * c”和“ ad *”

当我们第二次添加'a * c'时，我们注意到它已经在集合中，因此我们知道有两个仅相差一个字母的字符串。

该算法的总运行时间为。这是因为我们为输入中的所有n个字符串创建了k个新字符串。对于这些字符串中的每一个，我们需要计算哈希，通常需要O （k ）时间。$O(n*k^2)$$k$$n$$O(k)$

存储所有字符串需要空间。$O(n*k^2)$

进一步的改进

我们可以通过不直接存储修改后的字符串，而是存储一个引用原始字符串和被屏蔽字符的索引的对象来进一步改进算法。这样，我们不需要创建所有字符串，而只需要空间来存储所有对象。$O(n*k)$

您将需要为对象实现自定义哈希函数。我们可以以Java实现为例，请参阅Java文档。java hashCode将每个字符的unicode值乘以（k为字符串长度，而i为该字符的从一开始的索引。请注意，每个更改后的字符串与原始字符串仅相差一个字符。我们可以轻松地计算出该字符对哈希码的贡献。我们可以减去该字符，然后添加掩码字符，这需要O （1 ）进行计算。这使我们可以将总运行时间降低到O （$31^{k-i}$$k$$i$$O(1)$$O(n*k)$

我将制作哈希表H 1，… ，H k，每个哈希表都有一个长度为（k − 1 ）的字符串作为键，并包含一个数字列表（字符串ID）作为值。哈希表H i将包含到目前为止已处理的所有字符串，但位置i处的字符已删除。例如，如果k = 6，则H 3 [ A B D E F ]将包含到目前为止看到的所有具有模式A的字符串的列表。$k$$H_1, \dots, H_k$$(k-1)$$H_i$$i$$k=6$$H_3[ABDEF]$，其中 ⋅装置“的任何字符”。然后处理第 j个输入字符串 s j：$AB\cdot DEF$$\cdot$$j$$s_j$

1. 对于1到k范围内的每个： $i$$k$
   • 格式字符串通过删除我的性格第小号Ĵ。$s_j'$$i$$s_j$
   • 查找。此处的每个字符串ID均标识等于s或仅在位置i不同的原始字符串。将它们输出为字符串s j的匹配项。（如果要排除完全相同的重复项，请将哈希表的值类型设置为（字符串ID，已删除字符）对，以便可以测试已删除了与我们刚刚从s j中删除的字符相同的字符。）$H_i[s_j']$$s$$i$$s_j$$s_j$
   • 将插入到H i中，以供将来查询使用。$j$$H_i$

如果我们显式地存储每个哈希键，则必须使用空间，因此至少具有时间复杂度。但是，正如Simon Prins所述，可以隐式表示对字符串的一系列修改（在他的案例中，将单个字符更改为，在我的情况下，将其表示为删除），以使特定字符串的所有k个哈希键仅需要O （k ）空间，整体导致O （n k ）空间，并为O （n k ）打开可能性$O(nk^2)$*$k$$O(k)$$O(nk)$$O(nk)$时间也一样。为了实现这种时间复杂性，我们需要一种方法来计算O （k ）时间中长度k字符串的所有变化的哈希值：例如，这可以使用多项式哈希值完成，如DW所建议的（这是可能比单纯将已删除的字符与原始字符串的哈希值进行XOR更好。$k$$k$$O(k)$

西蒙·普林斯（Simon Prins）的隐式表示技巧也意味着实际上不会真正执行每个字符的“删除”，因此我们可以使用字符串的常规基于数组的表示，而不会降低性能（而不是我最初建议的链表）。

这是比多项式哈希方法更健壮的哈希表方法。首先生成与哈希表大小M互质的随机正整数r 1 .. k。即，0 ≤ [R 我 < 中号。然后散列每个串X 1 .. ķ至（Σ ķ 我= 1 X 我ř 我）MOD 中号。对手几乎无法采取任何措施来导致非常不均匀的碰撞，因为您在运行时生成r 1 .. k，因此$k$$r_{1..k}$$M$$0 \le r_i < M$$x_{1..k}$$(\sum_{i=1}^k x_i r_i ) \bmod M$$r_{1..k}$$k$增加任何给定的一对不同的串的碰撞的最大概率变为迅速。同样显而易见的是，如何在O （k ）时间内计算每个字符串更改一个字符后所有可能的哈希值。$1/M$$O(k)$

如果您确实想保证统一哈希，则可以为i的每个对（i ，c ）从1到k以及每个字符c生成一个小于M的随机自然数，然后对每个字符串进行哈希x 1 .. k到（∑ k i = 1 r （i ，x i））mod $r(i,c)$$M$$(i,c)$$i$$1$$k$$c$$x_{1..k}$$(\sum_{i=1}^k r(i,x_i) ) \bmod M$。然后任何给定的一对不同的串中的冲突的概率是精确地。如果您的字符集与n相比较小，则此方法更好。$1/M$$n$

此处发布的许多算法在哈希表上占用了大量空间。下面是一个辅助存储ø （（Ñ LG Ñ ）⋅ ķ 2）运行时简单的算法。$O(1)$$O((n \lg n) \cdot k^2)$

诀窍是使用，它是两个值a和b之间的比较器，如果a < b（按字典顺序），则返回true，而忽略第k个字符。那么算法如下。$C_k(a, b)$$a$$b$$a < b$$k$

首先，只需定期对字符串进行排序并进行线性扫描即可删除所有重复项。

然后，对于每个：$k$

1. 使用作为比较器对字符串进行排序。$C_k$

2. 现在仅相差字符串相邻，并且可以在线性扫描中检测到。$k$

长度为k的两个字符串（一个字符不同）共享长度为l的前缀和长度为m的后缀，使得k = l + m + 1。

由西蒙·普林斯答案通过存储所有前缀/后缀组合明确，即编码此abc变*bc，a*c和ab*。那是k = 3，l = 0,1,2和m = 2,1,0。

正如valarMorghulis指出的那样，您可以在前缀树中组织单词。还有非常相似的后缀树。在每个前缀或后缀下增加叶子节点的数量来扩展树是相当容易的。插入新单词时，可以在O（k）中进行更新。

想要这些同级计数的原因是，您知道给定一个新词是要枚举具有相同前缀的所有字符串还是要枚举具有相同后缀的所有字符串。例如，以“ abc”作为输入，可能的前缀为“”，“ a”和“ ab”，而相应的后缀为“ bc”，“ c”和“”。显而易见，对于短后缀，最好在前缀树中枚举同级，反之亦然。

正如@einpoklum指出的那样，所有字符串都可能共享相同的k / 2前缀。对于这种方法来说这不是问题。前缀树将是线性的，直到深度k / 2，每个节点直到k / 2深度都是100.000个叶节点的祖先。结果，后缀树将使用到（k / 2-1）深度，这很好，因为字符串必须共享前缀，因此后缀必须有所不同。

[编辑]作为一种优化，一旦确定了字符串的最短唯一前缀，便知道如果存在一个不同的字符，则该字符必须是该前缀的最后一个字符，并且您会发现当检查一个短一点的前缀。因此，如果“ abcde”具有最短的唯一前缀“ abc”，则意味着还有其他以“ ab？”开头的字符串。但不能使用“ abc”。即，如果它们仅在一个字符上有所不同，那将是第三个字符。您不再需要检查“ abc？e”。

按照相同的逻辑，如果您发现“ cde”是唯一的最短后缀，那么您知道只需要检查长度为2的“ ab”前缀，而不是长度为1或3的前缀。

请注意，此方法仅适用于仅一个字符差异，而不能泛化为2个字符差异，它依赖于一个字符是相同前缀和相同后缀之间的分隔。

Storing strings in buckets is a good way (there are already different answers outlining this).

An alternative solution could be to store strings in a sorted list. The trick is to sort by a locality-sensitive hashing algorithm. This is a hash algorithm which yields similar results when the input is similar[1].

Each time you want to investigate a string, you could calculate its hash and lookup the position of that hash in your sorted list (taking $O(log(n))$ for arrays or $O(n)$ for linked lists). If you find that the neighbours (considering all close neighbours, not only those with an index of +/- 1) of that position are similar (off by one character) you found your match. If there are no similar strings, you can insert the new string at the position you found (which takes $O(1)$ for linked lists and $O(n)$ for arrays).

One possible locality-sensitive hashing algorithm could be Nilsimsa (with open source implementation available for example in python).

[1]: Note that often hash algorithms, like SHA1, are designed for the opposite: producing greatly differing hashes for similar, but not equal inputs.

Disclaimer: To be honest, I would personally implement one of the nested/tree-organized bucket-solutions for a production application. However, the sorted list idea struck me as an interesting alternative. Note that this algorithm highly depends on the choosen hash algorithm. Nilsimsa is one algorithm I found - there are many more though (for example TLSH, Ssdeep and Sdhash). I haven't verified that Nilsimsa works with my outlined algorithm.

One could achieve the solution in $O(nk+ n^2)$ time and $O(nk)$ space using enhanced suffix arrays (Suffix array along with the LCP array) that allows constant time LCP (Longest Common Prefix) query (i.e. Given two indices of a string, what is the length of the longest prefix of the suffixes starting at those indices). Here, we could take advantage of the fact that all strings are of equal length. Specifically,

1. Build the enhanced suffix array of all the $n$ strings concatenated together. Let $X = x_1.x_2.x_3 .... x_n$ where $x_i, \forall 1 \le i \le n$ is a string in the collection. Build the suffix array and LCP array for $X$.

2. Now each $x_i$ starts at position $(i-1)k$ in the zero-based indexing. For each string $x_i$, take LCP with each of the string $x_j$ such that $j<i$. If LCP goes beyond the end of $x_j$ then $x_i = x_j$. Otherwise, there is a mismatch (say $x_i[p] \ne x_j[p]$); in this case take another LCP starting at the corresponding positions following the mismatch. If the second LCP goes beyond the end of $x_j$ then $x_i$ and $x_j$ differ by only one character; otherwise there are more than one mismatches.

   for (i=2; i<= n; ++i){
       i_pos = (i-1)k;
       for (j=1; j < i; ++j){
           j_pos = (j-1)k;
           lcp_len = LCP (i_pos, j_pos);
           if (lcp_len < k) { // mismatch
               if (lcp_len == k-1) { // mismatch at the last position
               // Output the pair (i, j)
               }
               else {
                 second_lcp_len = LCP (i_pos+lcp_len+1, j_pos+lcp_len+1);
                 if (lcp_len+second_lcp_len>=k-1) { // second lcp goes beyond
                   // Output the pair(i, j)
                 }
               }
           }
       }
   }
   

You could use SDSL library to build the suffix array in compressed form and answer the LCP queries.

Analysis: Building the enhanced suffix array is linear in the length of $X$ i.e. $O(nk)$. Each LCP query takes constant time. Thus, querying time is $O(n^2)$.

Generalisation: This approach can also be generalised to more than one mismatches. In general, running time is $O(nk + qn^2)$ where $q$ is the number of allowed mismatches.

If you wish to remove a string from the collection, instead of checking every $j<i$, you could keep a list of only 'valid' $j$.

One improvement to all the solutions proposed. They all require $O(nk)$ memory in the worst case. You can reduce it by computing hashes of strings with * instead each character, i.e. *bcde, a*cde... and processing at each pass only variants with hash value in certain integer range. F.e. with even hash values in the first pass, and odd hash values in the second one.

You can also use this approach to split the work among multiple CPU/GPU cores.

This is a short version of @SimonPrins' answer not involving hashes.

Assuming none of your strings contain an asterisk:

1. Create a list of size $nk$ where each of your strings occurs in $k$ variations, each having one letter replaced by an asterisk (runtime $\mathcal{O}(nk^2)$)
2. Sort that list (runtime $\mathcal{O}(nk^2\log nk)$)
3. Check for duplicates by comparing subsequent entries of the sorted list (runtime $\mathcal{O}(nk^2)$)

An alternative solution with implicit usage of hashes in Python (can't resist the beauty):

def has_almost_repeats(strings,k):
    variations = [s[:i-1]+'*'+s[i+1:] for s in strings for i in range(k)]
    return len(set(variations))==k*len(strings)

Here is my take on 2+ mismatches finder. Note that in this post I consider each string as circular, f.e. substring of length 2 at index k-1 consists of symbol str[k-1] followed by str[0]. And substring of length 2 at index -1 is the same!

If we have M mismatches between two strings of length k, they have matching substring with length at least $mlen(k,M) = \lceil{k/M}\rceil-1$ since, in the worst case, mismatched symbols split (circular) string into M equal-sized segments. F.e. with k=20 and M=4 the "worst" match may have the pattern abcd*efgh*ijkl*mnop*.

Now, the algorithm for searching all mismatches up to M symbols among strings of k symbols:

• for each i from 0 to k-1
  • split all strings into groups by str[i..i+L-1], where L = mlen(k,M). F.e. if L=4 and you have alphabet of only 4 symbols (from DNA), this will make 256 groups.
  • Groups smaller than ~100 strings can be checked with brute-force algorithm
  • For larger groups, we should perform secondary division:
    • Remove from every string in the group L symbols we already matched
    • for each j from i-L+1 to k-L-1
      • split all strings into groups by str[i..i+L1-1], where L1 = mlen(k-L,M). F.e. if k=20, M=4, alphabet of 4 symbols, so L=4 and L1=3, this will make 64 groups.
      • the rest is left as exercise for the reader :D

Why we don't start j from 0? Because we already made these groups with the same value of i, so job with j<=i-L will be exactly equivalent to job with i and j values swapped.

Further optimizations:

• At every position, also consider strings str[i..i+L-2] & str[i+L]. This only doubles amount of jobs created, but allows to increase L by 1 (if my math is correct). So, f.e. instead of 256 groups, you will split data into 1024 groups.
• If some $L[i]$ becomes too small, we can always use the * trick: for each i in in 0..k-1, remove i'th symbol from each string and create job searching for M-1 mismatches in those strings of length k-1.

I work everyday on inventing and optimizing algos, so if you need every last bit of performance, that is the plan:

• Check with * in each position independently, i.e. instead of single job processing n*k string variants - start k independent jobs each checking n strings. You can spread these k jobs among multiple CPU/GPU cores. This is especially important if you are going to check 2+ char diffs. Smaller job size will also improve cache locality, which by itself can make program 10x faster.
• If you are going to use hash tables, use your own implementation employing linear probing and ~50% load factor. It's fast and pretty easy to implement. Or use an existing implementation with open addressing. STL hash tables are slow due to use of separate chaining.
• You may try to prefilter data using 3-state Bloom filter (distinguishing 0/1/1+ occurrences) as proposed by @AlexReynolds.
• For each i from 0 to k-1 run the following job:
  • Generate 8-byte structs containing 4-5 byte hash of each string (with * at i-th position) and string index, and then either sort them or build hash table from these records.

For sorting, you may try the following combo:

• first pass is MSD radix sort in 64-256 ways employing TLB trick
• second pass is MSD radix sort in 256-1024 ways w/o TLB trick (64K ways total)
• third pass is insertion sort to fix remaining inconsistencies