Couchbase questions

1. During deployment we install Couchbase.

   Q: Dou you have recommendations how to automatically split allowed server memory between Couchbase services? Service Memory Quotas: Data/Index/Search/Eventing/Analytics

2. In our case we need to load some records from Couchbase (like openid tokens) in few milliseconds after persistence. This led to RP random failures. We have 2 solutions for this already:

   • add to N1QL quest scan consistency = REQUEST_PLUS.
   • we update our data structure to load token entry by key.

   Q: Which solution work qucker and will not led to random RP failues?

3. In GLuu we allow customers to use both LDAP and Couhcbase. Also we have converters to migrate DB from LDAP <-> Couchbase. As result we wrote persistence layer which is transparent for our applications. In few words applications don't know where it store data.

   Inside Couchbase module we convert LDAP filters to N1QL. Do you have any recommendations for us what we should do avoid in queries to get maximum performance with Couchbase?

4. We find out that Couchabse is very slow with queries like this. It's interesting because in all OR we use the same property:

select * from gluu where ( ( "top" IN objectClass AND "oxCustomScript" IN objectClass ) AND ( oxScriptType = "person_authentication" OR oxScriptType = "consent_gathering" OR oxScriptType = "client_registration" OR oxScriptType = "id_generator" OR oxScriptType = "uma_rpt_policy" OR oxScriptType = "uma_claims_gathering" OR oxScriptType = "application_session" OR oxScriptType = "dynamic_scope" OR oxScriptType = "introspection" OR oxScriptType = "resource_owner_password_credentials" ) )

But this one is very quick:

select * from gluu where ( ( "top" IN objectClass AND "oxCustomScript" IN objectClass ) 
AND ( oxScriptType IN ["person_authentication", "consent_gathering", "client_registration", "id_generator", "uma_rpt_policy" , "uma_claims_gathering", "application_session", "dynamic_scope", "introspection", "resource_owner_password_credentials"]  ))

Now our code automatically detect such queries and convert ... property_x = "value" OR ... to statement with IN.

Here is our recent stats from LDAP and Couchbase versions: LDAP: https://ce-dev5.gluu.org/ldap/06-25-19/01/db.txt Couchbase: https://ce-dev5.gluu.org/couchbase/06-25-19/01/db.txt

5. We also planning to automatically convert

select * from gluu where ( ( “top” IN objectClass AND “oxAuthToken” IN objectClass ) AND oxAuthTokenCode = “xyz”)

to

select * from gluu where ( ( “top” AND “oxAuthToken” IN objectClass ) AND oxAuthTokenCode = “xyz” )

Q: Is it can help to reduce query time from 0.026 to at least to 0.007 ?

6. Why Couchbase execute same query with not consistent execution time? We ran some queries in /query/workbench GUI and execution time was 5 ms - 20 ms.

7. Indexes. In LDAP we use minimum number of indexes because it's CPU havy process to maintains them. Are there no such limitations in Couchbase?

8. In GUI client we allow admin to find user by partial key:

SELECT gluu_doc.*, dn FROM `gluu_user` AS gluu_doc WHERE META().id LIKE "people%" AND ( ( "top" IN objectClass AND "gluuPerson" IN objectClass ) AND ( uid LIKE "%admin%" OR mail LIKE "%admin%" OR displayName LIKE "%admin%" OR iname LIKE "%admin%" OR oxPPID LIKE "%admin%" OR inum LIKE "%admin%" ) ) ORDER BY displayName

This query is very slow. How we can