Question

我正在尝试为沙发床（2.3.1）的项目确定最佳的文档架构。在研究此问题时，我发现一些矛盾的信息，并且没有最新版本的Sofadb和类似情况的相关准则。如果此数据不能提供给beddb或其他方法（而不是下文详述的方法）使用，我想更好地理解原因。

我的情况是跟踪小部件的制造细节：

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

方法1：

{
    "_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个文档。但是，这些文档非常高并且经常更新。

方法2：

{
    "_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"   
}

方法2创建一个很高的数据库

Answer 1

这是一个常见的问题。一般而言，小的，不可变的文档将比少数的，庞大的，可变的文档更有性能。造成这种情况的原因包括：

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

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

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

文档架构性能

1 个答案: