我们正在构建一个应用程序，要求我们为每个用户编制索引数据，以便我们可以对其数据进行全文搜索 . 以下是有关应用程序的一些值得注意的事项：
A）每个用户的数据与其他每个用户完全无关 . 这给我们带来了一些好处：
-
我们可以保持索引的小小 .
-
合并/合并碎片索引将花费更少的时间 .
-
如果某些索引由于某种原因（腐败？）而无法访问，则只有那些用户受到影响 . 其他用户不受影响，并且可以为他们提供服务 .
B）每个用户可以拥有很少的不同类型的数据 . 我们希望将每种类型保存在单独的文件夹中，原因与上述相同 .
因此，我们的索引层次结构将类似于：/user1/type1/<index files> /user1/type2/<index files> /user2/type1/<index files> /user3/type3/<index files>
C）通常，可能在每次迭代时，我们都会添加可以编制索引的数据 .
所以我们希望有一种有效/程序化的方法来为不同的"types"添加模式 . 我们希望避免使用固定的索引模式 . 我喜欢Lucene的无模式索引方法 .
D）用户可以触发搜索查询，这些搜索查询将搜索： - 在该用户的特定"type"内 - 对于该用户的所有类型：在这种情况下，我们想要像Lucene一样触发并行查询 . （ParallelMultiSearcher）
E）我们要求索引的实时更新 . 这是必须的 .
F）我们计划在多台机器上对索引进行分片 . 为此，我们希望：
如果分片变得不可访问，则只有那些数据驻留在该分片中的用户才会受到影响 . 其他用户获得不间断的服务 .
我们正在考虑Lucene，Sphinx和Solr这样做 . 这是我们发现的：
-
狮身人面像：没有有效的方法去做A，B，C，F . 或者有吗？
-
Luecne：一切看起来都很可能，因为它的水平非常低 . 但我们必须编写包装来执行F并在Web服务器和搜索服务器之间构建通信层 .
-
Solr：不确定我们是否可以轻松地做A，B，C . 我们可以吗？
那么，我的问题是什么是满足上述要求的最佳软件？如果我们满足所有要求，我更倾向于Solr，然后是Lucene .
2 回答
我可以't see Solr being able to handle A or B, as Solr'的模型是将所有内容都放在一个索引中（每个分片核心） . 如果使用dynamic field types，Solr可以处理C.尽管Solr可以进行实时索引，但它并不像Lucene那么快（根据我的经验，即使使用Embedded Solr） . 这一切都指向Lucene是您唯一的选择 .
我认为Solr在这里可能对你很有用 .
Solr的主要特点是在你的场景中适合你，这就是核心的概念 . 见http://wiki.apache.org/solr/CoreAdmin
实现这一点的一种方法是每个用户/类型组合可以是一个单独的Solr核心 . 这满足（A）和（B） . 客户端既可以将搜索引导到单个核心，也可以将搜索引导到多个核心（在不同的Solr服务器上可选），这是您在单个用户和所有类型中搜索时所需的内容 . 这满足（D）和（F） . 或者，您可以为每个用户创建一个核心，并使用可以过滤的“类型”字段 .
至于（C），Solr具有动态场的概念 . 见http://wiki.apache.org/solr/SchemaXml#Dynamic_fields
就（E）而言，Solr还没有“真正的”实时索引 . 但如果几秒钟的延迟是可以接受的，那么Solr可以处理这个问题 .