文档架构性能

Question

我正在尝试为 couchdb (2.3.1) 的项目确定最佳文档架构。在对此进行研究时，我发现了一些相互矛盾的信息，并且没有针对最新版本的 couchdb 和类似场景的相关指南。如果此数据不适用于 couchdb，或者首选除下面详述的方法之外的其他方法，我想更好地理解原因。

我的场景是跟踪小部件的制造细节：

必须跟踪 100,000-300,000 种小部件类型
每种小部件类型每天生产 200-1,800 次
小部件类型的制造可能会在一天内激增至约 10,000 个
必须记录和更新每个小部件创建及其相关详细信息
小部件创建存储 30 天
按小部件类型和creationStartTime/creationEndTime
我不关心修订，如果这可能会提高性能，我可以更新并使用相同的 _rev

方法一：

{
    "_id": "*",
    "_rev": "*",
    "widgetTypeId": "1831",
    "creation": [{
        "creationId" "da17faef-3591-4579-b5f6-ff0a719a6da7",
        "creationStartTime": 1556471139,
        "creationEndTime": 1556471173,
        "color": "#ffffff",
        "styleId": "92811",
        "creatorId": "82812"
  },{
        "creationId" "893fede7-3874-44ed-b290-7001b4901bc9",
        "creationStartTime": 1556471481,
        "creationEndTime": 1556471497,
        "color": "#cccccc",
        "styleId": "75343",
        "creatorId": "3211"
  }]
}

使用方法一会将我的文档创建限制为 100,000-300,000 个文档。但是，这些文档会非常高大上，而且经常更新。

方法二：

{
    "_id": "*",
    "_rev": "*",
    "widgetTypeId": "1831",
    "creationId" "da17faef-3591-4579-b5f6-ff0a719a6da7",
    "creationStartTime": 1556471139,
    "creationEndTime": 1556471173,
    "color": "#ffffff",
    "styleId": "92811",
    "creatorId": "82812"
},{
    "_id": "*",
    "_rev": "*",
    "widgetTypeId": "1831",
    "creationId" "893fede7-3874-44ed-b290-7001b4901bc9",
    "creationStartTime": 1556471481,
    "creationEndTime": 1556471497,
    "color": "#cccccc",
    "styleId": "75343",
    "creatorId": "3211"   
}

方法二创建tall数据库

Answer 1

这是一个常见的问题。一般来说，小的、不可变的文档可能比少数、大的、可变的文档更高效。原因包括：

CouchDB 不支持部分更新（补丁）。因此，如果您需要将数据插入大文档中的数组，则需要获取所有数据，解压缩 json，插入数据，重新打包 json 并将整个内容发送回在线 CouchDB。
更大的文档也提供更多的内部开销，尤其是在索引方面。

最好让变化的数据作为一个单元组成一个文件。文档中不断增长的列表不是一个好主意。

在我看来，您的第二个选择非常适合您想要实现的目标：一组可以不可变的小文档。然后制作一组视图，以便您可以查询时间范围和小部件类型。

文档架构性能

Document Schema Performance

couchdb