i am trying to implement a game-data-storage for users/players.
The users can save data via ingame-command (eg. /save test, /save myHouse)
and they can lookup their saves via command (eg. /listsaves)
I implemented the listing with a View. My Code would filter the keys “area:USERUID:name”.
The docs only contain small JsonDocs with information about the data, not the saved data itself
function (doc, meta){
if(meta.id.indexOf("area:") !== -1){
emit(meta.id, doc);
}
}
This results in two problems:
Querying the Saved-Data is not possible right after saving something, as couchbase updates lazy by default (missing the latest saves in the result).
Using stale=false in the View-Query results in bad response times and i imagine high server-load because of the re-indexing on every query.
A possible solution I am considering is to not use a View at all:
Maintaining a List-Document that contains all saved keys of a user
Update the List-Document on every save/delete action of a user
Receive a list of saved userdata via the List-Document instead of a View
My question now is: Is this the right approach or are there better ways to achieve the goal? Goal = Fast responsetime and correct listing of saved data right after saving new data.
(Version: 3.0.1 Enterprise Edition (build-1444))
How many saves do you expect per user? If this is a relatively small number (say few tens/hundred), then a list document is likely to be better suited to your requirements (or even embed the list in the user document).
Do you have any code example regarding to that user List-Document?
I have situation when I have lot of users with type “user” in the bucket and I want get list of all users from bucket (my bucket contains different type data not just user data) and I want to do that without map reduce or N1SQL and I can see you been working on similar problem…
the document approach would not be suitable in your case i think.
In my case i would have a list of 1-500 entries ( 99% below 50). This listing-document needs to be re-written to the Database every time the user inserts a new thing or removes one. In your case the listing would need to be rewritten every time a new user is created or removed.
If you ‘have lot of users’ managing a listing-document would not be a good approach. You should use the views and possibly query range-based ( user:0 to user:1 … user:a to user:b ) if you run into problems.
And you might think about if the ‘stale=false’ setting is necessary in your case. This setting increases the query-time a lot.
However i did not change my setup by now. I’m still using views because i’m using a better machine and the serverload is globally still pretty low.