我正在创建一个仅用作terms filter的查找索引。因此，无需搜索/汇总，只需进行过滤和GET即可。
我正在讨论此查找索引的结构，每个文档是否应包含要过滤的所有字段全部，还是应该为每个字段创建索引。
例如，假设每个文档都与一个用户有关。每个用户都有他们玩过的游戏，看过的书和看过的电影的列表。在搜索游戏/书籍/电影推荐时，我将使用过滤器一词来过滤掉它们已经与之互动的那些物品。
我想知道是否应该有一个包含文档映射的查找索引，例如：
users_index
{
'game_ids': [],
'movie_ids' : [],
'book_ids': []
}
或一个索引 per 查找值，例如：
user_games_index
{
'game_ids': []
}
user_movies_index
{
'movie_ids': []
}
user_books_index
{
'book_ids': []
}
一个索引的优点：
多个索引的优点：
根据update api docs，更新文档意味着首先检索整个文档。我将大量更新每个文档，这些数组可能会变得很大（请考虑数千个id）。然后更新书本ID将检索所有游戏ID，这会占用内存。如果它们在不同的索引中，则可以避免。
在事情结束时更容易维护
我应该注意，如果我使用多个索引，那么它将只有4个或5个，每个索引大约有50万个文档。另外，每个索引只有1个主分片，没有副本，而且我在单个m5.2xlarge EC2实例（8个内核，32G ram）上。
这些统计信息是否太小，以至于在这一点上并没有什么关系，还是我应该赞成一个或多个指数？
答案 0 :(得分：0)
第三个选项怎么样？
您有一个索引，索引中的每个文档看起来都像这样：
\b为什么？由于您说用户的游戏，电影或书籍会经常更新，因此该方法使您可以轻松地为用户添加/删除单个电影，游戏或书籍。
您还可以轻松过滤特定用户的书籍/电影/游戏。
所有值的类型均为“关键字”，并且过滤应快速。
PS：ES索引的“良好”映射将尝试最大程度地减少单个文档的更新次数，而是在插入/删除文档的级别上工作，因为与查找和更新文档相比，ES可以很好地完成此任务。
编辑：我添加了查询示例，以说明如何使用布尔查询过滤出结果。
示例：
获取_search
{
"user_id" : "some_user",
"document_type" : "movie" or "game" or "book"
"document_id" : "id of movie, game or book"
}
获取_search
{
"query": {
"bool": {
"must_not":{
"term" : {
"user_id" : "user X"
}
}
}
}
}