CouchDB可以在同一台机器上处理数千个独立的数据库吗？
想象一下，你有BankTransaction的集合。有成千上万的记录。 （编辑：实际上并不存储事务 - 只考虑非常大量的，经常更新的记录。它基本上是来自SQL-land的连接表。）
每天您都需要仅在当地银行分行发生的交易摘要视图。如果所有记录都在一个数据库中，则重新生成视图将处理来自所有分支的事务的所有。这是一个更大的工作块，对于仅关心其特定文档子集的用户来说是不必要的。
这使得每个银行分支看起来应该被划分为自己的数据库，以便以较小的块生成视图，并且彼此独立。但是我从来没有听说有人这样做过，而且它似乎是一种反模式（例如，在数千个不同的数据库中复制相同的设计文档）。
我应该采用不同的方式对此问题进行建模吗？ （分区是否应该在不同的机器之间进行，而不是在同一台机器上的单独数据库？）如果没有，CouchDB可以处理数千个数据库来保持分区小吗？
（谢谢！）
答案 0 :(得分：5)
[警告，我假设你在某种生产环境中运行它。如果这是针对学校或宠物项目，请选择简短的答案。]
简短的回答是“是”。
答案越长，有些事情你需要注意......
你将会使用诸如最大文件描述符之类的系统设置来玩whack-a-mole。
您还将使用erlang vm设置玩弄w鼹鼠。
CouchDB有一个“max open databases”选项。增加这一点，或者你将有待处理的待处理请求。
聚合多个数据库以生成报告将是一个PITA。您可以通过轮询每个数据库的_changes feed，修改数据，然后将其放回中央/聚合数据库来完成。 CouchDB的API中还没有提供简化工具的工具。几乎，但不完全。
然而，如果你试图这样做，你将遇到的最大问题是CouchDB本身不能水平扩展[well]。如果你添加更多的CouchDB服务器，他们都将拥有重复的数据。当然，你的最大开放dbs计数会随着每个节点的增加而线性扩展，但其他一些东西，比如视图构建时间则不会（例如，他们都需要自己进行视图构建）。
虽然我在BigCouch群集上看到过数千个开放数据库。有趣的是，这是因为发电机集群：更多节点并行执行不同的事情，而不是相互之间相互复制的CouchDB服务器。
干杯。
答案 1 :(得分：1)
可能有多个数据库，但在大多数情况下，我认为聚合数据库实际上会为您的分支机构提供更好的性能。请记住，您只是在文档更新到视图时进行优化;每个文档只会在每个视图中解析一次。
对于聚合数据库中的日终轮询，第一个分支将导致100％的新文档被处理，并支付100％的延迟。所有其他分支机构将支付0％。所以大多数分支都受益对于单独数据库中的日终轮询，所有分支机构都会支付一部分与其数量成比例的惩罚，因此大多数分支略微落后。
对于全天频繁的视图更新，活动分支更喜欢聚合，而低容量分支更喜欢分开。如果10中的一个分支增加了99％的文档，那么大多数更新工作将在其他分支的民意调查中完成，因此10个中的9个更喜欢单独的dbs。
如果此延迟很重要，并假设沙发有一些时钟周期未使用，您可以编写一个3行循环/视图/睡眠shell脚本，在任何用户等待之前更新某些文档。
答案 2 :(得分：0)
我想补充说，拥有大量数据库会在压缩和复制方面产生问题。不仅需要在每个数据库的基础上触发连续复制等事情（这意味着您必须编写自定义逻辑来遍历所有数据库），但它们还会为每个数据库生成复制守护程序 。这很快就会变得过高。