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树的能力，用于构建和维护视图以及文档，还将为您节省len([_id])空间。

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

这种类型的不变数据非常适合CouchDB。当数据被添加到couch中时，您可以周期性地触发视图更新，视图会提前构建查询数据。这意味着，与SQL不同，在SQL中，每次都会动态计算聚合数据，couch只会读取缓存在视图b-tree的中间节点中的数据。快得多。

所以典型的CouchDB方法是：-对你的事务进行建模，以最小化文档的数量(即去正规化)--如果需要的话，可以使用不同的视图来对结果进行不同的过滤或排序。

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