@@ -218,7 +218,7 @@ the cluster.
218
218
219
219
At minimum, consider the consequences of the
220
220
: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.
222
222
223
223
Restrictions
224
224
~~~~~~~~~~~~
@@ -264,11 +264,12 @@ inserts may look similar to the following:
264
264
The cluster in this example would *not* scale horizontally, as incoming writes
265
265
would only route to a subset of shards.
266
266
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.
272
273
273
274
If your data model requires sharding on a key that has low cardinality,
274
275
consider using a :term:`compound index` using a field that
@@ -293,19 +294,21 @@ distribution of inserts may look similar to the following:
293
294
294
295
.. include:: /images/sharded-cluster-ranged-distribution-frequency.rst
295
296
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.
300
303
301
304
If your data model requires sharding on a key that has high frequency
302
305
values, consider using a :term:`compound index` using a unique or
303
306
low frequency value.
304
307
305
308
.. _shard-key-monotonic:
306
309
307
- Monotonically Changing Shard Keys
308
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
310
+ Shard Key Monotonicity
311
+ ~~~~~~~~~~~~~~~~~~~~~~
309
312
310
313
A shard key on a value that increases or decreases monotonically is more
311
314
likely to distribute inserts to a single shard within the cluster.
@@ -331,11 +334,12 @@ distribution of inserts may look similar to the following:
331
334
If the shard key value was monotonically decreasing, then all inserts would
332
335
route to ``Chunk A`` instead.
333
336
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.
339
343
340
344
If your data model requires sharding on a key that changes
341
345
monotonically, consider using :doc:`/core/hashed-sharding`.
0 commit comments