Changes in ellen_troutman-at29536905925 branch

Author: skalapurakkel

010_Intro/10_Installing_ES.asciidoc

@@ -34,7 +34,7 @@ https://github.com/elasticsearch/cookbook-elasticsearch[Chef cookbook].
 
 http://www.elasticsearch.com/products/marvel[Marvel] is a management((("Marvel", "defined"))) and monitoring
 tool for Elasticsearch, which is free for development use. It comes with an
-interactive console called Sense, which makes it easy to talk to
+interactive console called Sense,((("Sense console (Marvel plugin)"))) which makes it easy to talk to
 Elasticsearch directly from your browser.
 
 Many of the code examples in the online version of this book include a View in Sense link. When
@@ -124,6 +124,6 @@ If you installed the <<marvel,Marvel>> management ((("Marvel", "viewing")))and m
 view it in a web browser by visiting
 http://localhost:9200/_plugin/marvel/.
 
-You can reach the _Sense_ developer((("Sense", "viewing developer console"))) console either by clicking the ``Marvel
+You can reach the _Sense_ developer((("Sense console (Marvel plugin)", "viewing"))) console either by clicking the ``Marvel
 dashboards'' drop-down in Marvel, or by visiting
 http://localhost:9200/_plugin/marvel/sense/.

010_Intro/15_API.asciidoc

@@ -35,7 +35,7 @@ of the http://www.elasticsearch.org/guide/[Guide].
 ==== RESTful API with JSON over HTTP
 
 All other languages can communicate with Elasticsearch((("port 9200 for non-Java clients"))) over port _9200_ using
-a ((("RESTful API", "communicating with Elasticseach")))RESTful API, accessible with your favorite web client. In fact, as you have
+a ((("RESTful API, communicating with Elasticseach")))RESTful API, accessible with your favorite web client. In fact, as you have
 seen, you can even talk to Elasticsearch from the command line by using the
 `curl` command.((("curl command", "talking to Elasticsearch with")))
 
@@ -128,6 +128,6 @@ GET /_count
 --------------------------------------------------
 // SENSE: 010_Intro/15_Count.json
 
-In fact, this is the same format that is used by the ((("Sense", "curl requests in")))Sense console that we
+In fact, this is the same format that is used by the ((("Marvel", "Sense console")))((("Sense console (Marvel plugin)", "curl requests in")))Sense console that we
 installed with <<marvel,Marvel>>. If in the online version of this book, you can open and run this code example in
 Sense by clicking the View in Sense link above.

010_Intro/25_Tutorial_Indexing.asciidoc

@@ -35,7 +35,7 @@ employee.  The act of storing data in Elasticsearch is called _indexing_, but
 before we can index a document, we need to decide _where_ to store it.
 
 In Elasticsearch, a document belongs to a _type_, and those((("types"))) types live inside
-an _index_. You can draw some (rough) parallels to a traditional relational database:
+an _index_. ((("indices")))You can draw some (rough) parallels to a traditional relational database:
 
 ----
 Relational DB  ⇒ Databases ⇒ Tables ⇒ Rows      ⇒ Columns
@@ -68,9 +68,9 @@ replace the old.
 
 Inverted index::
 
-Relational databases add an _index_, such as a B-tree index,((("relational databases", "indexes"))) to specific
+Relational databases add an _index_, such as a B-tree index,((("relational databases", "indices"))) to specific
 columns in order to improve the speed of data retrieval.  Elasticsearch and
-Lucene use a structure called((("inverted indexes"))) an _inverted index_ for exactly the same
+Lucene use a structure called((("inverted index"))) an _inverted index_ for exactly the same
 purpose.
 +
 By default, every field in a document is _indexed_ (has an inverted index)

010_Intro/30_Tutorial_Search.asciidoc

@@ -5,7 +5,7 @@ business requirements for this application.  The first requirement is the
 ability to retrieve individual employee data.
 
 This is easy in Elasticsearch.  We simply execute((("HTTP requests", "retrieving a document with GET"))) an HTTP +GET+ request and
