minor copy edits

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 <replica-set-read-preference-tag-sets>`.
 
-:term:`Hash-based shading <hashed shard key>` dose not support
+:term:`Hash-based sharding <hashed shard key>` does not support
 tag-aware sharding.
 
 Behavior and Operations

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 <index-hashed-index>` 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
+   <index-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 <index-type-sparse>` to filter these null values
 from the unique index.
 
+You may not specify a unique constraint on a :ref:`hashed
+index <index-type-hashed>`.
+
 .. 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

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-hashed-index>` 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 <hashed shard key>` dose not support
+   :term:`Hash-based sharding <hashed shard key>` does not support
    tag-aware sharding.
 
 .. include:: /includes/warning-hashed-index-floating-point.rst

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:

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.
 

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`.

source/reference/command/shardCollection.txt

@@ -13,12 +13,12 @@ shardCollection
 
    .. code-block:: javascript
 
-      { shardCollection: "<dabase>.<collection>", key: <shardkey> }
+      { shardCollection: "<database>.<collection>", key: <shardkey> }
 
    This enables sharding for the collection specified by
-   ``<collection>`` in the database named ``<db>``, using the key
+   ``<collection>`` in the database named ``<database>``, using the key
    ``<shardkey>`` to distribute documents among the
-   shard. ``<shardkey>`` is a document, and takes the same form as an
+   shard. ``<shardkey>`` is a document and takes the same form as an
    :ref:`index specification document <document-index-specification>`.
 
    :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
+         <sharding-hashed-shard-key-internals>` .
 
    :param integer numInitialChunks:
 

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 <index-hashed-index>`,
+      field for the :ref:`hashed index <index-hashed-index>`,
       which should provide an even distribution of documents across a
       cluster.