Question

开始的位置是这样的：我有一堆documents（40,000+）中包含简历（CV）。这些是相当大的嵌套对象，其中包含许多相关且不相关的信息。为了提供搜索而不解析整个文档，我考虑了另一个仅包含这些简历相关数据的集合。但是，有些术语比其他术语更重要，因此应给予较高的评价。总共有3个相关级别，例如“ Java”一词的计数应比在项目描述中发现的计数高3倍，而在CV的 focus部分中发现的计数应高5倍。

现在我有三种方法。 第一个为每个术语创建一个新文档，如下所示：

{ cvID: 1234,
  term: "java",
  count: 5 
}

{ cvID: 1234,
  term: "javascript",
  count: 3 
}

{ cvID: 1234,
  term: "html",
  count: 1 
}

如果我们假设有40,000个CV，每个500个词，那么将产生20,000,000个文档。我猜由于cvId的重复，这将是MapReduce的合适方案。但是，关于不必要的冗余，感觉不对。另一方面，NoSQL设计通常是关于冗余的很多次。

第二种方法是每个简历仅一个文档，每个相关性包含三个数组，其中包含这样的术语

{ cvId: 1234,
  terms_count5: ["java"],
  terms_count3: ["javascript"],
  terms_count1: ["html"] 
}

这将导致与CV一样数量的文档。包含搜索，MapReduce可能没有太大意义，因为没有什么可减少的。我认为aggregation是解决问题的方法，尽管这可能会有些棘手，尤其是当要搜索多个术语并且必须将所有这些相关性值相加时。

第三种方法是将所有内容颠倒过来，每个术语创建一个文档，并添加可以找到这些术语的简历，频率（次数）和相关程度（计数））。

 { term: "java",
   cvIds: [ {id: 4321, count: 5, times: 3} ]
 }

很大的缺点：每当简历更改为500个术语时，我们需要一次更新500个文档。就我们而言，简历可能会经常变化。

如果其中一种解决方案不可行，或者有第四种或第五种解决方案可以更好地解决我们的问题，那么我很乐意阅读任何建议。

PS .：没有时间和金钱来建立像Solr这样的专用搜索服务器。我们更喜欢MongoDB中的解决方案。

MongoDB中搜索索引收集的性能评估

0 个答案: