We use views to query data in couchbase. Is there a way to update a development view without taking down our production views? Ideally I would like to freely update development views and experiment with them without taking down production which relies on our production views. Today I updated the map function of one of my development views, and now all my design docs are taking a significantly longer time to index than they normally would. They usually take about 15 seconds to pick up new updates and finish indexing, but now they are all taking over an hour, even though only one design doc was updated so the rest of them should only be processing the latest updates. I’m used to this with my other development views, but my production views have also been effectively stopped. I did specify Full Cluster on the dev view I changed because often the Development subset does not include enough documents to actually display any results. I’m using Couchbase Server 3.1.
What you’re doing is correct. There shouldn’t be any impact to production views by editing and building development views. My guess is that because you’re using full_set on the development views, there is competition for resources. Those might be IO or processing resources.
Do you see the same effect if not using full_set?
Unfortunately I can’t really test that yet because it is our production server and I can’t risk it going down again. I will test on a new server with a backup of that db when I can.
I used Full Cluster Data Set, but when we run queries against the dev views we also specify full_set=true.
This is not recommended, because that means that your query will be executed on all nodes of the cluster and merged back after it. Without this flag it will only use local partition
The primary place to use full_set is when building the development index before 'publish’ing it into production.
Yes, that’s the scenario I’m concerned about. Say I’ve finished updating my view and I want to publish it, will building that full set index and publishing the view affect the other production views?
There is no functional affect, but It can in that they both share the same resources.
The intent of this feature is that you’d do the full build ‘off peak’ and the overall system would be sized to complete it before ramping up to peak again.
It’s now several years since we planned this feature, but we were cognizant of the difficulty of index changes/rebuilds on other systems so the ability to atomically swap in an index is definitely an advantage. On some systems, fragmented indexes or index rebuilds can’t be done concurrently with using the old index. We can control that, but we don’t currently have any fine-grained resource management for index building compared to index usage.