匹配大型文本数据集-如何更快地进行？

Question

我现在正在努力寻找一种最好的方法，无论是从逻辑上还是技术上，同时尝试以连续，轮换的方式匹配两组大型文本，这是我的最佳选择。

一方面，我们有歌曲及其歌词（大约3000万行文本，每行约1000个字符），另一方面，我们有歌曲歌词类别（约20K，每行约50个字符）。 歌曲歌词类别指的是歌曲的含义。

应该将每首歌分配到一个或多个类别，而我的观察方式只能通过将每个类别中单词的相关性与歌曲的歌词进行对比，然后选择一个来完成。拥有最高的全文搜索得分（对于具有相同最高得分的那些，则得分大于或等于1个类别），并考虑了适当的全文搜索引擎的同义词，词干，停用词以及所有的花哨信息。 如果您有更好的方法来解决此问题，请随时给我提示。

作为一个示例，根据其歌词，歌曲“ Unchained Melody”应归为以下类别：

• 情歌
  • 为了我的宝贝，我的爱
    • 感觉孤独

它的歌词确实包含了该类别（其整个路径）中包含的所有这些词，包括它们的变形和同义词，因此多次出现，因此该类别的文本应与歌曲的文本排名相当。

那么问题是，使用哪种可能的方法将所有这些类别文本与所有这些歌曲文本进行匹配？

请记住，自然地，如今每天都会发布成千上万首歌曲，而且类别的变化和改进甚至有很大的机会。

到目前为止，我已经尝试了以下方法：

1. SQL Server 2014保存这些类别，并链接到一个Sphinx搜索引擎，该引擎将歌词文本保存在其全文索引中。 在这些应用程序之上构建的应用程序对单个歌曲文本执行20K查询（即，获取每个类别与歌曲文本的相关性），并选择排名最佳的结果。 这意味着20K * 30M查询所有要匹配的歌曲。 当然，这需要在40核心计算机+ 256 GB RAM上使用的时间，并且到那时，将出现新歌曲，并且可能会更改/更新类别的结构。

2. 这很有趣：SQL Server 2014保存歌曲歌词，并链接到保存类别文本的Sphinx。 通过将歌曲文本拆分成单词，并在它们之间使用“或”运算符，可以创建与每首歌曲的类别相匹配的查询，如果在一行中找到更多单词，则结果排名会更高（包含类别文本和完整文本路径）。 结果是：速度更快，因为每首歌曲只有1个大查询才能获得其最高排名，但仍然不够快，而且准确性稍差。

3. SQL Server 2014同时拥有歌曲歌词和类别，并启用了全文搜索，而对有限的类别集使用第一种方法（没有Sphinx，仅SQL的FT）时，首先使用第二种方法（同样，没有Sphinx，仅是SQL的FT），所有内容分为数百个异步批处理工作。 因此，它是上述两者的结合。 结果：更准确，并且具有全部功能，但速度更快，但仍不足以达到我认为的可能。 匹配所有歌曲和歌词大约需要3天。

如果您有其他可以尝试的想法，我将不胜感激。 我对准确性（40％）和速度（60％）感兴趣，并且我真的觉得有更简单的方法可以完成这项工作。

Answer 1

就个人而言，我可能会坚持使用1.，但有两个改进

批处理更新 ，而不是简单地针对每个类别/文档组合运行一个查询。 对每个类别运行一个查询-并获取所有文档的结果。 较小的查询。 您可以进行一些优化，以使这些“大”查询效率更高。

Delta Updates （而不是每个周期）仅运行“完整”过程，而是定期使用单独的较小且特定的系统。 一位知道如何运行更有针对性的更新以避免重复工作的人。 例如：

1. 在您添加新类别后，只需运行其大查询即可找到该类别的文档。 删除的类别只会删除记录。 对类别的“编辑”可以是删除，然后是插入。

2. 新文档也可以是特殊的狮身人面像索引，仅包含新文档（main + delta索引系统可能已经提供了！）。 然后针对这个较小的增量索引针对每个类别运行主查询。

3. 甚至可以使用“投机”系统来减少您需要运行的类别的数量。 例如，将类别中的所有单词合并为BuildKeyword批量调用。 这可以使您获得每个单词的点击数，从而可以排除没有匹配项的类别（因此，对于许多类别，无需运行主查询）

...更聪明地工作，而不是更努力