确定数据库中项目之间的相似性答案

【问题标题】：Determining the Similarity Between Items in a Database确定数据库中项目之间的相似性
【发布时间】：2023-03-14 13:49:01
【问题描述】：

我们有一个包含数亿条日志数据记录的数据库。我们正在尝试将此日志数据“分组”为可能与日志数据库中的其他条目具有相同性质。例如：

记录 X 可能包含如下日志条目：

更改分配给服务器 US91 的事务 ABC123

并且记录 Y 可能包含如下日志条目：

更改分配给服务器 GB47 的事务 XYZ789

对于我们人类来说，这两个日志条目很容易识别为可能以某种方式相关。现在，记录 X 和记录 Y 之间可能有 1000 万行。可能还有数千个与 X 和 Y 相似的其他条目，有些完全不同但有其他相似的记录。

我试图确定的是将相似项目组合在一起的最佳方法，并以 XX% 的确定性表示，记录 X 和记录 Y 可能具有相同的性质。或者更好的说法可能是系统会查看记录 Y，并根据您的内容说您最像记录 X，与所有其他记录并列。

我看到有人提到自然语言处理和其他查找字符串之间相似性的方法（例如暴力破解一些 Levenshtein 计算） - 但是对我们来说，我们还有这两个额外的挑战：

感谢您的意见！

【问题讨论】：

您有一些看起来不同的示例记录吗？对我来说，这听起来像是一个聚类问题。
我建议聘请统计学家/“数据科学家”。
我不同意这是“没有建设性的”。困难也许；人们当然可以要求更多地考虑什么会/不会被认为是相似的，以及如何对相似性进行“排名”......但话又说回来，人们可能会很容易地寻求解决方案。

【解决方案1】：

有趣的问题。显然，这里存在规模问题，因为您真的不想开始将每条记录与数据库中的每条记录进行比较。我相信我会考虑增加一个“已知类型”列表并针对该列表中的类型对记录进行评分，以查看每条记录是否在该列表中具有匹配项。

“得分”部分有望在这里得出一些好的答案——你对已知类型得分的能力是让它运作良好的关键，我感觉你的处境比我们要好没错。也许是某种声音匹配？或者，如果您能弄清楚如何“发现”新记录的哪些部分发生了变化，您可以将已知类型定义为正则表达式。

此时，对于每条记录，您有望确定您有匹配（置信度高）或匹配（置信度较低）或很可能根本没有匹配。在最后一种情况下，您很可能找到了应该添加到“已知类型”列表中的新“类型”。如果您跟踪匹配的每条记录的分数，您还可以返回低分匹配，看看在您的处理过程中是否出现了更好的匹配。

【讨论】：

【解决方案2】：

我建议使用像 Lucene 这样的文本搜索引擎来索引您的数据，以将您的日志条目拆分为术语。由于您的数据是机器生成的，因此也可以使用单词 bigrams 和 tigrams，甚至更高阶的 n-grams。二元组只是一系列连续的单词，在您的示例中，您将拥有以下二元组：

Change_Transaction、Transaction_XYZ789、XYZ789_Assigned、Assigned_To、To_Server、Server_GB47

对于以类似方式准备查询的每个日志，搜索引擎可能会为您提供最相似的结果。您可能需要稍微调整相似度函数以获得最佳结果，但我相信这是一个好的开始。

【讨论】：

【解决方案3】：

我想到了两个主要策略：

临时的。使用信息检索方法。为日志条目建立索引，最终使用专门的标记器/解析器，将它们输入常规的文本搜索引擎。我听说有人用 Xapian 和 Lucene 来做这件事。然后您可以“搜索”新的日志记录，文本搜索引擎将（希望）返回一些相关的日志条目以进行比较。然而，通常“信息检索”方法只对找到 10 个最相似的结果感兴趣。
聚类方法。您通常需要将数据转换为数字向量（但可能是稀疏的），例如作为 TF-IDF。然后，您可以应用聚类算法来查找密切相关的线条组（例如您上面给出的示例），并研究它们的性质。你可能需要稍微调整一下，所以它不会，例如服务器 ID 上的集群。

这两种策略都有其起伏。第一个非常快，但是它总是会返回一些类似的现有日志行，而没有太多关于该行有多常见的数量。它主要用于人工检查。

第二种策略计算量更大，并且根据您的参数可能会完全失败（因此可能首先在子集上进行测试），但也可以通过实际构建大量密切相关的日志条目来提供更有用的结果.

【讨论】：

【解决方案4】：

听起来您可以采用上述 lucene 方法，然后将其用作机器学习库 Mahout (http://mahout.apache.org/) 的输入向量源。在那里，您可以训练分类器，或者只使用其中一种聚类算法。

【讨论】：

【解决方案5】：

如果您的 DBMS 有，请查看 SOUNDEX()。

【讨论】：