CouchDB可以在同一台机器上处理数千个不同的数据库吗？CouchDB可以处理数千个独立的数据库吗？
想象一下，你有一个集合BankTransaction s。有成千上万的记录。 （编辑：没有实际存储事务 - 只是想到了非常大量的非常小的，经常更新的记录，它基本上是一个来自SQL-land的连接表。）
每天你想要发生的事务的摘要视图只在您当地的银行分行。如果所有记录都在单个数据库中，则重新生成视图将处理全部的分支的全部。这是一个更大的工作，对于只关心他特定文档子集的用户来说是不必要的。
这使得每个银行分支似乎都应该划分到自己的数据库中，以便以更小的块生成视图，并且彼此独立。但是我从来没有听说过任何人这样做，而且这看起来像是一种反模式（例如，在数千个不同的数据库中复制相同的设计文档）。
有没有不同的方式来模拟这个问题？ （分区应该发生在不同的机器之间，而不是单独的数据库在同一台机器上？）如果不是，CouchDB可以处理成千上万的数据库以保持分区的小型化吗？
（谢谢！）
[警告，我假设你在某种生产环境中运行此。如果这是一个学校或宠物项目，请附简答。]
简短回答是“是”。
较长的答案是，有一些事情你需要提防...
你会被打捶一个痣有很多的系统设置，如最大文件描述。
你也会玩Erlang虚拟机设置的重击。
CouchDB有一个“max open databases”选项。增加这一点，或者你将有悬而未决的请求。
这将是一个PITA来聚合多个数据库来生成报告。您可以通过轮询每个数据库的_changes提要，修改数据，然后将其返回到中央/汇总数据库中来实现。使这个更容易的工具仅仅在CouchDB的API中还没有。几乎，但不完全。
但是，如果您尝试这样做，您将遇到的最大问题是CouchDB本身并不横向扩展[好]。如果你添加更多的CouchDB服务器，它们将会有重复的数据。当然，你的最大开放数据库数将随着每个节点的增加而线性扩展，但其他的东西如视图生成时间不会（例如，它们都需要自己构建视图）。
虽然我在BigCouch群集上看到了数千个开放数据库。有趣的是，这是因为发电机群集：更多的节点并行执行不同的事情，而不是CouchDB服务器相互复制。
干杯。
多个数据库是可能的，但大多数情况下，我想聚合数据库实际上将您的分支机构提供更好的性能。请记住，只有在文档更新到视图中时才进行优化;每个文档只能在每个视图中解析一次。
对于最终的天轮询在聚合数据库，所述第一分支将导致要处理的新文档的100％，并支付延迟的100％。所有其他分支机构将支付0％。所以大多数分行都受益对于单独数据库中的结束时间轮询，所有分支都支付与其数量成比例的部分罚款，因此大多数分数略微落后。
全天频繁更新视图，活跃的分支喜欢聚集和小批量分支喜欢独立。如果10中的一个分支添加了99％的文档，则大多数更新工作将在其他分支的投票中完成，因此10个中的9个更喜欢单独的dbs。
如果这种延迟的问题，并假设沙发上有一定的时钟周期去未使用的，你可以写一个3线环/视图/睡眠shell脚本的任何用户等待之前更新一些文件。
我想补充一点，有大量的数据库创建绕压实和复制问题。不仅做这样的事情连续复制需要在每个数据库的基础触发（这意味着你将不得不在所有的数据库编写自定义的逻辑回路），但每个数据库他们也产卵复制守护进程。这可能很快变得过于禁忌。
我想回应连续复制的问题，但我想提及_replicator数据库，它解决了一些提到的问题：https://gist.github.com/fdmanana/832610 ---尽管如此... tail -f即使有少量数据库，couchdb日志也很容易看出，这不会很好地扩展到数百万甚至数千个数据库。 – 2015-04-21 23:01:51
要回答你的问题，是的。 **但是**，使用非事务性存储进行交易是有风险的...... – ajreal 2012-03-27 10:46:18
@ajreal CouchDB是事务性的，否则它不会通过ACID合规性。每个文档写入在文档级别都是事务性的。您无法一次对> 1文档执行交易。 – 2012-03-27 21:20:33