CouchDB可以处理数千个独立的数据库吗？

CouchDB能在同一台机器上处理数千个独立的数据库吗

假设您有一个

BankTransaction

s的集合。有成千上万的记录。（编辑：不实际存储事务——只需考虑大量非常小、频繁更新的记录。它基本上是来自SQL land的连接表。）

每天您都需要仅在本地银行分行发生的交易的摘要视图。如果所有记录都在一个数据库中，则重新生成视图将处理来自所有分支的所有事务。这是一项更大的工作，对于只关心其特定文档子集的用户来说是不必要的

这使得每个银行分行似乎都应该被划分到自己的数据库中，以便以更小的块生成视图，并且彼此独立。但我从未听说过有人这样做，这似乎是一种反模式（例如，在数千个不同的数据库中复制相同的设计文档）

我是否应该以不同的方式对此问题进行建模？（分区应该在不同的机器之间进行，而不是在同一台机器上的不同数据库之间进行吗？）如果不是，CouchDB可以处理数千个数据库以保持分区较小吗

（谢谢！）

[警告，我假设您正在某种生产环境中运行此程序。如果这是针对学校或宠物项目，请使用简短的答案。]

简短的回答是“是”

较长的答案是，有些事情你需要注意

• 你将要用很多系统设置，比如max文件描述符，来打鼹鼠

• 您还将使用erlang虚拟机设置来打鼹鼠

• CouchDB有一个“最大开放数据库”选项。增加该值，否则将有大量未决请求

• 聚合多个数据库以生成报告将是一个PITA。您可以通过轮询每个数据库的_changes提要、修改数据，然后将其扔回中央/聚合数据库来实现。CouchDB的API中还没有使这更容易的工具。差不多，但不完全一样

然而，如果您尝试这样做，您将遇到的最大问题是CouchDB本身不能进行水平伸缩。如果您添加更多CouchDB服务器，它们都将有重复的数据。当然，您的最大开放数据库数量将随着每个节点的添加而线性扩展，但视图构建时间等其他事情则不会（例如，它们都需要自己进行视图构建）

而我在集群上看到了数千个开放数据库。有趣的是，这是因为dynamo集群：更多的节点并行地做不同的事情，而不是隔离的CouchDB服务器相互复制

---

干杯。

多个数据库是可能的，但在大多数情况下，我认为聚合数据库实际上会为分支提供更好的性能。请记住，只有当文档更新到视图中时，您才进行优化；每个文档在每个视图中只解析一次

对于聚合数据库中的日终轮询，第一个分支将处理100%的新文档，并支付100%的延迟。所有其他分行将支付0%。因此，大多数分支机构都从中受益。对于在不同数据库中进行的一天结束投票，所有分支机构都会支付与其数量成比例的一部分罚款，因此大多数分支机构都会稍微落后

对于全天频繁的视图更新，活动分支机构更喜欢聚合，低容量分支机构更喜欢单独。如果10个分支机构中有一个分支机构添加了99%的文档，那么大多数更新工作将在其他分支机构的调查中完成，因此10个分支机构中有9个更喜欢单独的数据库

---

如果这个延迟很重要，并且假设coach有一些未使用的时钟周期，您可以编写一个3行循环/视图/休眠shell脚本，在任何用户等待之前更新一些文档。

我要补充的是，拥有大量数据库会造成压缩和复制方面的问题。不仅像连续复制这样的事情需要在每个数据库的基础上触发（这意味着您必须编写自定义逻辑以在所有数据库上循环），而且还需要在每个数据库上生成复制守护进程。这很快就会变得令人望而却步。

要回答您的问题，请回答“是”。但是，将非事务性存储用于事务是有风险的…@ajreal-CouchDB是事务性的，否则它将无法通过ACID遵从性。在文档级别，每个文档写入都是事务性的。您不能一次对>1个文档执行事务。我想重复一下连续复制的问题，但我想提到的是\u replicator数据库，它解决了前面提到的一些问题：---尽管如此。。。tail-f couchdb日志即使只有少量数据库，您也可以很容易地看到它不能很好地扩展到数百万甚至数千个数据库。