Suppose I have the following use case: I use Couchbase to store user accounts. Each user have a list of phone numbers associated to him/her, and two different users can’t share the same phone number. The key (KV key) is a randomly generated UUID. The default mode for authentication and new account creation is via phone number + password.
Each time a user authenticates/creates a new account, the system will need to look up if the phone number has been used, so somehow, I have to index these numbers.
Now, there are 3 different ways to do it View, GIS and manual secondary indexing (à la http://blog.couchbase.com/manual-secondary-indexes). I’ve tried GIS (I’m aware that it hasn’t supported indexing for arrays yet, so I just did for the case where each user has 1 phone number for testing purposes) and got very slow performance: 100 N1QL queries per second and hence, only around 100 new account creation per second (number of index scans is around 100 per sec as well).
To compare, I tested creating new accounts without checking if phone number has been used (i.e. no use of N1QL query to find out about the phone) and I got very high performance (couple of thousands).
So it seems like looking up secondary indexes is quite slow. Is this the expected behavior? If not what should I do to fix. Would View or Manual secondary indexing improve the performance?
Thanks!