We are working on moving one of the database tables in our application to couchbase. One of the issues is that some of the legacy business logic needs to look up our entities by non-primary keys, and these secondary keys are small in number (by way of example, if the entity is “car” and the primary key is the car’s VIN number, a secondary key might be the color of the car.) So a reference document that lists all “red” cars will have to contain large numbers of primary key values. This leads to efficiency concerns when making mass state changes. Again using an automotive example, say we had an operation that painted all of the cars on our lot black at once. The ref doc containing each color will suddenly face a lot of near simultanous deletions, while the “black” ref doc will get a lot of rapid adds.
So we are wondering if there is an alternative that avoids contention issues (if say we believed that we absolutely needed data integrity in these cases). In our present case, we are already reconsidering as we had originally implemented these examples using views, and that alternative is looking more attractive now.