MongoDb + Mongoose QueryStream - 以下文档更改
MongoDb + Mongoose QueryStream - Following document changes
我正在尝试在调度应用程序中使用 Mongoose 及其查询流，但我可能误解了它的工作原理。我已经在 SO [Mongoose QueryStream new results 上阅读了这个问题，看来我是对的，但请有人解释一下：
如果我像这样过滤查询 -
Model.find().stream()
当我添加或更改与 .find() 匹配的内容时，它应该引发 data 事件，对吗？还是我对这个问题的理解完全错误？
例如，我正在尝试查看一些这样的数据：
Events.find({'title':/^word/}).stream();
我正在 mongodb 控制台中更改标题，但没有看到任何更改。
谁能解释为什么？
您的理解确实不正确，因为流只是当前查询响应的输出流，而不是 "listens for new data" 本身。这里的 returned 结果基本上只是一个节点 streaming interface，这是一个可选的选择，而不是 "cursor"，或者实际上直接转换为数组，就像 mongoose 方法默认做的那样。
所以 "stream" 不只是 "follow" 任何东西。这实际上只是处理查询的正常结果的另一种方式，但不会 "slurp" 所有结果立即存入内存。它使用事件侦听器来处理从服务器游标获取的每个结果。
你说的其实是"tailable cursor", or some variant thereof. In basic MongoDB operations, a "tailable cursor" can be implemented on a capped collection。这是具有特定规则的特殊类型 collection，因此它可能不适合您的目的。它们用于 "insert only" 通常适用于事件队列的操作。
在使用上限 collection 的模型上（并且仅在已设置上限 collection 的地方）然后您可以这样实现：
var query = Events.find({'title':/^word/}).sort({ "$natural": -1}).limit(1);
var stream = query.tailable({ "awaitdata": true}).stream();
// fires on data received
stream.on("data",function(data) {
console.log(data);
});
"awaitdata" 与 "tailable" 选项本身一样重要，因为它是告诉查询游标保持 "active" 和 [=39] 的主要内容=] collection 中满足查询条件的添加。但是你的 collection 必须是 "capped" 才能工作。
另一种更高级的方法是执行类似 meteor distribution does, where the "capped collection" that is being tailed is in fact the MongoDB oplog. This requires a replica set 配置的操作，但是就像 meteor 开箱即用一样，将单个节点作为副本集并没有错本身。在生产中这样做是不明智的。
这比简单的答案更高级，但基本概念是因为 "oplog" 是一个上限 collection 您可以 "tail" 它用于所有写操作数据库。然后检查此事件数据以确定您要监视写入的 collection 等详细信息已写入。然后，该数据可用于查询新信息，并通过 websocket 或类似方式向客户端执行类似 return 更新或新结果的操作。
但是流本身就是流。要 "follow" collection 上的更改，您需要按上限实施它，或者考虑实施一个基于观察 oplog 中描述的更改的过程。
我正在尝试在调度应用程序中使用 Mongoose 及其查询流，但我可能误解了它的工作原理。我已经在 SO [Mongoose QueryStream new results 上阅读了这个问题，看来我是对的，但请有人解释一下：
如果我像这样过滤查询 -
Model.find().stream()
当我添加或更改与 .find() 匹配的内容时，它应该引发 data 事件，对吗？还是我对这个问题的理解完全错误？
例如，我正在尝试查看一些这样的数据：
Events.find({'title':/^word/}).stream();
我正在 mongodb 控制台中更改标题，但没有看到任何更改。
谁能解释为什么？
您的理解确实不正确，因为流只是当前查询响应的输出流，而不是 "listens for new data" 本身。这里的 returned 结果基本上只是一个节点 streaming interface，这是一个可选的选择，而不是 "cursor"，或者实际上直接转换为数组，就像 mongoose 方法默认做的那样。
所以 "stream" 不只是 "follow" 任何东西。这实际上只是处理查询的正常结果的另一种方式，但不会 "slurp" 所有结果立即存入内存。它使用事件侦听器来处理从服务器游标获取的每个结果。
你说的其实是"tailable cursor", or some variant thereof. In basic MongoDB operations, a "tailable cursor" can be implemented on a capped collection。这是具有特定规则的特殊类型 collection，因此它可能不适合您的目的。它们用于 "insert only" 通常适用于事件队列的操作。
在使用上限 collection 的模型上（并且仅在已设置上限 collection 的地方）然后您可以这样实现：
var query = Events.find({'title':/^word/}).sort({ "$natural": -1}).limit(1);
var stream = query.tailable({ "awaitdata": true}).stream();
// fires on data received
stream.on("data",function(data) {
console.log(data);
});
"awaitdata" 与 "tailable" 选项本身一样重要，因为它是告诉查询游标保持 "active" 和 [=39] 的主要内容=] collection 中满足查询条件的添加。但是你的 collection 必须是 "capped" 才能工作。
另一种更高级的方法是执行类似 meteor distribution does, where the "capped collection" that is being tailed is in fact the MongoDB oplog. This requires a replica set 配置的操作，但是就像 meteor 开箱即用一样，将单个节点作为副本集并没有错本身。在生产中这样做是不明智的。
这比简单的答案更高级，但基本概念是因为 "oplog" 是一个上限 collection 您可以 "tail" 它用于所有写操作数据库。然后检查此事件数据以确定您要监视写入的 collection 等详细信息已写入。然后，该数据可用于查询新信息，并通过 websocket 或类似方式向客户端执行类似 return 更新或新结果的操作。
但是流本身就是流。要 "follow" collection 上的更改，您需要按上限实施它，或者考虑实施一个基于观察 oplog 中描述的更改的过程。