我一直在读Elasticsearch中的映射,这里有一些我发现的有趣的东西
Field names with the same name across types are highly recommended to have
the same type and same mapping characteristics (analysis settings for
example). There is an effort to allow to explicitly "choose" which field to
use by using type prefix (my_type.my_field), but it’s not complete, and there
are places where it will never work (like faceting on the field).
我在文档here
中找到了上述引用现在我的用例正是如此......这是一个例子。假设tenant1中的some field
必须具有以下映射(对于给定的实体用户):
{
"tenantId1_user": {
"properties": {
"someField": {
"type": "string",
"index":"analyzed"
}
}
}
}
现在,对于不同租户中的相同字段(对于相同的实体类型,假设用户),类型必须改变如下:
{
"tenantId2_user": {
"properties": {
"someField": {
"type": "int",
"index":"analyzed"
}
}
}
}
现在从我从上面的引文中理解,这意味着技术上即使我可以提供这种映射,也不建议这样做,因为内心深处Lucene以相同的方式处理它们。
我的问题是:
1)我如何处理我的用例?我是否应该将每个租户分成不同的索引,以便我不必担心这种映射?
2)还有其他解决方法吗?考虑到如果我有太多租户意味着我会有太多的指数?
3)这个用例的推荐方法是什么?
所有帮助表示赞赏!
答案 0 :(得分:2)
在您的方案中,您应该为每个租户使用一个索引。
AFAIK,对群集中的索引数量没有限制 - 只有"自然"根据可用的物理资源限制。
此外,每个租户拥有独特的指数将使每个租户更少"惊人的"搜索结果。如果它们在同一索引中,则TF-IDF评分将受到所有其他租户文档中搜索词出现频率的偏差。
附注(基于IRC中提出的其他问题):接收索引请求或搜索请求的任何节点都具有指定哪些节点具有哪些索引的分片的集群元数据,因此仅将请求转发到适当的节点。另外,不要担心每个节点上的每个索引都有分片。在本身中,该模型不会对您的部署做出任何有用的贡献。