基于MongoDb ObjectId的基于Redis光标的分页

Question

I don't have experience with Redis so far, but I'm exploring possibilities to use MongoDB as database and Redis as cache.

The question I'm dealing with is whether Redis is capable of handling MongoDb ObjectId's in the scope of cursor-based pagination as described, for example here: https://developer.twitter.com/en/docs/tweets/timelines/guides/working-with-timelines.html .
In this example we have a maxId that serves as the maximum id that was fetched from the previous request, and will be used as lower bound for fetching the next page.

In MongoDb I've explored that it is not a problem to user greater than / smaller than operators on ObjectId's, but I don't know if I will be capable to handle this in Redis, as ObjectId's will most probably be stored as a string value.

This question is important for me as it will help me to decide whether to use MongoDb ObjectId's, or to use auto-increments as PK id. I would prefer to use ObjectId's though.

Note: I'm writing my backend with Java, so fancy npm modules are not what I'm looking for.

Answer 1

The solution I came up with:

• Use timestamp as cursor
• Store timestamp as score in Redis. Even when there are theoretically duplicate scores possible in this case, the chance that this will cause conflict in terms of pagination is negligeable for my application.
  For example: I have a duplicate score at the 10th result. The next request will include the current timestamp in its result, which means that both 10th and 11th result would be returned on the next request.
• In case Redis returns results, ok
• In case Redis does not return results, the timestamp cursor can be used to query ObjectId's in MongoDb as well. Even though ObjectId doesn't support milliseconds, this is not a real problem. Find all objectId's <= cursor timestamp with limit / offset should work fine. The cursor timestamp in the search needs , so millisecond variations won't cause trouble.
• In case Redis only returns a partial result, MongoDb can be queried based on the ObjectId of the last available post that was found in Redis.

This solution isn't ideal since the client will need to perform extra checks on the last processed vs the newly received results to avoid duplicate rendering, but this isn't a real problem as this is not an open api and only used internally. After looking for quite some time, there doesn't appear to be an one-fit-all solution to this kind of problem.