我认为重要的是我详细说明了我的来源，以便你能理解我的用例，请耐心等待。
背景：我希望将我的应用程序从CouchDB 1迁移到2，这种迁移将需要相当多的工作。我只想仔细检查一下，我不是要重新发明轮子，并确保没有更好的设计，我将在下面详细说明，特别是因为CouchDB 2似乎有一些很棒的新功能。
考虑以下简化的应用程序用例，允许学生以数字方式提交测验答案。每个学生都应该能够提交她/他的测验答案，教师应该能够查看所有答案。这个设计需要与PouchDB一起使用，因为PouchDB直接与数据库对话，这节省了我们很多时间，否则需要编写一套精心设计的API。
我选择的设计包括每个学生一个数据库和每个教师一个数据库，即每个用户的数据库。只有数据库的所有者才能编辑她/他的数据库，这是通过CouchDB角色强制执行的。当学生提交答案时，它将通过PouchDB与她/他的数据库同步。然后将答案复制到教师的数据库中。这反过来允许学生在应用程序和教师中快速加载他们的答案，为所有学生加载所有答案。当然，教师数据库中有一些观点可以按班级，测验等对答案进行分段......这样教师就不必立即为所有学生加载答案。如果我们没有教师数据库，那么教师需要访问所有学生的数据库，并且必须与他们学生的所有数据库同步。
乍一看，_replicator数据库似乎是将学生数据库中的数据复制到单个教师数据库的明显方法。最重要的是，当您使用连续复制时，它会消耗文件句柄和数据库连接，这意味着您可以非常快速地使其资源数据库饿死。例如，如果我们在数据库中说10,000名学生，那么我们需要10,000个并发文件句柄和数据库连接，仅用于复制。考虑到即使这些10,000名学生中的100名同时使用该应用程序也不太可能，这是非常疯狂的。
相反，我开发了一个服务，它监听_db_updates提要，然后只在对该特定数据库进行更改时复制数据库。使用这种方法，我们只担心在有变化时消耗资源，因此我们最终会有大量的空闲文件句柄和数据库连接。
我简要地尝试了CouchDB 2，看起来_replicator数据库和CouchDB 1中的资源一样贪婪。
这种针对学生和教师的每用户数据库设计是最佳解决方案还是有更好的解决方案？如果它是最好的解决方案，是否有更好的方法来复制不消耗尽可能多资源的数据？