Store related data on the same vBucket
How can I store a set a related data on the same vBucket?
I know this sounds odd, but my justification for wanting to do this is based on my understanding of the Couchbase architecture. For a given bucket (ex: default) all data is broken up into 1024 vbuckets. These vbuckets are stored on the Couchbase cluster. (If I had three servers, and 12 vbuckets, I could expect the following possible allocation of vbuckets across servers : server1 =>(1,2,3,4) server2=>(5,6,7,8) server3=>(9,10,11,12)).
My concern is that if server 2 dies, and the vbuckets on server 2 are unavailable, then I have (at a high level) 1/3 of all my data missing and no users can use the db reliably. However, if I know that I have a set of keys that, if stored on a given vbucket, could handle all queries for that user in isolation, I now have a 1/3 chance that a given user can't access my db, but 2/3 of my users are unaffected. (Yes, I know replication and rollover can help here). So, what I am wanting to do is for a set of keys, known to the client, store those keys on the same vbucket. I thought I could do this with the master_key parameter in the Php 1.0 Api, but that does not appear to work. The store_by_key in the c api seems to have what I want.
const void* hashkey This alternate hashkey allows a client application to group a set of unique keys together to a given server though the keys themselves may be unique. For example, you may wish to use the hashkey "user" for the two data keys "user:name" and "user:birthdate". Note that not all clients support this option so it may not be interoperable between clients.
How can I access the store_by_key from the Php Api? Would this method give me the funcitonality I am after?
How can I access the store_by_key from the Php Api? Would this method give me the funcitonality I am after?
As you can see the php extension uses simplified version of the store command, which doesn't allow to setup common key
https://github.com/couchbase/php-ext-couchbase/blob/master/couchbase.c#L...
But you can open the issue on jira, it will raise chances that such feature will get into nearest release.
You are correct that the store_by_key, or the way we talk about it amongst ourselves having a 'hashkey' separate from key would be the way to go. The main reason we've not done this to date (other than time/other priorities) is that it makes it a bit more likely that we could end up with unbalanced clusters. Combine that with our strategy for replication and failover, as you point out above, and there is not as much need for it.
At the moment there is no option for this, but if you wanted to try to make the addition to the client we'd be glad to work with you. All of the code for php-ext-couchbase is on github.com/couchbase and patches can be submitted to review.couchbase.org.