推荐的 CouchDB 文档结构

Question

我们目前正在考虑将 Postgres 更改为 CouchDB 以用于使用监控应用程序。一些数字：

大约 2000 个连接，每 5 分钟轮询一次，每天大约有 600,000 个新行。在 Postgres 中，我们按天存储这些数据：

t_usage {service_id, timestamp, data_in, data_out}
t_usage_20100101 继承 t_usage。
t_usage_20100102 继承 t_usage。等等

我们使用乐观存储过程写入数据，该过程假定分区存在并在必要时创建它。我们可以非常快速地插入。

对于数据的读取，我们的用例按重要性和当前性能排列如下：
* 单次服务，单日使用：良好的性能
* 多项服务，每月使用量：性能不佳
* 单一服务，月使用量：性能不佳
* 多个服务，多个月：性能非常差
* 多种服务，单日：良好的性能

这是有道理的，因为分区已经优化了几天，这是迄今为止我们最重要的用例。但是，我们正在研究改进次要要求的方法。

我们通常还需要按小时对查询进行参数化，例如，仅在上午 8 点到下午 6 点之间给出结果，因此汇总表的用途有限。 （这些参数变化的频率足够高，以至于创建多个数据汇总表是令人望而却步的）。

有了这个背景，第一个问题是：CouchDB 是否适合这些数据？如果是的话，鉴于上述用例，您将如何最好地对 CouchDB 文档中的数据进行建模？到目前为止，我整理的一些选项是（_id，_rev 除外）：

每天每个连接一个文档

{
  service_id:555
  day:20100101
  usage: {1265248762: {in:584,out:11342}, 1265249062: {in:94,out:1242}}
}

每月大约有 60,000 个新文档。大多数新数据将是对现有文档的更新，而不是新文档。

（这里，使用中的对象以轮询的时间戳为键，以及字节输入和输出的值）。

每月每个连接一个文档

{
  service_id:555
  month:201001
  usage: {1265248762: {in:584,out:11342}, 1265249062: {in:94,out:1242}}
}

每月大约 2,000 个新文档。需要对现有文件进行适度更新。

每行数据收集一个文档

{
  service_id:555
  timestamp:1265248762
  in:584
  out:11342
}
{
  service_id:555
  timestamp:1265249062
  in:94
  out:1242
}

每月大约有 15,000,000 个新文档。所有数据都将插入到新文档中。插入速度更快，但我对在处理数亿个文档后一年或两年后的效率有疑问。文件 IO 似乎令人望而却步（尽管我是第一个承认我并不完全理解它的机制的人）。

我正在尝试以面向文档的方式处理此问题，尽管很难打破 RDMS 习惯 :) 您也只能最小化参数化视图这一事实让我有点担心。也就是说，以上哪个最合适？还有其他我没有考虑过的格式会更好吗？

提前致谢，

杰米。

Answer 1

我不认为这是一个可怕的想法。

让我们考虑一下您的连接/月份方案。

考虑到一个条目的长度约为 40 个（这已经够大了）字符，并且您每月会收到大约 8,200 个条目，因此您的最终文档大小将在月底达到大约 350K。

这意味着，如果要满负荷工作，您每 5 分钟要读取和写入 2000 个 350K 文档。

I/O 方面，这小于 6 MB/s，考虑到读写，平均 5m 时间窗口。这在今天的低端硬件中也是如此。

但是，还有另一个问题。当您存储该文档时，Couch 将评估其内容以构建其视图，因此 Couch 将解析 350K 文档。我担心的是（最后检查，但已经有一段时间了）我不相信 Couch 不能很好地跨 CPU 内核扩展，因此这很容易固定 Couch 将使用的单个 CPU 内核。我希望 Couch 可以读取、解析和处理 2 MB/s，但坦率地说我不知道​​。尽管 erlang 具有所有优点，但它并不是直线计算机语言中最好的。

最后一个问题是跟上数据库。这将在月底每 5 分钟写入 700 MB。使用 Couchs 架构（仅附加），您将每 5 分钟写入 700MB 数据，即每小时 8.1GB，24 小时后写入 201GB。

在 DB 压缩后，它会压缩到 700MB（一个月），但在此过程中，该文件会变大，而且速度很快。

在检索方面，这些大文件不会吓到我。加载一个 350K JSON 文档，是的，它很大，但不是那么大，不是在现代硬件上。公告板上有比这更大的头像。所以，我认为你想要对一个月内的连接活动做的任何事情都会很快。跨连接，显然你抓取的越多，它就会变得越贵（所有 2000 个连接为 700MB）。 700MB 是一个具有实际影响的实数。此外，您的流程将需要积极地丢弃您不关心的数据，以便它可以扔掉谷壳（除非您想在报告流程中加载 700MB 的堆）。

鉴于这些数字，连接/天可能是更好的选择，因为您可以更好地控制粒度。但是，坦率地说，我会尽可能地寻找最粗略的文档，因为我认为这可以为您提供数据库的最佳价值，仅仅是因为今天所有的磁头寻道和盘片旋转都会扼杀大量 I/O 性能，很多磁盘流数据非常好。较大的文档（假设数据位置良好，因为 Couch 经常被压缩，这应该不是问题）流比查找更多。与磁盘相比，在内存中查找是“免费的”。

请务必在我们的硬件上运行您自己的测试，但要牢记所有这些因素。

编辑：

经过更多的实验......

几个有趣的观察结果。

在导入大型文档期间，CPU 对 I/O 速度同样重要。这是因为将 JSON 转换为内部模型以供视图使用会消耗大量的编组和 CPU。通过使用大型 (350k) 文档，我的 CPU 几乎用尽了 (350%)。相比之下，对于较小的文档，它们以 200% 的速度嗡嗡作响，尽管总的来说，它是相同的信息，只是分块不同。

对于 I/O，在 350K 文档期间，我的图表速度为 11MB/秒，但对于较小的文档，仅为 8MB/秒。

压缩似乎几乎受 I/O 限制。我很难获得关于我的 I/O 潜力的好数字。缓存文件的副本以 40+MB/秒的速度推送。压缩以大约 8MB/秒的速度运行。但这与原始负载一致（假设沙发正在逐条移动内容）。 CPU 较低，因为它执行的处理较少（它不解释 JSON 有效负载或重建视图），而且它是一个单独的 CPU 来完成工作。

最后，为了阅读，我尝试转储整个数据库。一个 CPU 被固定为此，而我的 I/O 非常低。我强调要确保 CouchDB 文件实际上没有被缓存，我的机器有很多内存，所以很多东西都被缓存了。通过 _all_docs 的原始转储只有大约 1 MB/秒。这几乎是所有的寻找和旋转延迟。当我对大型文档执行此操作时，I/O 达到了 3 MB/秒，这只是显示了流影响，我提到了大型文档的好处。

应该注意的是，Couch 网站上有一些我没有遵循的提高性能的技巧。值得注意的是，我使用的是随机 ID。最后，这并不是作为衡量 Couch 性能的标准，而是衡量负载最终出现的地方。我认为大文件和小文件的差异很有趣。

最后，终极性能并不像简单地为您的硬件应用程序提供足够好的性能那么重要。正如你所提到的，你正在做你自己的测试，这才是真正重要的。