我认为重要的是要详细说明自己的来源，以便您可以理解我的用例，请忍受我。
背景：我希望将我的应用程序从Couchdb 1迁移到2，而这种迁移将需要大量的工作。我只想仔细检查一下我不会重新发明轮子，并确保在下面详细说明的设计没有更好的设计，尤其是因为Couchdb 2似乎具有一些很棒的新功能。
考虑一个应用程序的以下简化用例，该应用程序允许学生以数字方式提交测验答案。每个学生都应该能够提交她/他的测验答案，并且老师应该能够查看所有答案。由于PouchDB直接与DB交谈，因此需要与PouchDB一起使用，这为我们节省了很多时间，否则需要编写一组精心设计的API。
我选择的设计由每个学生一个数据库和每个老师的一个数据库组成，即每个用户的数据库。只有数据库的所有者才能编辑她/他的数据库，这是通过CouchDB角色执行的。当学生提交答案时，它通过PouchDB与她/他的数据库同步。然后将答案复制到教师的数据库中。反过来，这使学生可以快速将答案加载到应用程序中，而老师可以为所有学生加载所有答案。当然，教师数据库中有一些视图，可以按课堂，测验等细分答案，以便老师不必一次为所有学生加载答案。如果我们没有教师数据库，那么老师将需要访问所有学生的数据库，并且必须与所有学生的数据库同步。
乍一看，_replicator数据库似乎是将数据库从学生数据库复制到单个教师数据库的明显方法。最大的Gotcha是，当您使用连续复制时，它会消耗文件句柄和数据库连接，这意味着您可以很快饿死其资源数据库。例如，如果我们在数据库中说了10,000名学生，那么我们需要10,000个并发文件处理和数据库连接才能复制。考虑到这10,000名学生中的100名不太可能同时使用该应用程序，这真是太疯狂了。
相反，我开发了一项服务，该服务会倾听_db_updates feed，然后在对该特定数据库进行更改时仅复制数据库。使用这种方法，我们只担心在发生更改时消耗资源，因此我们最终获得了大量的免费文件处理和数据库连接。
我已经简短地尝试了CouchDB 2，看来_replicator数据库与Couchdb 1一样贪婪。
。这个数据库per-user设计是为学生和老师提供的最佳解决方案，还是有更好的解决方案？如果是最好的解决方案，是否有更好的方法来复制这些数据不会消耗那么多资源？
我已经为Spiegel开了开源的解决方案，该解决方案提供了缺失的部分：可伸缩的CouchDB复制和更改聆听。Spiegel目前正在使用DB Per-user设计中使用，并有效地处理了超过10,000个数据库的Quizster。