-specify the _address_ of the document--the index, type, and ID.((("id", "speccifying in a request")))((("indexes", "specifying index in a request")))((("types", "specifying type in a request")))  Using
+specify the _address_ of the document--the index, type, and ID.((("id", "specifying in a request")))((("indices", "specifying index in a request")))((("types", "specifying type in a request")))  Using
 those three pieces of information, we can return the original JSON document:
 
 [source,js]
@@ -15,7 +15,7 @@ GET /megacorp/employee/1
 // SENSE: 010_Intro/30_Get.json
 
 And the response contains some metadata about the document, and John Smith's
-original JSON document ((("source field")))as the `_source` field:
+original JSON document ((("_source field", sortas="source field")))as the `_source` field:
 
 [source,js]
 --------------------------------------------------
@@ -260,7 +260,7 @@ range search, and reused the same `match` query as before.  Now our results show
 === Full-Text Search
 
 The searches so far have been simple:  single names, filtered by age. Let's
-try a more advanced, full-text search--a ((("full-text search")))task that traditional databases
+try a more advanced, full-text search--a ((("full text search")))task that traditional databases
 would really struggle with.
 
 We are going to search for all employees who enjoy rock climbing:
@@ -334,7 +334,7 @@ traditional relational databases, in which a record either matches or it doesn't
 === Phrase Search
 
 Finding individual words in a field is all well and good, but sometimes you
-want to match exact sequences of words or _phrases_.((("prhase search"))) For instance, we could
+want to match exact sequences of words or _phrases_.((("phrase matching"))) For instance, we could
 perform a query that will match only employee records that contain both  ``rock''
 _and_ ``climbing'' _and_ that display the words are next to each other in the phrase
 ``rock climbing.''

020_Distributed_Cluster/00_Intro.asciidoc

@@ -17,7 +17,7 @@ to skim through the chapter and to refer to it again later.
 
 ****
 
-Elasticsearch is built to be ((("scalability", "Elasticsearch and")))always available, and to scale with your needs.
+Elasticsearch is built to be ((("scalability, Elasticsearch and")))always available, and to scale with your needs.
 Scale can come from buying bigger ((("vertical scaling, Elasticsearch and")))servers (_vertical scale_, or _scaling up_)
 or from buying more ((("horizontal scaling, Elasticsearch and")))servers (_horizontal scale_, or _scaling out_).
 

020_Distributed_Cluster/15_Add_an_index.asciidoc

@@ -1,7 +1,7 @@
 === Add an Index
 
 To add data to Elasticsearch, we need an _index_—a place to store related
-data.((("indexes")))((("clusters", "adding an index")))  In reality, an index is just a _logical namespace_ that points to
+data.((("indices")))((("clusters", "adding an index")))  In reality, an index is just a _logical namespace_ that points to
 one or more physical _shards_.
 
 A _shard_ is a low-level _worker unit_ that holds((("shards", "defined"))) just a slice of all the
@@ -37,8 +37,8 @@ serve read requests like searching or retrieving a document.
 The number of primary shards in an index is fixed at the time that an index is
 created, but the number of replica shards can be changed at any time.
 
-Let's create an index called `blogs` in our empty one-node cluster.((("indexes", "creating"))) By
-default, indices are assigned five primary shards,((("primary shards", "assigned to indexes")))((("replica shards", "assigned to indexes"))) but for the purpose of this
+Let's create an index called `blogs` in our empty one-node cluster.((("indices", "creating"))) By
+default, indices are assigned five primary shards,((("primary shards", "assigned to indices")))((("replica shards", "assigned to indices"))) but for the purpose of this
 demonstration, we'll assign just three primary shards and one replica (one replica
 of every primary shard):
 

020_Distributed_Cluster/20_Add_failover.asciidoc

