我有一个具有以下结构的聚合的对象:
每个对象的属性通常是小文本，如标题、名称和浮点数。
保存一个包含大约 10 个项目的 Json 文件，它大约有 60mb。
将这些相同的 10 个项目保存在 Elasticseach 索引中，获取所有项目的简单选择大约需要 10 秒来检索响应，我理解这种情况需要很长时间。
GET projects/project/_search?pretty=true&q
知道我真的需要对象的所有属性，是否有另一种方法可以将数据保存在面向文档的解决方案中？
我的对象结构是否适合该场景？
在客户端应用程序中，这些文档通常会一次全部检索出来，以便对项目进行一些数据分析。
最佳答案
一般来说，你应该设计一个 扁平 基于文档的数据库的结构。让自己摆脱关系数据库的概念(例如外键、规范化)。
话虽如此，您应该尽可能避免使用连接数据类型。在某些情况下它是有道理的，但在我看来它不应该变得太复杂和嵌套。
通过不引用文档(就像在 RDBMS 中那样)，您 将获取冗余信息。但是在基于文档的数据库的上下文中，这完全没问题!因此，您的列表将是包含存储所有信息的对象(不是文档)的数组。
假设您只有一个带有 n 个子对象的项目(您显示的列表)。在一个完全扁平化的世界中，您将拥有 一个 文档索引。
但一如既往:
一切都取决于您的具体用例。我的目的是给你一些提示。我多次遇到 DBA 将关系模型实现到 elasticsearch 中，结果非常糟糕。
我建议实现一个基本原型(prototype)以开始使用扁平结构。
我希望我能帮助你!
关于mongodb - 与 Elasticsearch 或其他面向文档的数据库一起使用的最佳文档结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57998138/