_replicator 数据库不可扩展或我的设计需要调整

Question

我认为详细说明我的来源很重要，这样您才能理解我的用例，请耐心等待。

背景：我希望将我的应用程序从 CouchDB 1 迁移到 2，此迁移需要大量工作。我只是想仔细检查一下我不是在重新发明轮子，并确保没有比我将在下面详述的更好的设计，特别是因为 CouchDB 2 似乎有一些很棒的新功能。

考虑以下允许学生以数字方式提交测验答案的应用的简化用例。每个学生都应该能够提交 her/his 个测验答案，老师应该能够查看所有答案。此设计需要与 PouchDB 配合使用，因为 PouchDB 直接与数据库对话，这为我们节省了大量时间，否则将需要编写一组精心设计的 API。

我选择的设计包括每个学生一个数据库和每个教师一个数据库，即每个用户一个数据库。只有数据库的所有者才能编辑 her/his 数据库，这是通过 CouchDB 角色强制执行的。当学生提交答案时，它会通过 PouchDB 与 her/his 数据库同步。然后将答案复制到教师的数据库中。这反过来又允许学生在应用程序中快速加载他们的答案，而教师则可以为所有学生加载所有答案。当然，教师数据库中的视图会按 class、测验等对答案进行分段，这样教师就不必一次加载所有学生的答案。如果我们没有教师数据库，那么教师将需要访问所有学生的数据库，并且必须与所有学生的数据库同步。

乍一看，_replicator 数据库似乎是将数据从学生数据库复制到单个教师数据库的明显方法。最大的陷阱是，当您使用连续复制时，它会消耗一个文件句柄和一个数据库连接，这意味着您可以很快耗尽数据库的资源。例如，如果我们的数据库中有 10,000 名学生，那么仅用于复制就需要 10,000 个并发文件句柄和数据库连接。考虑到这 10,000 名学生中有 100 名同时使用该应用程序的可能性不大，这实在是太疯狂了。

相反，我开发了一项服务，该服务侦听 _db_updates 提要，然后仅在特定数据库发生更改时才复制该数据库。使用这种方法，我们只担心在发生变化时消耗资源，结果我们最终得到大量的空闲文件句柄和数据库连接。

我对 CouchDB 2 进行了简短的试验，发现 _replicator 数据库与 CouchDB 1 中的资源一样贪婪。

这种针对学生和教师的每个用户数据库设计是最好的解决方案还是有更好的解决方案？如果这是最好的解决方案，是否有更好的方法来复制这些数据而不消耗那么多资源？

Answer 1

我已经开源了我的解决方案，名为 Spiegel, which provides the missing piece: scalable CouchDB replication and change listening. Spiegel is currently being used in production with a db-per-user design and is efficiently handling the replication of over 10,000 databases for Quizster。