Lucene 具有多索引和复杂要求的全文搜索

我们正在构建一个应用程序，它将要求我们为每个用户的数据编制索引，以便我们能够对他们的数据进行全文搜索。以下是有关该应用程序的一些值得注意的事项：

A） 每个用户的数据与其他用户完全无关。这给了我们一些好处：

我们可以将索引保持在较小的范围内 尺寸

合并/兼容碎片索引 将花费更少的时间

如果某些索引变得不可访问 无论出于何种原因（腐败？）， 只有那些用户才会受到影响。 其他用户不受影响，并且 为他们提供服务

B） 每个用户可以有几个不同类型的数据。出于与上述相同的原因，我们希望将每种类型保存在单独的文件夹中

因此，我们的索引层次结构将类似于：

/user1/type1/

/user1/type2/

/user2/type1/

/user3/type3/

C） 通常，我们可能会在每个iCreation中添加可以索引的“类型”数据。
因此，我们希望有一种高效的/编程的方式来为不同的“类型”添加模式。我们希望避免使用固定的索引模式。我喜欢Lucene的无模式索引方法

D） 用户可以启动搜索查询，该查询将搜索： -在该用户的特定“类型”内 -针对该用户的所有类型：在本例中，我们希望触发类似Lucene的并行查询。（）

E） 我们需要对索引进行实时更新。这是必须的

F） 我们正计划在多台机器上共享索引。为此，我们还需要：
如果碎片变得不可访问，则只有数据位于该碎片中的用户才会受到影响。其他用户得到不间断的服务

我们正在考虑Lucene、Sphinx和Solr来做这件事。这就是我们发现的：

• 斯芬克斯：没有有效的方法来做A，B， C、 还是有
• 卢埃克：一切看起来都是可能的，就像 这是非常低的水平。但我们必须 编写包装器来完成F和构建 网络间的通信层 服务器和搜索服务器
• 索尔：不确定我们是否能做A，B，C 很容易。我们可以吗

---

所以，我的问题是，对于上述要求，什么是最好的软件？如果我们能满足所有的要求，我更倾向于Solr，然后是Lucene。

我看不出Solr能够处理A或B，因为Solr的模型是将所有内容都放在一个索引中（每个碎片核心）。如果使用。尽管Solr可以进行实时索引，但它的速度不如Lucene（根据我的经验，即使使用嵌入式Solr）。所有这些都表明Lucene是您唯一的选择。

我认为Solr在这里可能非常适合您

Solr的关键特性是核心的概念，它将在您的定位中很好地为您服务。看

实现这一点的一种方法是，每个用户/类型组合都可以是一个单独的Solr核心。这满足（A）和（B）。客户端可以在单个核心上直接搜索，也可以一次在多个核心上直接搜索（在不同的Solr服务器上可选），这是您在单个用户和所有类型上搜索时所需要的。这满足（D）和（F）。或者，您可以为每个用户提供一个核心，并提供一个“类型”字段，您可以对其进行筛选

至于（C），Solr有动态场的概念。看

---

就（E）而言，Solr还没有“真正的”实时索引。但是如果几秒钟的延迟是可以接受的，那么Solr可以处理这个问题。

如果用户数量相当多，你认为Solr不会抱怨吗？在不影响性能的情况下，理想的内核数是多少？它能支持B中提到的文件夹结构吗？Solr是为高容量而设计的，所以我不会担心大量的用户。始终可以向外扩展到多个节点。至于核心问题，我不认为数量太多是个问题，尽管它值得测试。我知道保持索引打开有一些最小的内存开销，您可能需要为打开的文件句柄设置ulimit。Re：文件夹结构，它可能不完全允许这种结构，但您可以接近它。每个核心至少有一个目录。请参阅。看起来主要的问题是能够有效地打开和关闭很多内核。读完这篇文章后，我真的很害怕现在使用Solr。。。顺便说一句，我们将在这个项目中使用AmazonEC2实例。。。我们会有很多实例，并且更喜欢将索引分布在实例上……Solr支持多个节点上的多个核心，因此在EC2bajafresh4life中，它可以在多个实例上正常工作。使用大量核心的建议是人们没有想到的（出于某种原因，我想到了另一台服务器上的核心==碎片）.这会改变你现在的立场吗？严格按照你的问题规格（A到F）我认为Lucene是最好的选择，因为它给了你最大的灵活性。然而，我不相信你真的需要为每个用户单独的索引文件，或者需要担心（A），因为这似乎是过早的优化。Solr在Lucene上为您提供了很多免费的东西（Solr需要的代码行要少得多），但它迫使您以Solr的方式做事。我重新编写了一个应用程序，它使用纯Lucene来使用Solr，虽然理解和欣赏Solr的工作方式确实需要一段时间，但最终的结果是用户体验要好得多。