From dbd159c854f30bfa69e3ed4483e8155c8ab3d27f Mon Sep 17 00:00:00 2001 From: debadair Date: Wed, 6 Jan 2016 19:05:22 -0800 Subject: [PATCH] Fixed build errors. --- 060_Distributed_Search/10_Fetch_phase.asciidoc | 2 +- 070_Index_Mgmt/50_Reindexing.asciidoc | 2 +- 300_Aggregations/20_basic_example.asciidoc | 8 ++++---- 400_Relationships/25_Concurrency.asciidoc | 4 ++-- 400_Relationships/26_Concurrency_solutions.asciidoc | 2 +- 410_Scaling/45_Index_per_timeframe.asciidoc | 2 +- 410_Scaling/75_One_big_user.asciidoc | 2 +- 510_Deployment/40_config.asciidoc | 1 + 8 files changed, 12 insertions(+), 11 deletions(-) diff --git a/060_Distributed_Search/10_Fetch_phase.asciidoc b/060_Distributed_Search/10_Fetch_phase.asciidoc index dd5c4ffc3..27b0c6145 100644 --- a/060_Distributed_Search/10_Fetch_phase.asciidoc +++ b/060_Distributed_Search/10_Fetch_phase.asciidoc @@ -58,6 +58,6 @@ after page until your servers crumble at the knees. If you _do_ need to fetch large numbers of docs from your cluster, you can do so efficiently by disabling sorting with the `scroll` query, -which we discuss <>. +which we discuss <>. **** diff --git a/070_Index_Mgmt/50_Reindexing.asciidoc b/070_Index_Mgmt/50_Reindexing.asciidoc index ed5322379..59b5ca0e7 100644 --- a/070_Index_Mgmt/50_Reindexing.asciidoc +++ b/070_Index_Mgmt/50_Reindexing.asciidoc @@ -15,7 +15,7 @@ whole document available to you in Elasticsearch itself. You don't have to rebuild your index from the database, which is usually much slower. To reindex all of the documents from the old index efficiently, use -<> to retrieve batches((("using in reindexing documents"))) of documents from the old index, +<> to retrieve batches((("using in reindexing documents"))) of documents from the old index, and the <> to push them into the new index. .Reindexing in Batches diff --git a/300_Aggregations/20_basic_example.asciidoc b/300_Aggregations/20_basic_example.asciidoc index b51b5354c..af0627226 100644 --- a/300_Aggregations/20_basic_example.asciidoc +++ b/300_Aggregations/20_basic_example.asciidoc @@ -49,9 +49,9 @@ using a simple aggregation. We will do this using a `terms` bucket: GET /cars/transactions/_search { "size" : 0, - "aggs" : { - "popular_colors" : { - "terms" : { + "aggs" : { <1> + "popular_colors" : { <2> + "terms" : { <3> "field" : "color" } } @@ -62,7 +62,7 @@ GET /cars/transactions/_search <1> Aggregations are placed under the ((("aggregations", "aggs parameter")))top-level `aggs` parameter (the longer `aggregations` will also work if you prefer that). -<2> We then name the aggregation whatever we want: `colors`, in this example +<2> We then name the aggregation whatever we want: `popular_colors`, in this example <3> Finally, we define a single bucket of type `terms`. Aggregations are executed in the context of search results,((("searching", "aggregations executed in context of search results"))) which means it is diff --git a/400_Relationships/25_Concurrency.asciidoc b/400_Relationships/25_Concurrency.asciidoc index 7595b3213..2bb5b6155 100644 --- a/400_Relationships/25_Concurrency.asciidoc +++ b/400_Relationships/25_Concurrency.asciidoc @@ -11,7 +11,7 @@ The more important issue is that, if the user were to change his name, all of his blog posts would need to be updated too. Fortunately, users don't often change names. Even if they did, it is unlikely that a user would have written more than a few thousand blog posts, so updating blog posts with -the <> and <> APIs would take less than a +the <> and <> APIs would take less than a second. However, let's consider a more complex scenario in which changes are common, far @@ -182,7 +182,7 @@ PUT /fs/file/1?version=2 <1> We can even rename a directory, but this means updating all of the files that exist anywhere in the path hierarchy beneath that directory. This may be quick or slow, depending on how many files need to be updated. All we would -need to do is to use <> to retrieve all the +need to do is to use <> to retrieve all the files, and the <> to update them. The process isn't atomic, but all files will quickly move to their new home. diff --git a/400_Relationships/26_Concurrency_solutions.asciidoc b/400_Relationships/26_Concurrency_solutions.asciidoc index 10bd1d5e3..18a271dea 100644 --- a/400_Relationships/26_Concurrency_solutions.asciidoc +++ b/400_Relationships/26_Concurrency_solutions.asciidoc @@ -166,7 +166,7 @@ PUT /fs/lock/_bulk -------------------------- <1> The `refresh` call ensures that all `lock` documents are visible to the search request. -<2> You can use a <> query when you need to retrieve large +<2> You can use a <> query when you need to retrieve large numbers of results with a single search request. Document-level locking enables fine-grained access control, but creating lock diff --git a/410_Scaling/45_Index_per_timeframe.asciidoc b/410_Scaling/45_Index_per_timeframe.asciidoc index 75f1c297a..709acf4a7 100644 --- a/410_Scaling/45_Index_per_timeframe.asciidoc +++ b/410_Scaling/45_Index_per_timeframe.asciidoc @@ -29,7 +29,7 @@ data. If we were to have one big index for documents of this type, we would soon run out of space. Logging events just keep on coming, without pause or -interruption. We could delete the old events with a <> +interruption. We could delete the old events with a <> query and bulk delete, but this approach is _very inefficient_. When you delete a document, it is only _marked_ as deleted (see <>). It won't be physically deleted until the segment containing it is merged away. diff --git a/410_Scaling/75_One_big_user.asciidoc b/410_Scaling/75_One_big_user.asciidoc index 754400376..edfb84347 100644 --- a/410_Scaling/75_One_big_user.asciidoc +++ b/410_Scaling/75_One_big_user.asciidoc @@ -23,7 +23,7 @@ PUT /baking_v1 ------------------------------ The next step is to migrate the data from the shared index into the dedicated -index, which can be done using a <> query and the +index, which can be done using a <> query and the <>. As soon as the migration is finished, the index alias can be updated to point to the new index: diff --git a/510_Deployment/40_config.asciidoc b/510_Deployment/40_config.asciidoc index f142db6da..a5aa57261 100644 --- a/510_Deployment/40_config.asciidoc +++ b/510_Deployment/40_config.asciidoc @@ -1,3 +1,4 @@ +[[important-configuration-changes]] === Important Configuration Changes Elasticsearch ships with _very good_ defaults,((("deployment", "configuration changes, important")))((("configuration changes, important"))) especially when it comes to performance- related settings and options. When in doubt, just leave