Reputation: 101
I am pretty new to Couchbase database and have requirement to build leaderboard solution in our project. Ideally it should work like inmemory sorted set: O(log(N)) for each item added and O(log(N)+M) with N being the number of elements in the sorted set and M the number of elements returned.
Is there any way to reach this requirements with Couchbase? All couchbase queries is depend on indexes(views) which rebuild after request by default in background. Using Stale.False option is time consuming. GSI for N1QL consistency also depends on using Stale parameter.Is there any way to insert in CouchBase key/value pair in some structure like Sorted set in Redis and be able to get updated data immediately?
Lets say we have user document:
{
"id": "44-44-45"
"name": "John_Canada",
"country": "Canada",
"city": "Ottawa"
"levelScore": 2147483641,
"type": "user"
}
Requirement is to build real-time leaderboard(which means if someone change property it should be visible for others immediately) based on levelScore and be able to filter by country, city or other user property in the future. In Redis it could be done like this:
ZADD "leaderboard" 10 "homer"
ZADD "leaderboard" 25 "marge"
ZADD "leaderboard" 55 "bart"
GETTING A RANKED LIST for top10 players:
ZREVRANGE "leaderboard" 0 10
1) "frank grimes"
2) "lisa"
3) "bart"
Use ZRANK "leaderboard" "lise"
2
In Couchbase views values are always sorted by key. Even if we put levelScore as view key we still rely on time needed for index rebuild to get data consistency(like in Redis Sorted sets example) and can't fulfill project requirements.
Probably CouchBase fits more for storing documents and if we need to work with sorted by some values structures something similar to Redis should be added to the technology stack. Am i correct?
Upvotes: 2
Views: 390
Reputation: 12804
AFAIK there's no way to get an index updated immediately on couchbase, as all the indexes are eventually consistent. As you mentioned you can specify the consistency options in the query request, which can wait for the index to catch up with the pending mutations. It should not be very slow unless you have a lot of writes pending. If that's the case, you can scale up your index nodes.
As for the index itself, you should index by the score field in desc order, otherwise, the default order is asc and then the index won't be used efficiently for desc queries.
Upvotes: 0