我有兴趣为在Windows群集中运行的应用程序运行Lucene.NET。搜索问题本身相当小，但仍然需要处理无状态/集群问题。
我理解SOLR处理我的场景（以及更多）但是需要一个servlet容器（和Java）给我带来了一些问题。根据基于Lucene.NET的方法的复杂性，它可能仍然是一个小瓶选项。
我现在的问题是我有哪些选项来处理在多个主机上运行的问题：
坚持共享存储，对所有节点都是通用的？ Lucene.NET会透明地处理并发吗？服务器是否会使用RAM进行缓存，如果是这样，Lucene.NET会根据更新的文件透明地处理这种情况的失效吗？
复制？每个服务器都有自己所需的一切副本。在任何更新中，所有服务器都会获得一个新的副本（如果这相当简单，则为diff）。现有的工具，或由我来处理？
工作负载分区/分片？每个服务器只处理自己的数据，包括读取和更新。处理此问题的工具，加入部分结果等？
我在初步调查时可能错过的其他选择？
在尝试本地版本时，我的Lucene目录大约有几百兆。从长期来看，我可能会看到1-5 GB。如果更新的频率很难，我可以相当灵活地控制它。并发读取/搜索负载预计非常温和。
答案 0 :(得分：0)
您可以将lucene.net与多个服务器一起使用，但必须实现索引服务器。
您所做的所有更改都应排队，并且每次都会对待处理的文档进行索引。你也应该立即索引x项是否在队列中（x取决于你的合并文档设置，这对我来说是25,000）。
上述原因是您需要避免对索引进行小的更改，因为这会因为创建了许多小文件而导致性能超时。您可以运行2个索引服务器，但由于锁定索引，一次只能索引1个，这样做的唯一原因是在第一个服务器发生故障时进行故障转移，这取决于您的需求。
我使用了15Gb的索引，有3000万条记录。我对此的情景是在azure下。
索引更改的1个辅助角色
为每个持有索引的内容提供2到20个网络角色。
每15分钟推送一次更改，索引合并为25,000个更改，每个组合索引包含250,000个文档。每个Web服务器每隔15分钟检查一次blob存储，并锁定索引阅读器，如果下载了更改，则会使其无效。每个文件的最大文档数基本上是为了阻止Web服务器下载大量先前的更改。
我确实使用了Lucene.AzureDirectory，但它在blob存储中检测到更改的blob时不可靠，因此我最终迭代blob并在本地进行比较并根据需要下载。
现在我会再次实现这样的东西吗？答案是一个很大的问题。当你重新发明轮子时，我会使用elasticsearch或solr。