架构：数据持久性，搜索和推荐系统

Question

我正在计划一个涉及数据持久性，搜索功能和推荐功能（协作过滤）的项目。

如图所示，我在想：

1）拥有一套微服务来处理将在NoSQL存储中持久保存的实体（可能是MongoDb）

2）对于搜索功能，我将使用Slor，来自微服务的消息将用于更新Slor索引。

3）对于建议，我正在考虑使用Apache Mahout并使用message-queue来更新Mahout中使用的Slor索引

我的问题是：

1）这是处理这类问题的正确架构吗？

2）是否需要3个数据存储：MongoDB用于数据存储，Slor（Lucene索引）用于搜索，而Solr（Lucene Index）用于mahout用于推荐？

3）由于Slor也是NoSQL解决方案，在不使用MongoDB的情况下将Solr用于持久性和搜索功能有什么缺点？

4）如果我想使用Hadoop或Apache Sparks进行分析，这涉及引入另一个数据存储？

Answer 1

这种架构似乎很合理。您可以使用相同的Solr群集进行常规搜索以及推荐者搜索。如果要将自己的数据输入写入Spark，可以实现一种从MongoDB实例化Mahout IndexedDataset的方法。已经存在一个伴随对象，用于将（String，String）的PairRDD作为单个事件的输入并创建IndexedDataset。这将消除对HDFS的需求。

Spark保存临时文件，但不需要HDFS进行存储。如果您正在使用AWS，您可以将Spark再培训工作放到EMR上，进行培训，然后拆除。

所以答案是：

1. 是的，看起来很合理。您应该始终将事件流保存在一些安全的存储空间中。

2. 不，只要你能从MongoDB读取到Spark，就只需要MongoDB和Solr。这将在推荐人培训代码中使用Mahout的Spark代码进行相似性分析。发生

3. 没有已知的缺点，不确定性能或支出权衡。

4. 您必须使用来自Mahout的Spark for SimilarityAnalysis.cooccurrence，因为它实现了新的“相关交叉发生”（CCO）算法，该算法将极大地提高您使用不同形式的用户数据的能力，从而增加建议的质量。如果使用MongoDB或Solr提供事件，Spark不需要HDFS存储。

BTW：ActionML有助于数据科学部分，我们可以帮助您确定哪些用户信息最具预测性。我们创建了CCO的第一个开源实现。通过包含正确的CCO数据（远远高于Netflix奖10％），我们看到了推荐质量的大幅提升。我们还支持上述架构的PredictionIO实现。我们编写了基于Mahout（我是Mahout提交者）的Universal Recommender，但它比从头开始构建系统更加交钥匙，但是我们的分析帮助与实现无关，可能对数据科学部分有帮助。项目。 ActionML.com，Universal Recommender here。一切都是免费的OSS。