说com.google.appengine.api.datastore.Cursor只是将索引位置存储到GAE数据存储索引中是否正确？
游标是否经久耐用？也就是说，我可以永久存储游标并一次又一次地重复使用它，并确保如果它指向索引中的第5000个位置，那么它将永远指向它吗？
如果索引缩小到少于5000个条目怎么办？使用此游标会导致错误还是只返回任何内容？
对于较大的索引（比如100,000个或更多条目），我是否可以首先获取每5000个多个位置的游标（比如说），存储它们然后使用这组游标以Map / Reduce方式完成一些工作？
我实际上是直接使用Objectify而不是DS，但是AFAIK这不会影响游标与索引的属性。
答案 0 :(得分：3)
游标仅在原始查询的上下文中有意义。它们不完全是指数位置/抵消。来自Cursors and data updates：
光标的位置被定义为结果列表中的位置 在最后一个结果返回后。光标不是相对位置 清单（它不是抵消）;它是Cloud Datastore的标记 在开始索引扫描结果时可以跳转。如果结果为 查询在使用游标之间进行更改，查询通知仅更改 在光标后的结果中出现。如果之前出现新结果 对于查询的光标位置，当它的时候不会返回 获取光标后的结果。同样，如果实体不是 查询的结果更长但是在光标之前出现了 光标不会改变后出现的结果。如果是最后的结果 return从结果集中删除，光标仍然知道如何 找到下一个结果。
游标受以下限制：
- 游标只能由执行原始查询的同一应用程序使用，并且只能继续执行相同的查询。使用光标 在随后的检索操作中，您必须重新构建 原始查询确切，包括相同的实体种类，祖先 过滤器，属性过滤器和排序顺序。这是不可能的 使用游标检索结果而不设置相同的查询 这是最初生成的。
- 因为NOT_EQUAL和IN运算符是用多个查询实现的，所以使用它们的查询不支持游标，也不支持游标 使用CompositeFilterOperator.or构造的复合查询 方法
- 游标不会像预期的那样使用不等式过滤器或具有多个值的属性上的排序顺序的查询。 这种多值属性的重复数据删除逻辑没有 在检索之间保持不变，可能导致相同的结果 不止一次地回来。
- 新的App Engine版本可能会更改内部实现细节，使依赖于它们的游标无效。如果申请 尝试使用不再有效的游标Cloud Datastore 引发IllegalArgumentException（低级API）， JDOFatalUserException（JDO）或PersistenceException（JPA）。
如果您的数据没有改变，您可能会以地图/缩小方式使用游标（通过恢复原始查询），包括预先获取它们。