What is a better / faster complex couchbase identifier or inline document type = "my_document_type"

Question

My current key keys contain from 3 or 4 segments:

namespace::my_key::id namespace::my_key::my_second_key::id 

Solution 1. Use a complex identifier and create views by searching by id for the key

 function (doc, meta) { if(meta.id.indexOf("::my_key::") !== -1){ emit([doc.source_id], [doc.name,doc.title,doc.ui]); } } 

Solution 2. For each document, add fields of type "type", "namespace", and types of creativity that use them

 function (doc, meta) { if(doc.type=='my_key'){ emit([doc.source_id], [doc.name,doc.title,doc.ui]); } } 

If I choose solution 2, I should support id in my application and probably will do the same as in solution 1.

Does anyone have experience in identifying names and creating from them? what problems you had with each of these solutions. Or maybe the indexOf () function is not recommended?

Answer 1

Couchbase creates a view index in the background, so if you do not use the stale=false parameter, you will get the same performance when retrieving documents from a view in both solutions.

In the first solution, you can probably get keys with a longer length than in the second, because in 2 solutions you can use the type in the document, not the meta. Couchbase contains all the metadata in memeory, so the longer keys you have, more memory is required. In addition, indexOf is slower than == or === , so the build index may take longer.

Since for me the second solution is better.

You can also improve the use of your disk representations by emmiting only emit(doc.source_id, null) and use IncludeDocs in your client library. This will reduce their size and hardly affect performance.

There is also a link for "best practice." Perhaps this will also help.

Answer 2

I use as your solution 1.

In my case (social game backend server), the key name indicates the saved data type, for example, "player: {zone_id]: {uid}", "playerchar: {zone_id]: {player_uid}: {char_id}", etc. Thus, I did not add the type field to the document, because the application knows what it wants, never requires information from the value to be reflected.

About performance / speed, I'm sorry, I could not give any suggestions, I have no requirement for query data with a view, all the views I created work only in the development and backup environment, and the work on data analysis and statistics is performed with another system, not Couchbase enabled.