我有一个关于 couchDB 上最适合我的消息应用程序用例的架构的问题。
该用例用于一个简单的消息传递平台，该平台目前有一个沙发数据库，所有消息都作为文档。每个文档都有一个“收件人”字段，指示消息的预期收件人。当客户端应用程序唤醒时，它会在数据库中查询在最后一次检查后发给特定用户的所有新消息。这是通过使用普通过滤器查询 _changes 提要来实现的，该过滤器检查用户 ID 在文档的“to”字段中是否存在。
据我了解 couchDB 的操作，这需要数据库在最后一个序列之后检索更改提要的所有文档，并对它们运行过滤器功能。由于在我的用例中出现新消息的可能性非常低，这将导致相当大的开销（假设我有 100 000 个用户，每个用户每天收到两条消息，这将需要数据库读取所有 200 000 条消息 200 000次支持所有用户？）
选项 1：根据我的阅读，不可能在 _changes 提要上放置参数过滤器。这很好，从那时起我就可以使用复制功能来提取消息。– 非首发？
选项 2：使用组合“to”字段和更新序列的键实现视图。然后，我可以在此视图中查询用户值和序列 > 最后一个序列。– 在这里，我正在努力从 Map 函数访问文档的更新 Seq。– 这可行吗？
选项 3：在服务器上为每个用户实现一个数据库，并在公共数据库上设置复制到每个用户特定的数据库。然后，用户查询她自己的数据库的 _changes 提要，该提要只有发给她的消息，非常简单。现在您需要在服务器上维护 100 000 x 2 个复制。这还有其他缺点，但可以工作。
综上所述，这听起来像是最可行/可扩展的方法？还是我错过了另一个选择？
谢谢