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。这大大提高了沙发维护其b树的能力，例如构建和维护视图以及文档，并且它也将为您节省len([_id])空间。

您添加的每个文档（对于此类小数据）都会在b树空间中添加一些开销。在您的视图中（您的SQL查询的逻辑等效项），您始终可以解析文档字段并单独发出，或者在需要时多次发出。

这种不变的数据非常适合CouchDB。当数据添加到沙发时，您可以定期触发视图更新，并且视图将提前构建查询数据。这意味着，与SQL不同的是，您可以在运行每个时计算聚合日期，沙发将只读取缓存在视图b-tree的中间节点中的数据。快得多。

所以典型的CouchDB方法是： - 建模您的交易以最小化文档数量（即非规范化） - 如果需要，可以使用不同的视图以不同的方式过滤或排序结果。

我想你会想要在这段时间内产生汇总统计数据。在erlang中，这可能会更有效（CPU智能化）;所以，看看https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_query_servers.erl#L172-205，了解它们是如何完成的。

CouchDB数据库结构 - 最佳实践

1 个答案: