@@ -198,8 +198,8 @@ the appropriate permissions for issuing :method:`sh.updateZoneKeyRange()`. See
198198the documentation page for :ref:`Role-Based Access Control <authorization>`
199199for more information.
200200
201- Example
202- -------
201+ Examples
202+ --------
203203
204204Given a sharded collection ``exampledb.collection`` with a shard key of ``{ a
205205: 1 }``, the following operation creates a range with a lower bound of ``1``
@@ -276,85 +276,94 @@ initial chunk creation and distribution. See
276276:ref:`updateZoneKeyRange-method-init-chunk-distribution-compound-hashed`
277277for more information.
278278
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.
281280
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+ `````````````````````````````
283292
284- .. tab:: Single or Compound Shard Keys
285- :tabid: single-or-compound
293+ .. note::
286294
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.
291297
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*.
320328
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+ ``````````````````````````````````````````````````````
357335
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
358367
359368.. seealso::
360369
0 commit comments