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

Question

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

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

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

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

乍一看，_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 多个数据库的复制。 .