我们一直在使用Elasticsearch向我们网站的读者提供大约700,000条内容，但有些情况已经发生变化，我们需要弄清楚该服务能否适应我们。 ..（对不起，这篇文章很长，我试着预测所有问题！）
我们使用Elasticsearch来存储我们内容的“快照”，以避免重复工作并减慢我们的应用，方法是让他们获取数据并从我们的内容API中解析所有资源。我们还利用Elasticsearch的搜索API以各种方式检索内容。
为了维护我们集群中的内容，我们运行一项服务，该服务从我们的API接收内容更改通知，触发内容“摄取”（获取数据，进行任何必要的转换并为其编制索引）。同一服务还会定期“重新提取”内容。通常情况下，新的内容将在发布后的30秒内被摄取，并在此后每5天左右触摸一次。
我们的应用程序用于检索内容的最常用方法是“标记”。我们有列表页面按标签查看内容，我们的用户可以订阅标签的内容更新。每条内容都有一个或多个标签。
标签有几个属性： - ID，名称，分类以及它与内容的关系。它们被编入索引作为嵌套对象，以便我们可以聚合它们等。
这就是它变得有趣的地方......标签曾经是不可变的，但我们最近更改了元数据系统，现在它们可能会更改 - 名称将更新，ID可能会随着移动分类等而变化。
我们有大约65,000个标签在使用，其中绝大多数仅在相对较小的数量中使用。如果这些标签发生变化，我们可以触发所有相关内容的重新发布，而无需对我们的基础架构进行任何更改。
但是，我们也有一些非常常见的标签，其中最受欢迎的标签使用超过180,000次。我们刚刚收到警告，其他一些有数万份文件的人会发生变化！因此，我们需要能够在现在和将来应对这些更新。
触发所有关联内容的重新加载并将其排队不是问题，但这可能需要一段时间，在某些情况下至少需要3-5小时，我们希望尝试避免我们的列表页面成为发生这种情况时会出现孤立或重复的现象。
如果你已经走到这一步，谢谢！我有两个问题：
由于
答案 0 :(得分：0)