@@ -198,8 +198,8 @@ the appropriate permissions for issuing :method:`sh.updateZoneKeyRange()`. See
198
198
the documentation page for :ref:`Role-Based Access Control <authorization>`
199
199
for more information.
200
200
201
- Example
202
- -------
201
+ Examples
202
+ --------
203
203
204
204
Given a sharded collection ``exampledb.collection`` with a shard key of ``{ a
205
205
: 1 }``, the following operation creates a range with a lower bound of ``1``
@@ -276,85 +276,94 @@ initial chunk creation and distribution. See
276
276
:ref:`updateZoneKeyRange-method-init-chunk-distribution-compound-hashed`
277
277
for more information.
278
278
279
- Each of the following tabs contains an example specific to the
280
- described shard key type:
279
+ The sections below contain examples for three different shard key types.
281
280
282
- .. tabs::
281
+ Consider the following examples, which explore pre-defining zones or
282
+ zone ranges for three different shard key types:
283
+
284
+ - :ref:`updatezonekeyrange-single-or-compound-example`
285
+ - :ref:`updatezonekeyrange-compound-prefix-hashed-example`
286
+ - :ref:`updatezonekeyrange-compound-non-prefix-hashed-example`
287
+
288
+ .. _updatezonekeyrange-single-or-compound-example:
289
+
290
+ Single or Compound Shard Keys
291
+ `````````````````````````````
283
292
284
- .. tab:: Single or Compound Shard Keys
285
- :tabid: single-or-compound
293
+ .. note::
286
294
287
- .. note::
288
-
289
- The content in this tab only applies to single-field or
290
- compound shard keys *without* a hashed field.
295
+ This example only applies to single-field or compound shard keys
296
+ *without* a hashed field.
291
297
292
- For example, ``{ "zip" : 1 }`` or
293
- ``{ "zip" : 1, "account" : 1}``
294
-
295
- .. include:: /includes/steps/zones-initial-chunk-distribution-single-compound.rst
296
-
297
- .. tab:: Compound Hashed Shard Key with Hashed Prefix
298
- :tabid: compound-hashed
299
-
300
- .. note::
301
-
302
- The content in this tab only applies to compound hashed shard
303
- keys where the hashed field is the prefix of the shard key (i.e.
304
- the first field in the shard key is hashed).
305
-
306
- For example, ``{ "_id" : "hashed", "facility" : 1 }``
307
-
308
- Starting in version 4.4, MongoDB supports sharding collections on
309
- :ref:`compound hashed indexes <index-type-compound-hashed>`. When
310
- sharding on a compound hashed shard key, MongoDB can perform
311
- optimized initial chunk creation and distribution on the empty or
312
- non-existing collection *only if* the defined zone ranges meet
313
- :ref:`additional requirements
314
- <updateZoneKeyRange-method-init-chunk-distribution>`.
315
-
316
- Consider an empty collection ``examples.metrics`` which will store
317
- analytics from one of two manufacturing facilities. The
318
- planned shard key is ``{ "_id" : "hashed", "facility" : 1}``,
319
- where the hashed field is the shard key *prefix*.
298
+ For example, ``{ "zip" : 1 }`` or
299
+ ``{ "zip" : 1, "account" : 1}``
300
+
301
+ .. include:: /includes/steps/zones-initial-chunk-distribution-single-compound.rst
302
+
303
+ .. _updatezonekeyrange-compound-prefix-hashed-example:
304
+
305
+ Compound Hashed Shard Key with Hashed Prefix
306
+ ````````````````````````````````````````````
307
+
308
+ .. note::
309
+
310
+ This example only applies to compound hashed shard keys where the
311
+ hashed field is the prefix of the shard key (i.e. the first field in
312
+ the shard key is hashed).
313
+
314
+ For example, ``{ "_id" : "hashed", "facility" : 1 }``
315
+
316
+ Starting in version 4.4, MongoDB supports sharding collections on
317
+ :ref:`compound hashed indexes <index-type-compound-hashed>`. When
318
+ sharding on a compound hashed shard key, MongoDB can perform
319
+ optimized initial chunk creation and distribution on the empty or
320
+ non-existing collection *only if* the defined zone ranges meet
321
+ :ref:`additional requirements
322
+ <updateZoneKeyRange-method-init-chunk-distribution>`.
323
+
324
+ Consider an empty collection ``examples.metrics`` which will store
325
+ analytics from one of two manufacturing facilities. The
326
+ planned shard key is ``{ "_id" : "hashed", "facility" : 1}``,
327
+ where the hashed field is the shard key *prefix*.
320
328
321
- .. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-prefix.rst
322
-
323
- .. tab:: Compound Hashed Shard Key with Non-Prefix Hashed Field
324
- :tabid: compound-hashed-no-prefix
325
-
326
- .. note::
327
-
328
- The content in this tab only applies to compound hashed shard
329
- keys where the hashed field is *not* the prefix of the shard key
330
- (i.e. the first field in the shard key is not hashed).
331
-
332
- For example, ``{ "facility" : 1, "_id" : "hashed" }``
333
-
334
- Starting in version 4.4, MongoDB supports sharding collections on
335
- :ref:`compound hashed indexes <index-type-compound-hashed>`. When
336
- sharding on a compound hashed shard key, MongoDB can perform
337
- optimized initial chunk creation and distribution on the empty or
338
- non-existing collection *only if* the defined zone ranges meet
339
- :ref:`additional requirements
340
- <updateZoneKeyRange-method-init-chunk-distribution>`.
341
-
342
- Consider an empty collection ``examples.metrics`` which will store
343
- analytics from one of two manufacturing facilities. The planned
344
- shard key is ``{ "facility" : 1, "_id" : "hashed" }``, where
345
- the hashed field is *not* the shard key prefix.
346
-
347
- - The ``facility`` field stores the name of the facility:
348
- ``"FacilityAlpha"`` or ``"FacilityBaker"``. The
349
- collection requires zone ranges on ``facility`` to help isolate
350
- data for each facility to specific shards.
351
-
352
- - The ``_id`` field compensates for the low-cardinality of the
353
- ``facility`` field. Hashing compensates for the
354
- monotonically-increasing nature of the ``_id`` field.
355
-
356
- .. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-non-prefix.rst
329
+ .. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-prefix.rst
330
+
331
+ .. _updatezonekeyrange-compound-non-prefix-hashed-example:
332
+
333
+ Compound Hashed Shard Key with Non-Prefix Hashed Field
334
+ ``````````````````````````````````````````````````````
357
335
336
+ .. note::
337
+
338
+ This example only applies to compound hashed shard keys where the
339
+ hashed field is *not* the prefix of the shard key (i.e. the first
340
+ field in the shard key is not hashed).
341
+
342
+ For example, ``{ "facility" : 1, "_id" : "hashed" }``
343
+
344
+ Starting in version 4.4, MongoDB supports sharding collections on
345
+ :ref:`compound hashed indexes <index-type-compound-hashed>`. When
346
+ sharding on a compound hashed shard key, MongoDB can perform
347
+ optimized initial chunk creation and distribution on the empty or
348
+ non-existing collection *only if* the defined zone ranges meet
349
+ :ref:`additional requirements
350
+ <updateZoneKeyRange-method-init-chunk-distribution>`.
351
+
352
+ Consider an empty collection ``examples.metrics`` which will store
353
+ analytics from one of two manufacturing facilities. The planned
354
+ shard key is ``{ "facility" : 1, "_id" : "hashed" }``, where
355
+ the hashed field is *not* the shard key prefix.
356
+
357
+ - The ``facility`` field stores the name of the facility:
358
+ ``"FacilityAlpha"`` or ``"FacilityBaker"``. The
359
+ collection requires zone ranges on ``facility`` to help isolate
360
+ data for each facility to specific shards.
361
+
362
+ - The ``_id`` field compensates for the low-cardinality of the
363
+ ``facility`` field. Hashing compensates for the
364
+ monotonically-increasing nature of the ``_id`` field.
365
+
366
+ .. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-non-prefix.rst
358
367
359
368
.. seealso::
360
369
0 commit comments