Edited 410_Scaling/15_Shard.asciidoc with Atlas code editor

410_Scaling/15_Shard.asciidoc

@@ -1,15 +1,15 @@
 [[shard-scale]]
-=== The unit of scale
+=== The Unit of Scale
 
-In <<dynamic-indices>> we explained that a shard is a _Lucene index_ and that
+In <<dynamic-indices>>, we explained that a shard is a _Lucene index_ and that
 an Elasticsearch index is a collection of shards.((("scaling", "shard as unit of scale"))) Your application talks to an
 index, and Elasticsearch routes your requests to the appropriate shards.
 
 A shard is the _unit of scale_. ((("shards", "as unit of scale"))) The smallest index you can have is one with a
-single shard.  This may be more than sufficient for your needs -- a single
-shard can hold a lot of data -- but it limits your ability to scale.
+single shard. This may be more than sufficient for your needs--a single
+shard can hold a lot of data--but it limits your ability to scale.
 
-Imagine that our cluster consists of one node, in our cluster we have one
+Imagine that our cluster consists of one node, and in our cluster we have one
 index, which has only one shard:
 
 [source,json]
@@ -29,13 +29,13 @@ This setup may be small, but it serves our current needs and is cheap to run.
 [NOTE]
 ==================================================
 
-At the moment we are talking only about _primary_ shards.((("primary shards")))  We will discuss
-_replica_ shards later on in <<replica-shards>>.
+At the moment we are talking about only _primary_ shards.((("primary shards")))  We discuss
+_replica_ shards in <<replica-shards>>.
 
 ==================================================
 
 One glorious day, the Internet discovers us, and a single node just can't keep up with
-the traffic.  We decide to add a second node.  What happens?
+the traffic.  We decide to add a second node, as per <<img-one-shard>>. What happens?
 
 [[img-one-shard]]
 .An index with one shard has no scale factor
@@ -49,7 +49,7 @@ because the number of shards is an important element in the algorithm used to
     shard = hash(routing) % number_of_primary_shards
 
 Our only option now is to reindex our data into a new, bigger index that has
-more shards, but that will take time which we can ill afford.  By planning
+more shards, but that will take time that we can ill afford.  By planning
 ahead, we could have avoided this problem completely by _overallocating_.