CouchDB数据库结构 - 最佳实践

cra*_*awf 5 database couchdb

作为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...
Run Code Online (Sandbox Code Playgroud)

我的问题是,这种结构是否正确?我知道CouchDB是一个平面文件数据库,但数据库中将有数百万个时间戳/值文档.我可能只是挑剔,但它似乎对我来说有点混乱.

谢谢!

dch*_*dch 3

如果保证唯一,请使用时间戳作为您的 ID。这极大地提高了 couch 维护其 B 树的能力,以用于构建和维护视图以及文档等操作,并且它也会节省您的len([_id])空间。

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

这种类型的不变数据非常适合 CouchDB。当数据添加到 couch 时,您可以定期触发视图更新,视图将提前构建查询数据。这意味着,与 SQL 不同(每次都动态计算聚合日期),couch 只会读取缓存在视图 B 树的中间节点中的数据。快多了。

因此,典型的 CouchDB 方法是: - 对事务进行建模,以最大限度地减少文档数量(即非规范化) - 如果需要以不同方式过滤或排序结果,则使用不同的视图。

我想您会想要生成该时间段内的汇总统计数据。在 erlang 中这可能会更加高效(CPU 方面);因此,请查看https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L172-205以了解它们是如何完成的。