@@ -1,7 +1,7 @@
 === Add Failover
 
 Running a single node means that you have a single point of failure--there
-is no redundancy.((("failover", "adding"))) Fortunately, all we need to do to protect ourselves from data
+is no redundancy.((("failover, adding"))) Fortunately, all we need to do to protect ourselves from data
 loss is to start another node.
 
 .Starting a Second Node

020_Distributed_Cluster/25_Scale_horizontally.asciidoc

@@ -1,6 +1,6 @@
 === Scale Horizontally
 
-What about scaling as the demand for our application grows?((("scaling horizontally")))((("clusters", "three-node cluster")))((("primary shards", "in three-node cluster"))) If we start a
+What about scaling as the demand for our application grows?((("scaling", "horizontally")))((("clusters", "three-node cluster")))((("primary shards", "in three-node cluster"))) If we start a
 third node, our cluster reorganizes itself to look like
 <<cluster-three-nodes>>.
 

020_Distributed_Cluster/30_Scale_more.asciidoc

@@ -2,13 +2,13 @@
 
 But what if we want to scale our search to more than six nodes?
 
-The number of primary shards is fixed at the moment an((("indexes", "fixed number of primary shards")))((("primary shards", "fixed number in an index"))) index is created.
+The number of primary shards is fixed at the moment an((("indices", "fixed number of primary shards")))((("primary shards", "fixed number in an index"))) index is created.
 Effectively, that number defines the maximum amount of data that can be
 _stored_ in the index.  (The actual number depends on your data, your hardware
 and your use case.) However, read requests--searches or document retrieval--can be handled by a primary _or_ a replica shard, so the more copies of
 data that you have, the more search throughput you can handle.
 
-The number of replica shards can be changed dynamically on a live cluster,
+The number of ((("scaling", "increasing number of replica shards")))replica shards can be changed dynamically on a live cluster,
 allowing us to scale up or down as demand requires. Let's increase the number
 of replicas from the default of `1` to `2`:
 

020_Distributed_Cluster/35_Coping_with_failure.asciidoc

@@ -1,7 +1,7 @@
 === Coping with Failure
 
 We've said that Elasticsearch can cope when nodes fail, so let's go
-ahead and try it out. ((("shards", "horizontal scaling and safety of data")))((("failure", "coping with")))((("master node", "killing and replacing")))((("nodes", "failure of")))((("clusters", "coping with failure of nodes")))If we kill the first node, our cluster looks like
+ahead and try it out. ((("shards", "horizontal scaling and safety of data")))((("failure of nodes, coping with")))((("master node", "killing and replacing")))((("nodes", "failure of")))((("clusters", "coping with failure of nodes")))If we kill the first node, our cluster looks like
 <<cluster-post-kill>>.
 
 [[cluster-post-kill]]

030_Data/00_Intro.asciidoc

@@ -43,7 +43,7 @@ objects as documents, they still require us to think about how we want to
 query our data, and which fields require an index in order to make data
 retrieval fast.
 
-In Elasticsearch, _all data in every field_ is _indexed by default_. That is,
+In Elasticsearch, _all data in every field_ is _indexed by default_.((("indexing", "in Elasticsearch"))) That is,
 every field has a dedicated inverted index for fast retrieval. And, unlike
 most other databases, it can use all of those inverted indices _in the same
 query_, to return results at breathtaking speed.

030_Data/05_Document.asciidoc

@@ -58,13 +58,13 @@ elements are as follows:
 ==== _index
 
 An _index_ is like a database in a relational database; it's the place
-we store and index related data.((("indexes")))
+we store and index related data.((("indices", "_index, in document metadata")))
 
 [TIP]
 ====
 Actually, in Elasticsearch, our data is stored and indexed in _shards_,
 while an index is just a logical namespace that groups together one or more
