diff --git a/source/administration/tag-aware-sharding.txt b/source/administration/tag-aware-sharding.txt index f1ae3a171bc..d8cbd5744a6 100644 --- a/source/administration/tag-aware-sharding.txt +++ b/source/administration/tag-aware-sharding.txt @@ -27,7 +27,7 @@ sharding in MongoDB deployments. Shard key range tags are entirely distinct from :ref:`replica set member tags `. -:term:`Hash-based shading ` dose not support +:term:`Hash-based sharding ` does not support tag-aware sharding. Behavior and Operations diff --git a/source/core/indexes.txt b/source/core/indexes.txt index c102a04b1ee..efea4ba9d31 100644 --- a/source/core/indexes.txt +++ b/source/core/indexes.txt @@ -275,11 +275,9 @@ index, however, would not support queries that select the following: - only the ``item`` and ``stock`` fields .. important:: You may not create compound indexes that have - ``hashed`` index fields. - - :ref:`Hashed indexes ` do notare incompatible with - compound indexes. You will receive an error if you attempt to - create a compound index including a hashed index. + ``hashed`` index fields. You will receive an error if you attempt to + create a compound index that includes :ref:`a hashed index + `. When creating an index, the number associated with a key specifies the direction of the index. The options are ``1`` (ascending) and ``-1`` @@ -478,6 +476,9 @@ because of this unique constraint. You can combine with the :ref:`sparse index ` to filter these null values from the unique index. +You may not specify a unique constraint on a :ref:`hashed +index `. + .. index:: index; sparse .. _index-type-sparse: @@ -532,25 +533,25 @@ Hashed Index .. versionadded:: 2.4 -Hashed indexes maintain entries with hashes of the values the indexed -field. The hashing -function collapses sub-documents and computes the hash for the entire -value, but does not support multi-key (i.e. arrays) indexes. +Hashed indexes maintain entries with hashes of the values of the +indexed field. The hashing function collapses sub-documents and +computes the hash for the entire value but does not support multi-key +(i.e. arrays) indexes. -MongoDB can use the hashed index to support equality queries, but +MongoDB can use the ``hashed`` index to support equality queries, but ``hashed`` indexes do not support range queries. -You may not create compound indexes that have ``hashed`` index fields, -or specify a unique constraint on a hashed index; however, you can -create both a hashed and an ascending/descending (i.e. non-hashed) -index on the same field: MongoDB will use the scalar index for range -queries. +You may not create compound indexes that have ``hashed`` index fields +or specify a unique constraint on a ``hashed`` index; however, you can +create both a ``hashed`` index and an ascending/descending (i.e. +non-hashed) index on the same field: MongoDB will use the scalar index +for range queries. .. _hashed-index-warning: .. include:: /includes/warning-hashed-index-floating-point.rst -Create a hashed index using an operation that resembles the +Create a ``hashed`` index using an operation that resembles the following: .. code-block:: javascript @@ -560,7 +561,7 @@ following: This operation creates a hashed index for the ``active`` collection on the ``a`` field. -.. [#hash-size] The hash stored in the hashed index is 64 bits of the +.. [#hash-size] The hash stored in the ``hashed`` index is 64 bits of the 128 bit ``md5`` hash. .. index:: index; options diff --git a/source/core/sharded-cluster-internals.txt b/source/core/sharded-cluster-internals.txt index 3564985ef25..cb16788ac0b 100644 --- a/source/core/sharded-cluster-internals.txt +++ b/source/core/sharded-cluster-internals.txt @@ -230,15 +230,15 @@ single shard. Choosing a Shard Key ~~~~~~~~~~~~~~~~~~~~ -For many data sets, there may be no single, naturally occurring key in your -collection that possess all of the qualities of a good shard key. For -these cases, you may select one of the following strategies: +For many data sets, there may be no single, naturally occurring key in +your collection that possesses all of the qualities of a good shard +key. For these cases, you may select one of the following strategies: #. Compute a more ideal shard key in your application layer, and store this in all of your documents, potentially in the ``_id`` field. -#. Use a compound shard key, that uses two or three values from all +#. Use a compound shard key that uses two or three values from all documents that provide the right mix of cardinality with scalable write operations and query isolation. @@ -250,11 +250,11 @@ these cases, you may select one of the following strategies: - query patterns and demands. #. .. versionadded:: 2.4 - Use a :term:`hashed shard key`. With a hashed shard key you can - choose a field that has high cardinality and create a hashed - index on that field. MongoDB then uses the values of this - hashed index as the shard key values, thus ensuring an even - distribution across the shards. + Use a :term:`hashed shard key`. With a hashed shard key, you can + choose a field that has high cardinality and create a + :ref:`hashed indexes ` index on that field. + MongoDB then uses the values of this hashed index as the shard + key values, thus ensuring an even distribution across the shards. From a decision making stand point, begin by finding the field that will provide the required :ref:`query isolation @@ -333,12 +333,12 @@ cardinality but uneven distribution. .. example:: A hashed index on an :term:`ObjectId` will lead to an even - distribution of documents across all shards as the hash of two + distribution of documents across all shards since the hash of two sequential documents will have different hashes. .. note:: - :term:`Hash-based shading ` dose not support + :term:`Hash-based sharding ` does not support tag-aware sharding. .. include:: /includes/warning-hashed-index-floating-point.rst diff --git a/source/core/sharded-clusters.txt b/source/core/sharded-clusters.txt index c48db6bdea8..927f0f25219 100644 --- a/source/core/sharded-clusters.txt +++ b/source/core/sharded-clusters.txt @@ -111,9 +111,9 @@ Hashed Sharding The field you choose as your hashed shard key should have a good cardinality, or large number of different values. Hashed keys work well with fields that increase monotonically like :term:`ObjectId` -values or time stamps. +values or timestamps. -If you shard an collection that does not hold documents using hashed +If you shard an empty collection using a hashed shard key, MongoDB will automatically create and migrate chunks so that each shard has two chunks. You can control how many chunks MongoDB will create with the ``numInitialChunks`` parameter to @@ -125,10 +125,10 @@ See :ref:`index-hashed-index` for limitations on hashed indexes. .. warning:: - Hashed shard keys are only supported by MongoDB 2.4 and greater - versions of the :program:`mongos` program. After sharding a - collection with a hashed shard key you must use MongoDB 2.4 or - greater mongos instances in your sharded cluster. + Hashed shard keys are only supported by the MongoDB 2.4 and greater + versions of the :program:`mongos` program. After sharding a + collection with a hashed shard key, you must use the MongoDB 2.4 or + greater :program:`mongos` instances in your sharded cluster. .. index:: balancing .. _sharding-balancing: diff --git a/source/includes/warning-cannot-unshard-collection.rst b/source/includes/warning-cannot-unshard-collection.rst index ddb8fced8e8..8dd54f666e2 100644 --- a/source/includes/warning-cannot-unshard-collection.rst +++ b/source/includes/warning-cannot-unshard-collection.rst @@ -1,7 +1,7 @@ .. warning:: - MongoDB provides no method to deactivate sharding, after calling - :dbcommand:`shardCollection`. Additionally, after - :dbcommand:`shardCollection` you cannot change shard keys or modify + MongoDB provides no method to deactivate sharding for a collection + after calling :dbcommand:`shardCollection`. Additionally, after + :dbcommand:`shardCollection`, you cannot change shard keys or modify the value of any field used in your shard key index. diff --git a/source/includes/warning-hashed-index-floating-point.rst b/source/includes/warning-hashed-index-floating-point.rst index 1ee6d256294..9c9ef2628da 100644 --- a/source/includes/warning-hashed-index-floating-point.rst +++ b/source/includes/warning-hashed-index-floating-point.rst @@ -1,9 +1,9 @@ .. warning:: - Hashed indexes truncate floating point numbers to 64-bit integers - before hashing. For example, a hashed index would store the same + ``hashed`` indexes truncate floating point numbers to 64-bit integers + before hashing. For example, a ``hashed`` index would store the same value for a field that held a value of ``2.3``, ``2.2`` and ``2.9``. - To prevent collisions do not use a hashed index for floating point - numbers that cannot be consistently converted to 64-bit integers (and - then back to floating point.) Hashed indexes do not support floating - point values larger than 2\ :sup:`53`. + To prevent collisions, do not use a ``hashed`` index for floating + point numbers that cannot be consistently converted to 64-bit + integers (and then back to floating point.) ``hashed`` indexes do + not support floating point values larger than 2\ :sup:`53`. diff --git a/source/reference/command/shardCollection.txt b/source/reference/command/shardCollection.txt index 8b421fddfc7..a55a0fee8c7 100644 --- a/source/reference/command/shardCollection.txt +++ b/source/reference/command/shardCollection.txt @@ -13,12 +13,12 @@ shardCollection .. code-block:: javascript - { shardCollection: ".", key: } + { shardCollection: ".", key: } This enables sharding for the collection specified by - ```` in the database named ````, using the key + ```` in the database named ````, using the key ```` to distribute documents among the - shard. ```` is a document, and takes the same form as an + shard. ```` is a document and takes the same form as an :ref:`index specification document `. :param string shardCollection: @@ -35,7 +35,8 @@ shardCollection .. versionadded:: 2.4 The key may be in the form ``{ field : "hashed" }`` which will - use the specified field as a hashed shard key. + use the specified field as a :ref:`hashed shard key + ` . :param integer numInitialChunks: diff --git a/source/tutorial/deploy-shard-cluster.txt b/source/tutorial/deploy-shard-cluster.txt index f51b07b51b9..62c09876433 100644 --- a/source/tutorial/deploy-shard-cluster.txt +++ b/source/tutorial/deploy-shard-cluster.txt @@ -252,6 +252,7 @@ You enable sharding on a per-collection basis. sh.shardCollection("records.people", { "zipcode": 1, "name": 1 } ) sh.shardCollection("people.addresses", { "state": 1, "_id": 1 } ) sh.shardCollection("assets.chairs", { "type": 1, "_id": 1 } ) + db.alerts.ensureIndex( { _id : "hashed" } ) sh.shardCollection("events.alerts", { "_id": "hashed" } ) @@ -291,6 +292,6 @@ You enable sharding on a per-collection basis. This shard key distributes documents by a hash of the value of the ``_id`` field. MongoDB computes the hash of the ``_id`` - field through for the :ref:`hashed index `, + field for the :ref:`hashed index `, which should provide an even distribution of documents across a cluster.