关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗？**更新这个问题，这样就可以通过编辑这篇文章用事实和引文来回答。
上个月关门了。
改进这个问题
裁判：https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html
我们正在为多租户应用程序（例如：大约10000个租户）引入使用elasticsearch的log。我们需要记录个人资料编辑，用户评论，cron活动，分类编辑和大约30多个分类日志。
我找到了两种储存这些日志的方法。
每个租户一个索引
POST tenant-1/_doc
{
"type" : "profile_edits",
"fullname" : "NewName",
"age" : 11,
"score" : 999
...
}
POST tenant-1/_doc
{
"type" : "user_comments",
"user" : "User1",
"comment" : "Nice!"
}这样，我就可以没有索引=没有租户。
租户共享索引
POST profile_edits/_doc
{
"tenant" : 1,
"fullname" : "NewName",
"age" : 11,
"score" : 999
}
POST user_comments/_doc
{
"tenant" : 1,
"user" : "User1",
"comment" : "Nice!"
}这样我总共需要大约35个索引。
哪种方法效果更好？
2条答案
按热度按时间nhjlsmyf1#
这是自以为是的，但基于数据，我建议使用第二种方法，因为您的日志具有非常不同的结构，并且最终会有许多稀疏字段。
如果事情发展得很顺利，你可以使用专门租户的指数，或者引入每日/每周/每月/每年的指数。
wvyml7n52#
同意另一个用户@evaldas的观点，这是基于观点的，但在我看来，以及相当多的大规模es部署经验，我也觉得有基于您的类别的索引，如
profile_edits,user_edits并有一个共同的领域可能是tenant_id这将有助于筛选特定tenant. 很少有人赞成这种方法。你将有相对较少的索引管理开销，而不是10k你只需要管理35个索引。
你仍然可以得到更好的性能，因为你可以有一个过滤器上
tenant_id默认情况下，文件服务器缓存在es中，有关详细信息，请参阅筛选器上下文。集群状态（关于所有碎片和状态的信息）会小得多，虽然在较新的版本中es优化了集群状态的发布，但是如果您使用的是非常旧的版本，它会很有帮助并提供更好的性能。
最后但并非最不重要的一点是，您的用例类似于本官方es博客中讨论的内容，他们还建议避免太多索引，而是建议对它们进行分组，下面是来自同一博客的提示
提示：为了减少索引的数量并避免大型的、杂乱无章的Map，请考虑将具有类似结构的数据存储在同一索引中，而不是根据数据的来源拆分为单独的索引。在索引和碎片的数量以及每个索引的Map大小之间找到一个良好的平衡是很重要的。因为集群状态被加载到每个节点（包括主节点）的堆中，并且堆的数量与索引的数量、每个索引的字段和碎片成正比，所以监视主节点上的堆使用情况并确保它们的大小适当也很重要。