为搜索和索引选择正确的解决方案

Question

我们正在致力于无头应用程序的设计和开发。目前，我们面临**architectural question**，我们需要找到答案才能继续设计系统，我们不是**search engine**的专家，但我们正在研究这方面。

我们的技术stack is .net Core/SQL Server 未来我们可能会plan to use Raven DB.

我们计划不使用内容交付 API，而是使用Query based content delivery 使其更加灵活，并减少每个前端框架的 API 开发开销。我们决定对大部分数据管理使用索引和索引，即减少数据库负载。所以基本上大部分内容操作都会使用索引来处理。

我们在搜索引擎中观察到的问题： 在第一次剪辑时，我们计划使用Elastic Search，但我们再次理解了以下issues。

系统将有一个dynamic field management and field data management，即用户将在系统运行时编辑字段和字段值。每次我们可能需要重建索引以更新弹性搜索中的字段（我们不是搜索引擎专家），这会增加网络负载，这对于我们在大型多租户环境中操作可能不可行。

所以我们decided to go with Lucene.net，但在继续lucene.net 之前，我们要确保可以解决以下问题。

动态更新字段而不每次都重新构建索引，lucene 是否支持这一点，或者我们可以自定义来管理它吗？

第二个问题是使用分布式架构为每个租户管理单独的索引。

我们计划为生产中的每个租户建立一个分区，这样数据就不会位于单个索引中。这是因为我们不需要在 Web 服务器上放置高负载来管理基于权限的查询结果，相反，Lucene 会这样做。所以对于任何查询结果都将根据查询它的用户的权限返回，因此最好为每个租户建立单独的索引以减少操作。

是否可以通过为每个租户专门设置一个分区来实现分布式 Lucene？

请帮助我们为我们目前面临的上述两个问题找到解决方案。

Answer 1

Elasticsearch 内部仅使用 Lucene，每个 elasticsearch 索引（由一个或多个分片组成）在内部都是一个 Lucene 索引。 您甚至可以将 Elasticsearch 视为分布式 Lucene，它可以轻松扩展到数千台物理服务器。

现在，这应该可以消除您的任何疑问，因为所有低级操作（例如更新文档和删除文档）都是由 Lucene 内部完成的，以防 Elasticsearch 是您问题的第 1 部分。

您的第一个问题

问：动态更新字段而不每次都重建索引，Lucene 是否支持这一点，或者我们可以自定义来管理它吗？

您只是在更新单个文档，它不会导致整个索引重建，您将在 1 秒内获得更新的文档（默认 refresh interval），或者如果您想要立即更新文档，您可以执行显式刷新（不推荐）。

关于第二个问题：

问：是否可以通过为每个租户专门设置一个分区来实现分布式 Lucene？

Answer：正如解释的那样，您可以将 Elasticsearch 仅视为分布式 Lucence，并且可以轻松地为每个租户创建单独的索引，并且它们不会与其他数据交互（尽管如果您在同一个 Elasticsearch 上存储多个索引集群不会有基础设施资源隔离（CPU，内存））等，你可以得到嘈杂的邻居问题。