我们已经开始在我们的项目中使用elasticsearch，我们将用户数据和他的朋友列表存储为嵌套对象，并嵌套到存储朋友朋友列表的嵌套对象中，因为我们在进行全局搜索时需要这些数据。现在我们正在将这些数据与我们的数据库实时同步，所以这对实时同步 50-100 TPS 是否有好处，否则将来会产生问题。
我们需要创建复杂的查询来更新数据，因为我们在第二级管理朋友列表。那么如何轻松创建高级脚本，我已经在 Google 中检查过，但没有找到任何详细信息。
如果我的做法是错误的，请告诉我。
问问题
457 次
1 回答
2
回答你的第一个问题
所以这对实时同步 50-100 TPS 有好处吗，否则将来会产生问题
从 ES6.0 版本开始，自动支持和检测多级嵌套，如果内部嵌套查询存在于另一个嵌套查询中，则会自动匹配相关嵌套级别（而不是根）。但是有一个警告，索引一个包含 100 个嵌套字段的文档实际上索引了 101 个文档，因为每个嵌套文档都被索引为一个单独的文档。为了防止错误定义的映射，每个索引可以定义的嵌套字段的数量通常限制为 50，使用index.mapping.nested_fields.limit. 此设置允许您限制可以手动或动态创建的字段映射的数量，以防止不良文档导致映射爆炸。因此，回答您的问题，这很好，但随着数据的增长，管理变得更加复杂，并且您冒着映射爆炸的危险。
回答你的第二个问题
我们需要创建复杂的查询来更新数据，因为我们在第二级管理朋友列表。那么如何轻松创建高级脚本，我已经在 Google 中检查过，但没有找到任何详细信息。
您可能需要在此处提供一些上下文，以便能够理解为什么您的方法是必要的，但基本上，在社交资料上下文中，像您一样管理朋友列表总是一个坏主意，特别是如果您预计将来会扩展. 它可能适用于较小的用例，但在扩展时效果不佳。这是因为，关系变得更加复杂，最终您将拥有太多的多嵌套对象。如前所述，所有因素都保持不变，您可能希望针对这种情况查看图形数据库。但是，您的方法可能还有其他原因，这就是为什么您可能想要列举您的上下文以便我们更好地提供建议的原因。
希望这可以帮助！！
于 2017-11-16T12:13:52.087 回答