Best Practice: View-Lookup vs Key-List in Document


#1

Hey,

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:

  1. Querying the Saved-Data is not possible right after saving something, as couchbase updates lazy by default (missing the latest saves in the result).
  2. 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))

Thanks,
Kademlia


C# Get list with a startkey
View best practice for data search
#2

Hi Kademlia,

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).


#3

Hey drigby,

you numbers are about right. I will try that approach.

Thanks for your reply,
Kademlia


#4

Hi,

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…

Thanks


#5

Hey,

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.