CouchDB数据库结构最佳实践

Question

CouchDB数据库结构最佳实践

5

作为一个新手使用CouchDB，想讨论一下构建数据库和文档的最佳实践。我的背景是MySQL，所以仍在尝试理解基于文档的数据库。

我们系统的概述如下：我们有几个客户，每个客户都访问不同的网站并处理各自的数据。每个客户的数据将拆分成其自己的数据库。每个数据库将不断插入数据（每5分钟插入一次，至少插入一年）以记录事件。每5分钟创建一个新文档，其中包含时间戳和值。我们还需要存储一些关于客户的信息，这是一个单独的文档，很少会被更新（如果有更新，也很少）。

以下是一个客户数据库的示例...

{
    "_id": "client_info",
    "name": "Client Name",
    "role": "admin",
    ....
},
{
    "_id": "1199145600",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
{
    "_id": "1199145900",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
{
    "_id": "1199146200",
    "alert_1_value": 0.150
    "alert_2_value": 1.030
    "alert_3_value": 12.500
    ...
    ...
},
etc...literally millions more of these every 5 minutes...

我的问题是，这种结构是否正确？我知道CouchDB是一个平面文件数据库，但是在数据库中将会有数百万个时间戳/值文档。也许我只是有点挑剔，但对我来说它似乎有点杂乱无章。

谢谢！

- crawf

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- dch · Accepted Answer

如果时间戳保证唯一，可以将其用作ID。这会极大地提高Couch在构建和维护视图以及文档等方面维护B树的能力，同时还可以节省len([_id])的空间。

每个添加的文档（对于这样的小数据）都会增加B树空间上的一些开销。在视图中（相当于SQL查询的逻辑等价物），您始终可以解析文档字段并分别发出它们，或者多次发出它们（如果需要）。

这种不变数据非常适合CouchDB。随着数据添加到Couch中，您可以定期触发视图更新，并且视图将提前构建查询数据。这意味着，与SQL不同，在那里您将每次动态计算汇总日期，Couch只需读取缓存在视图B树的中间节点中的数据。速度更快。

因此，典型的CouchDB方法是： - 模型化交易以最小化文档数量（即去规范化） - 如有必要，请使用不同的视图以不同方式过滤或排序结果。

我猜你希望跨那段时间产生聚合统计信息。很可能这在CPU方面更有效率（智能手机），因此请查看https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L172-205以了解它们是如何完成的。