-shards.((("shards", "grouped in indexes"))) However, this is an internal detail; our application shouldn't care
+shards.((("shards", "grouped in indices"))) However, this is an internal detail; our application shouldn't care
 about shards at all.  As far as our application is concerned, our documents
 live in an _index_. Elasticsearch takes care of the details.
 ====
@@ -83,7 +83,7 @@ may have a name, a gender, an age, and an email address.
 
 In a relational database, we usually store objects of the same class in the
 same table, because they share the same data structure. For the same reason, in
-Elasticsearch we use the same _type_ for ((("types")))documents that represent the same
+Elasticsearch we use the same _type_ for ((("types", "_type, in document metadata)))documents that represent the same
 class of _thing_, because they share the same data structure.
 
 Every _type_ has its own <<mapping,mapping>> or schema ((("mapping (types)")))((("schema definition, types")))definition, which
@@ -101,7 +101,7 @@ underscore or contain commas.((("types", "names of")))  We will use `blog` for o
 
 ==== _id
 
-The _ID_ is a string that,((("id", "in document metadata"))) when combined with the `_index` and `_type`,
+The _ID_ is a string that,((("id", "_id, in document metadata"))) when combined with the `_index` and `_type`,
 uniquely identifies a document in Elasticsearch. When creating a new document,
 you can either provide your own `_id` or let Elasticsearch generate one for
 you.

030_Data/10_Index.asciidoc

@@ -1,7 +1,7 @@
 [[index-doc]]
 === Indexing a Document
 
-Documents are _indexed_—stored and made ((("documents", "indexing")))((("indexes", "indexing a document")))searchable--by using the `index`
+Documents are _indexed_—stored and made ((("documents", "indexing")))((("indexing", "a document")))searchable--by using the `index`
 API. But first, we need to decide where the document  lives.  As we just
 discussed, a document's `_index`, `_type`, and `_id` uniquely identify the
 document.  We can either provide our own `_id` value or let the `index` API
@@ -65,7 +65,7 @@ made by another part.
 ==== Autogenerating IDs
 
 If our data doesn't have a natural ID, we can let Elasticsearch autogenerate
-one for us.  ((("id", "autogenerating")))The structure of the request changes: instead of using ((("HTP methods", "POST")))the `PUT`
+one for us.  ((("id", "autogenerating")))The structure of the request changes: instead of using ((("HTTP methods", "POST")))((("POST method")))the `PUT`
 verb (``store this document at this URL''), we use the `POST` verb (``store this document _under_ this URL'').
 
 The URL now contains just the `_index` and the `_type`:

030_Data/15_Get.asciidoc

@@ -11,7 +11,7 @@ GET /website/blog/123?pretty
 
 // SENSE: 030_Data/15_Get_document.json
 
-The response includes the by-now-familiar metadata elements, plus ((("source field")))the `_source`
+The response includes the by-now-familiar metadata elements, plus ((("_source field", sortas="source field")))the `_source`
 field, which contains the original JSON document that we sent to Elasticsearch
 when we indexed it:
 
@@ -40,7 +40,7 @@ Instead we get back exactly the same JSON string that we passed in.
 ====
 
 The response to the +GET+ request includes `{"found": true}`. This confirms that
-the document was found.  ((("documents", "requesting non-existant document")))If we were to request a document that doesn't exist,
+the document was found.  ((("documents", "requesting non-existent document")))If we were to request a document that doesn't exist,
 we would still get a JSON response, but `found` would be set to `false`.
 
 Also, the HTTP response code would be `404 Not Found` instead of `200 OK`.

030_Data/20_Exists.asciidoc

@@ -1,8 +1,8 @@
 [[doc-exists]]
 === Checking Whether a Document Exists
 
-If all you want to do is to check whether a document exists--you're not
-interested in the content at all--then use the `HEAD` method instead
+If all you want to do is to check whether a ((("documents", "checking whether a document exists")))document exists--you're not
+interested in the content at all--then use((("HEAD method")))((("HTTP methods", "HEAD"))) the `HEAD` method instead
 of the `GET` method. `HEAD` requests don't return a body, just HTTP headers:
 
 [source,js]

030_Data/25_Update.asciidoc

@@ -2,7 +2,7 @@
 === Updating a Whole Document
 
 Documents in Elasticsearch are _immutable_; we cannot change them.((("documents", "updating whole document")))((("updating documents", "whole document"))) Instead, if
-we need to update an existing document, we _reindex_ or replace it, which we
+we need to update an existing document, we _reindex_ or replace it,((("reindexing")))((("indexing", seealso="reindexing"))) which we
 can do using the same `index` API that we have already discussed in
 <<index-doc>>.
 

030_Data/30_Create.asciidoc

@@ -7,7 +7,7 @@ new document and not overwriting an existing one?
 Remember that the combination of `_index`, `_type`, and `_id` uniquely
 identifies a document.  So the easiest way to ensure that our document is new
 is by letting Elasticsearch autogenerate a new unique `_id`, using the `POST`
-version of ((("HTTP methods", "POST")))the index request:
+version of ((("POST method")))((("HTTP methods", "POST")))the index request:
 
 [source,js]
 --------------------------------------------------
@@ -21,7 +21,7 @@ the same `_index`, `_type`, and `_id` doesn't exist already. There are two ways
 of doing this, both of which amount to the same thing. Use whichever method is
 more convenient for you.
 
-The first method uses the `op_type` query((("query strings", "op_type parameter")))((("op_type query string parameter")))-string parameter:
+The first method uses the `op_type` query((("PUT method")))((("HTTP methods", "PUT")))((("query strings", "op_type parameter")))((("op_type query string parameter")))-string parameter:
 
 [source,js]
 --------------------------------------------------

030_Data/35_Delete.asciidoc

@@ -2,7 +2,7 @@
 === Deleting a Document
 
 The syntax for deleting a document((("documents", "deleting"))) follows the same pattern that we have seen
-already, but ((("deleting documents")))((("HTTP methods", "DELETE")))uses the `DELETE` method :
+already, but ((("DELETE method", "deleting documents")))((("HTTP methods", "DELETE")))uses the `DELETE` method :
 
 [source,js]
 --------------------------------------------------

030_Data/55_Bulk.asciidoc

@@ -19,7 +19,7 @@ The `bulk` request body has the following, slightly unusual, format:
 --------------------------------------------------
 
 This format is like a _stream_ of valid one-line JSON documents joined
-together by newline (`\n`) characters.((("\n (newline) characters in buk requests", sortas="n (newline)"))) Two important points to note:
+together by newline (`\n`) characters.((("\n (newline) characters in bulk requests", sortas="n (newline)"))) Two important points to note:
 
 * Every line must end with a newline character (`\n`), _including the last
   line_. These are used as markers to allow for efficient line separation.
@@ -194,7 +194,7 @@ succeeded:
 <3> The error message explaining why the request failed.
 <4> The second request succeeded with an HTTP status code of `200 OK`.
 
-That also means ((("bulk API", "bulk requests, not atomic")))that `bulk` requests are not atomic: they cannot be used to
+That also means ((("bulk API", "bulk requests, not transactions")))that `bulk` requests are not atomic: they cannot be used to
 implement transactions.  Each request is processed separately, so the success
 or failure of one request will not interfere with the others.
 

040_Distributed_CRUD/05_Routing.asciidoc

@@ -1,7 +1,7 @@
 [[routing-value]]
 === Routing a Document to a Shard
 
-When you index a document, it is stored on a single primary shard.((("shards", "routing a document to")))((("routing a document to a shard"))) How does
+When you index a document, it is stored on a single primary shard.((("shards", "routing a document to")))((("documents", "routing a document to a shard")))((("routing a document to a shard"))) How does
 Elasticsearch know which shard a document belongs to?  When we create a new
 document, how does it know whether it should store that document on shard 1 or
 shard 2?