database - CouchDB 数据库结构 - 最佳实践

Question

作为 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 是一个平面文件数据库，但数据库中实际上会有数百万个时间戳/值文档。我可能只是挑剔，但对我来说似乎有点杂乱无章。

谢谢!

Answer 1

如果保证唯一，请使用时间戳作为您的 ID。这极大地提高了 couch 维护其 b 树的能力，例如构建和维护 View 以及文档，而且它还会为您节省 len([_id]) 空间。

您添加的每个文档(对于如此小的数据)都会在 b 树空间中增加一些开销。在您的 View 中(逻辑上等同于您的 SQL 查询)，您始终可以解析文档字段并单独发出它们，或者在需要时多次发出它们。

这种类型的不变数据非常适合 CouchDB。随着数据添加到沙发上，您可以定期触发 View 更新， View 会提前构建查询数据。这意味着，与 SQL 不同，在 SQL 中您每次 都在动态计算聚合日期，couch 将简单地读取缓存在 View b 树的中间节点中的数据。快得多。

所以典型的 CouchDB 方法是:- 为您的交易建模以最小化文档数量(即非规范化)- 如果需要以不同方式过滤或排序结果，请使用不同的 View 。

我想您会想要生成该时间段内的汇总统计数据。这在 erlang 中可能会更有效率(CPU 方面)；所以看看https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L172-205看看他们是如何完成的。