对于我的Messaging应用程序用例，我对couchDB上最合适的架构有疑问。
该用例适用于一个简单的消息传递平台，该平台目前有一个沙发数据库，所有消息都作为文档。每个文档都有一个“to”字段，表示消息的预期收件人。当客户端应用程序唤醒时，它会在数据库中查询上次检查后发送给特定用户的所有新消息。这可以通过使用普通过滤器查询_changes Feed来检查文档中“to”字段中是否存在用户ID。
据我了解couchDB的操作，这要求数据库在最后一个序列之后检索更改源的所有文档，并针对它们运行过滤器功能。由于在我的用例中新消息的可能性非常低，这将导致相当大的开销（假设我每天有100 000个用户每天收到两条消息，它将要求DB读取所有200 000条消息200 000次支持所有用户？）
选项1：根据我的阅读，不可能在_changes Feed之上放置参数过滤器。这样会很好，从那以后我就可以使用复制功能来提取消息了。 - 非入门？
选项2：使用组合“to”字段和更新序列的键实现视图。然后，我可以查询此视图以获取用户值和序列＆gt;最后的序列。 - 在这里，我正在努力从Map功能访问文档的更新Seq。 - 这可行吗？
选项3：在服务器上为每个用户实现数据库，并在公共数据库上为每个特定于用户的数据库设置复制。然后，用户查询她自己的数据库的_changes提要，该数据库只有指向她的消息，这很容易。现在，您需要在服务器上维护100 000 x 2次复制。这有其他缺点，但可以奏效。
从上面看，这听起来像是最可行/可扩展的方法吗？或者我错过了另一种选择？
由于
答案 0 :(得分：0)
我会使用选项2.而不是文档序列ID（我认为你不能从视图函数中获取），只需在消息文档中添加日期/时间字段？
如果您担心客户端的时钟偏差（您应该将其作为对我的答案的评论而不是尝试编辑它而被拒绝），您可以在检索中应用一些容差。我假设你只是输入一些你已经看过的额外信息就不会太糟糕了。
（我也不会担心时钟偏差，但我不知道你将使用哪种类型的客户。）