Fix ambiguity in documentation on shards and replicas

[adrienverge]

The doc said:

If you have 4 shards, that means that you can have at most 4 nodes.

But at other places it states:

For systems with lots of small, infrequently accessed databases, or
for servers with fewer CPU cores, consider reducing this value to
1 or 2.

and:

In a default 3-node cluster, each node would receive 8 shards.

From my understanding, the number of shards can be anything, and even
q=1 will not alter safety of data. Only n can. If I understand
correctly:

• If you have 4 copies of a shard (n=4), that means that you can
  have at most 4 nodes.
• The number of nodes is not impacted by the number of shards (q).
• You can have safe clusters with n=3, q=1 (2 nodes can be down).

So this commit tries to make the doc clearer. -- Please tell me if I'm wrong!

[wohali]

This isn't accurate either, unfortunately. I think we need a more complete rewrite here.

If you have 4 copies of a shard, n=4, then you can still have 100 nodes in your cluster - but that specific shard replica will live at most on 4 of those nodes. If you have q=8 on top of your n=4, then you will use a maximum of 8 x 4 = 32 nodes in a 100 node cluster. Again, this is fine - if you had 4 databases with q=8 and n=4 you'd have at least one shard replica on every node, with some nodes having 2 replicas.

[wohali]

"means that all 4 copies of this specific shard will live on at most 4 nodes."

[wohali]

"No node can have more than one copy of each shard replica."

"The default for CouchDB since 2.0.0 is q=8 and n=3, meaning each database (and secondary index) is split into 8 shards, with 3 replicas per shard, for a total of 24 shard replica files.

"For a CouchDB cluster only hosting a single database with these default values, a maximum of 24 nodes can be used to scale horizontally."

[adrienverge]

Thanks for the explanation @wohali, it's clear now.

I've updated the pull request according to your suggestions.

[wohali]

Thanks for the help, @adrienverge !