Skip to content

Commit 5042b39

Browse files
jmd-mongoandf-mongodb
authored andcommitted
DOCSP-13710 monotonically changing shard keys
1 parent 7e36eb5 commit 5042b39

File tree

1 file changed

+21
-17
lines changed

1 file changed

+21
-17
lines changed

source/core/sharding-shard-key.txt

Lines changed: 21 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -218,7 +218,7 @@ the cluster.
218218

219219
At minimum, consider the consequences of the
220220
:ref:`cardinality<shard-key-range>`, :ref:`frequency<shard-key-frequency>`, and
221-
rate of :ref:`change<shard-key-monotonic>` of a potential shard key.
221+
:ref:`monotonicity<shard-key-monotonic>` of a potential shard key.
222222

223223
Restrictions
224224
~~~~~~~~~~~~
@@ -264,11 +264,12 @@ inserts may look similar to the following:
264264
The cluster in this example would *not* scale horizontally, as incoming writes
265265
would only route to a subset of shards.
266266

267-
A shard key with high cardinality does not guarantee even distribution of data
268-
across the sharded cluster, though it does better facilitate horizontal
269-
scaling. The :ref:`frequency <shard-key-frequency>` and :ref:`rate of
270-
change <shard-key-monotonic>` of the shard key also contributes to data
271-
distribution. Consider each factor when choosing a shard key.
267+
Choosing a shard key with high cardinality does not, on its own,
268+
guarantee even distribution of data across the sharded cluster. The
269+
:ref:`frequency <shard-key-frequency>` and
270+
:ref:`monotonicity <shard-key-monotonic>` of the shard key also
271+
contribute to data distribution. Take each factor into account when
272+
choosing a shard key.
272273

273274
If your data model requires sharding on a key that has low cardinality,
274275
consider using a :term:`compound index` using a field that
@@ -293,19 +294,21 @@ distribution of inserts may look similar to the following:
293294

294295
.. include:: /images/sharded-cluster-ranged-distribution-frequency.rst
295296

296-
A shard key with low frequency does not guarantee even distribution of data
297-
across the sharded cluster. The :ref:`cardinality <shard-key-cardinality>` and
298-
:ref:`rate of change <shard-key-monotonic>` of the shard key also contributes
299-
to data distribution. Consider each factor when choosing a shard key.
297+
Choosing a shard key with low frequency does not, on its own, guarantee
298+
even distribution of data across the sharded cluster.
299+
The :ref:`cardinality <shard-key-cardinality>` and
300+
:ref:`monotonicity <shard-key-monotonic>` of the shard key also
301+
contribute to data distribution. Take each factor into account when
302+
choosing a shard key.
300303

301304
If your data model requires sharding on a key that has high frequency
302305
values, consider using a :term:`compound index` using a unique or
303306
low frequency value.
304307

305308
.. _shard-key-monotonic:
306309

307-
Monotonically Changing Shard Keys
308-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
310+
Shard Key Monotonicity
311+
~~~~~~~~~~~~~~~~~~~~~~
309312

310313
A shard key on a value that increases or decreases monotonically is more
311314
likely to distribute inserts to a single shard within the cluster.
@@ -331,11 +334,12 @@ distribution of inserts may look similar to the following:
331334
If the shard key value was monotonically decreasing, then all inserts would
332335
route to ``Chunk A`` instead.
333336

334-
A shard key that does not change monotonically does not guarantee even
335-
distribution of data across the sharded cluster. The
336-
:ref:`cardinality<shard-key-cardinality>` and
337-
:ref:`frequency<shard-key-frequency>` of the shard key also contributes to
338-
data distribution. Consider each factor when choosing a shard key.
337+
Choosing a shard key that does not change monotonically does not, on
338+
its own, guarantee even distribution of data across the sharded cluster.
339+
The :ref:`cardinality<shard-key-cardinality>` and
340+
:ref:`frequency<shard-key-frequency>` of the shard key also contribute
341+
to data distribution. Take each factor into account when choosing a
342+
shard key.
339343

340344
If your data model requires sharding on a key that changes
341345
monotonically, consider using :doc:`/core/hashed-sharding`.

0 commit comments

Comments
 (0)