0

我需要一种方法来超越 NoSQL 文档项大小限制，同时保持读/写性能。

所有 NoSQL 实施都有文档项大小限制（例如 AWS DynamoDB 为 400KB，MongoDB 为 16MB）。此外，文档项大小越大，文档的检索就越慢。读取、写入、更新和删除性能在我的实现中很重要。

我已经在使用 NoSQL 数据库，并且我使用的文档具有四个级别的树结构（该文档描述了不同大小和复杂性的矢量图）。树的每个节点都是一个组件，它有一个 ID 和一个引用以下组件的主体。可以对整个树或树的部分执行读取和更新。

我考虑过切换到图形数据库，但它们已针对查询图形中的关系进行了优化。我需要一种简单且高性能的方式来存储扩展树文档而不是处理图形。

我在想我需要在 NoSQL 中实现Closure Table结构，以将树节点拆分为单独的组件，从而打破文档大小的障碍。在客户端，具有延迟加载的 ORM（对象关系映射器）将根据需要检索文档树节点。

我的问题是：

  • 这以前是否已实施？
  • 是否有另一种方法来获得上述功能？

如果您需要这样的功能，请对此表示赞成，以便更多的出口可以回答这个问题。

4

1 回答 1

0

DynamoDB 不会因大小而降低速度，但联网需要额外的时间，仅此而已。此外，如果您有这么大的文件并试图将其推送到 DynamoDB，这就是设计问题的开始。只需将大文件存储在 S3 中并将元数据存储在 DynamoDB 中。

您正在使用 DynamoDB 按 KB 为写入和读取单位付费，为什么在 S3 如此便宜且大小限制为 5TB 而不是 400KB 的情况下将钱浪费在大数据上。此外，如果您的应用程序生成了那些大型 JSON 结构，您可以通过使用 S3 存储类自动化来节省 $ 加班费，这会将未使用的 JSON 移动到“更冷”的存储类。

于 2021-01-17T09:07:50.630 回答