Specifically, n is the number of copies of your data, not the number of nodes
in the system. You can tweak read concurrency performance by increasing a
database’s number of shards (q) and adding more nodes for those shards to live
on, at the expense of view, all_docs and changes requests becoming more
expensive.
> On 12. Mar 2019, at 08:08, Vladimir Ralev <vladimir.ra...@gmail.com> wrote:
>
> OK, I see. Thank you.
>
> On Mon, Mar 11, 2019 at 8:48 PM Robert Newson <rnew...@apache.org> wrote:
>
>> Hi,
>>
>> Yes, you will have 4 copies of your data, your nodes will be mirrors of
>> each other in effect.
>>
>> R and W only control one thing; the number of replies we wait for before
>> returning your response. All N requests are made, in parallel, no matter
>> what setting for R or W you use. You're not saving I/O by changing it, you
>> are just modifying your latency (lower values of R and W will lower request
>> latency) and consistency (higher values of R and W will improve
>> consistency, though nothing delivers strong consistency in CouchDB).
>>
>> Your understanding is not quite right, and so there neither are the
>> inferences made from that base.
>>
>> B.
>>
>> --
>> Robert Samuel Newson
>> rnew...@apache.org
>>
>> On Mon, 11 Mar 2019, at 15:25, Vladimir Ralev wrote:
>>> Ah thanks a lot for the reply.
>>>
>>> The idea for n = 4 is both fault tolerance and performance. Since I have
>>> very few writes, I expect replication IO and view indexing IO to be
>> minimal
>>> and I have no issues with temporary inconsistencies and conflicts.
>>>
>>> My understanding is that since there are very few writes, the 4 nodes
>> will
>>> behave almost like 4 independent single nodes and will be able to serve
>> the
>>> read requests independently without having to proxy to cluster peers and
>>> thus avoiding a great deal of extra network and disk IO.
>>>
>>> R=3 to me means 3 times the IO and thus 3 machines will be busy for the
>>> same read request instead of serving other requests. Which I understand
>> is
>>> 3 times less performance from the cluster as a whole.
>>>
>>> If my understanding is correct, I imagine this would be a common use-case
>>> for couch?
>>>
>>> On Mon, Mar 11, 2019 at 4:58 PM Robert Newson <rnew...@apache.org>
>> wrote:
>>>
>>>> r and w are no longer configurable from the config file by design. The
>>>> default is n/2+1 (so 3 in your case) unless you specify r or w as
>> request
>>>> parameters.
>>>>
>>>> setting n = 4 for a 4 node cluster is very unusual, do you really need
>> 4
>>>> full copies of your data?
>>>>
>>>> couchdb will also automatically lower both r and w if nodes are
>> offline.
>>>>
>>>> The default of n=3, r=w=2 is appropriate in almost all cases as the
>> right
>>>> balance between data safety and availability. Nothing you've said so
>> far
>>>> suggests it would be good to deviate from those settings.
>>>>
>>>> --
>>>> Robert Samuel Newson
>>>> rnew...@apache.org
>>>>
>>>> On Mon, 11 Mar 2019, at 14:52, Vladimir Ralev wrote:
>>>>> Hi all,
>>>>>
>>>>> I am looking into running a 4-node couchdb 2.3 with this config in
>>>>> default.ini and I made sure no other config file override them:
>>>>> [cluster]
>>>>> q = 8
>>>>> n = 4
>>>>> r = 1
>>>>> w = 1
>>>>>
>>>>> But when i create a test DB and check the settings I get:
>>>>> curl -s couch01:5984/mytest1234 |jq . .... .... "cluster": { "q": 8,
>>>> "n": 4,
>>>>> "w": 3, "r": 3 },
>>>>>
>>>>> r and w settings are not respected and seem stuck to be the defaults.
>>>>>
>>>>> When I kill 3 of the machine and test reads and writes, they still
>> work
>>>>> fine so it doesn't seem like the r and w are actually 3 either. I
>> checked
>>>>> if the debug logs printed out the r and w anywhere to confirm what is
>>>> being
>>>>> configured or executed but there is nothing.
>>>>>
>>>>> It is unclear if r and w are active in this version of couch. I can
>> see
>>>>> the
>>>>> they have been partially removed from the documentation
>>>>> https://docs.couchdb.org/en/master/cluster/theory.html as opposed to
>>>>> couchdb 2.0.0 original doc
>>>>>
>>>>
>> https://web.archive.org/web/20160109122310/https://docs.couchdb.org/en/stable/cluster/theory.html
>>>>>
>>>>> Additionally curl -s couch01:5984/mytest1234/doc?r=3
>>>>> still works even if 3 out of the 4 nodes are dead which is
>> unexpected per
>>>>> the quorum documentation here
>>>>> https://docs.couchdb.org/en/master/cluster/sharding.html#quorum
>>>>>
>>>>> My specific concern with r and w is that if r is 3 this means 3 times
>>>> more
>>>>> network and disk IO since it will have to read 3 times from remote
>>>>> machines. My use case really doesn't need this and performance will
>>>> suffer.
>>>>> This is a little hard to test so I was hopinh someone can shed some
>> light
>>>>> on the current situation with r and w in couch 2.3.
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
