Hi Reddy,
On 2020-02-28 13:35, Reddy B. wrote:
Hello,
Congratulations for CouchDB 3.0, it truly looks like the best ever CouchDB version!
As I was reading the blog series, I immediately got concerned about the automatic
View Index Warming
feature<https://blog.couchdb.org/2020/02/26/the-road-to-couchdb-3-0-automatic-view-index-warming/>.
Is it opt-in or automatically enabled by default?
It's enabled by default.
If you want to ensure it's disabled, just add this to your local.ini
file before starting up, after the upgrade:
[ken]
batch_channels = 0
incremental_channels = 0
max_incremental_updates = 0
limit = 0
ken will still run, but should never queue a view for automatic indexing
in this situation.
I would hope it is opt-in because I see the fact that indexes are updated at
query time as a feature rather than as a bug. In particular I am thinking about
scenarios in which you have nodes only handling specific queries. Which is
particularly likely and easy to achieve if you use the Command/Query pattern in
your application layer.
Different users have different expectations, and picking a default
setting is always a compromise.
In general, since CouchDB 0.12, we've had more complaints of people
being upset that secondary indexes were *not* automatically warmed, than
people who *do* want them warmed. Automatically building those indexes
more closely aligns with other database systems' design choices, SQL and
no. Thus, the new default behaviour more closely aligns with that
industry norm.
Fortunately, it's an easy thing for you to alter.
You may for example decide that full text search queries go to a specific node,
queries for user profiles go to another node and so on. With the ability to
dynamically balance at peak times (all nodes may have all data replicated to
accommodate these situations etc... such logic is typically managed upstream
CouchDB).
I would consider this not the typical installation approach, but it's
certainly an option.
To make the sysadmin work easy you would simply replicate databases and handle
load balancing at the application layer. But if Automatic View Warming is
enabled it kinds of add friction. Now to be fair I see many scenarios, in which
automatic background warming is desirable, especially when there is low load
(which may describes 90% of applications being built out there). But I feel
that enabling this by default may be like treating a feature as a bug, while
view warming really is an optimization.
These are my thoughts but my specific question is: is this feature opt-in or
enabled by default? I couldn't figure it out by reading the docs. And also what
is your point of view about this?
Many thanks,
Reddy
-Joan
