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

Question

我认为详细说明我的来源很重要，以便您了解我的用例，请多多包涵。

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

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

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

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

相反，我开发了一个服务，它侦听 _db_updates 提要，然后仅在特定数据库发生更改时复制数据库。使用这种方法，我们只担心在发生更改时消耗资源，因此我们最终会获得大量空闲文件句柄和数据库连接。

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

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

Answer 1

我已经开源了我的解决方案，名为 Spiegel，它提供了缺失的部分：可扩展的 CouchDB 复制和更改侦听。 Spiegel 目前在生产环境中使用 db-per-user 设计，并有效地处理 Quizster 的 10,000 多个数据库的复制。