DOCSP-13710 monotonically changing shard keys

Author: jmd-mongo

source/core/sharding-shard-key.txt

@@ -213,7 +213,7 @@ the cluster. See also :ref:`sharding strategy <sharding-strategy>`.
 
 At minimum, consider the consequences of the
 :ref:`cardinality<shard-key-range>`, :ref:`frequency<shard-key-frequency>`, and
-rate of :ref:`change<shard-key-monotonic>` of a potential shard key.
+:ref:`monotonicity<shard-key-monotonic>` of a potential shard key.
 
 .. note::
 
@@ -269,11 +269,12 @@ inserts may look similar to the following:
 The cluster in this example would *not* scale horizontally, as incoming writes
 would only route to a subset of shards.
 
-A shard key with high cardinality does not guarantee even distribution of data
-across the sharded cluster, though it does better facilitate horizontal
-scaling. The :ref:`frequency <shard-key-frequency>` and :ref:`rate of
-change <shard-key-monotonic>` of the shard key also contributes to data
-distribution. Consider each factor when choosing a shard key.
+Choosing a shard key with high cardinality does not, on its own, 
+guarantee even distribution of data across the sharded cluster. The 
+:ref:`frequency <shard-key-frequency>` and 
+:ref:`monotonicity <shard-key-monotonic>` of the shard key also 
+contribute to data distribution. Take each factor into account when 
+choosing a shard key.
 
 If your data model requires sharding on a key that has low cardinality,
 consider using a :term:`compound index` using a field that
@@ -298,19 +299,21 @@ distribution of inserts may look similar to the following:
 
 .. include:: /images/sharded-cluster-ranged-distribution-frequency.rst
 
-A shard key with low frequency does not guarantee even distribution of data
-across the sharded cluster. The :ref:`cardinality <shard-key-cardinality>` and
-:ref:`rate of change <shard-key-monotonic>` of the shard key also contributes
-to data distribution. Consider each factor when choosing a shard key.
+Choosing a shard key with low frequency does not, on its own, guarantee 
+even distribution of data across the sharded cluster. 
+The :ref:`cardinality <shard-key-cardinality>` and 
+:ref:`monotonicity <shard-key-monotonic>` of the shard key also 
+contribute to data distribution. Take each factor into account when 
+choosing a shard key.
 
 If your data model requires sharding on a key that has high frequency
 values, consider using a :term:`compound index` using a unique or
 low frequency value.
 
 .. _shard-key-monotonic:
 
-Monotonically Changing Shard Keys
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Shard Key Monotonicity
+~~~~~~~~~~~~~~~~~~~~~~
 
 A shard key on a value that increases or decreases monotonically is more
 likely to distribute inserts to a single shard within the cluster.
@@ -336,11 +339,12 @@ distribution of inserts may look similar to the following:
 If the shard key value was monotonically decreasing, then all inserts would
 route to ``Chunk A`` instead.
 
-A shard key that does not change monotonically does not guarantee even
-distribution of data across the sharded cluster. The
-:ref:`cardinality<shard-key-cardinality>` and
-:ref:`frequency<shard-key-frequency>` of the shard key also contributes to
-data distribution. Consider each factor when choosing a shard key.
+Choosing a shard key that does not change monotonically does not, on 
+its own, guarantee even distribution of data across the sharded cluster. 
+The :ref:`cardinality<shard-key-cardinality>` and
+:ref:`frequency<shard-key-frequency>` of the shard key also contribute
+to data distribution. Take each factor into account when choosing a 
+shard key.
 
 If your data model requires sharding on a key that changes
 monotonically, consider using :doc:`/core/hashed-sharding`.