Facets: Removal from master.

Close #7337

docs/reference/getting-started.asciidoc

@@ -170,7 +170,7 @@ Now that we have our node (and cluster) up and running, the next step is to unde
 * Check your cluster, node, and index health, status, and statistics
 * Administer your cluster, node, and index data and metadata
 * Perform CRUD (Create, Read, Update, and Delete) and search operations against your indexes
-* Execute advanced search operations such as paging, sorting, filtering, scripting, faceting, aggregations, and many others
+* Execute advanced search operations such as paging, sorting, filtering, scripting, aggregations, and many others
 
 === Cluster Health
 

docs/reference/index-modules/fielddata.asciidoc

@@ -1,8 +1,8 @@
 [[index-modules-fielddata]]
 == Field data
 
-The field data cache is used mainly when sorting on or faceting on a
-field. It loads all the field values to memory in order to provide fast
+The field data cache is used mainly when sorting on or computing aggregations
+on a field. It loads all the field values to memory in order to provide fast
 document based access to those values. The field data cache can be
 expensive to build for a field, so its recommended to have enough memory
 to allocate it, and to keep it loaded.

docs/reference/mapping.asciidoc

@@ -29,8 +29,8 @@ Field names with the same name across types are highly recommended to
 have the same type and same mapping characteristics (analysis settings
 for example). There is an effort to allow to explicitly "choose" which
 field to use by using type prefix (`my_type.my_field`), but it's not
-complete, and there are places where it will never work (like faceting
-on the field).
+complete, and there are places where it will never work (like
+aggregations on the field).
 
 In practice though, this restriction is almost never an issue. The field
 name usually ends up being a good indication to its "typeness" (e.g.

docs/reference/mapping/fields/type-field.asciidoc

@@ -18,7 +18,7 @@ The `_type` field can be stored as well, for example:
 --------------------------------------------------
 
 The `_type` field can also not be indexed, and all the APIs will still
-work except for specific queries (term queries / filters) or faceting
+work except for specific queries (term queries / filters) or aggregations
 done on the `_type` field.
 
 [source,js]

docs/reference/mapping/types/core-types.asciidoc

@@ -477,7 +477,7 @@ default and can't be disabled).
 ==== Fielddata filters
 
 It is possible to control which field values are loaded into memory,
-which is particularly useful for faceting on string fields, using
+which is particularly useful for aggregations on string fields, using
 fielddata filters, which are explained in detail in the
 <<index-modules-fielddata,Fielddata>> section.
 

docs/reference/migration/migrate_1_0.asciidoc

@@ -193,7 +193,7 @@ Also, the top-level `filter` parameter in search has been renamed to
 <<search-request-post-filter,`post_filter`>>, to indicate that it should not
 be used as the primary way to filter search results (use a
 <<query-dsl-filtered-query,`filtered` query>> instead), but only to filter
-results AFTER facets/aggregations have been calculated.
+results AFTER aggregations have been calculated.
 
 This example counts the top colors in all matching docs, but only returns docs
 with color `red`:
@@ -373,4 +373,4 @@ Elasticsearch will *not* delete the `_percolator` index when upgrading, only the
 stored in the `_percolator` index. In order to use the already stored queries, you can just re-index the queries from the
 `_percolator` index into any index under the reserved `.percolator` type. The format in which the percolate queries
 were stored has *not* been changed. So a simple script that does a scan search to retrieve all the percolator queries
-and then does a bulk request into another index should be sufficient.
+and then does a bulk request into another index should be sufficient.

docs/reference/modules/scripting.asciidoc

@@ -304,7 +304,7 @@ There are a few limitations relative to other script languages:
 [float]
 === Score
 
-In all scripts that can be used in facets, the current
+In all scripts that can be used in aggregations, the current
 document's score is accessible in `doc.score`.  When using a `script_score`,
 the current score is available in `_score`.
 

docs/reference/query-dsl.asciidoc

@@ -27,8 +27,8 @@ complex (and interesting) queries.
 
 Both queries and filters can be used in different APIs. For example,
 within a <<search-request-query,search query>>, or
-as a <<search-facets,facet filter>>. This
-section explains the components (queries and filters) that can form the
+as an <<search-aggregations-bucket-filter-aggregation,aggregation filter>>.
+This section explains the components (queries and filters) that can form the
 AST one can use.
 
 Filters are very handy since they perform an order of magnitude better

docs/reference/query-dsl/filters/range-filter.asciidoc

@@ -71,7 +71,7 @@ In general for small ranges the `index` execution is faster and for longer range
 
 The `fielddata` execution as the same suggests uses field data and therefor requires more memory, so make you have
 sufficient memory on your nodes in order to use this execution mode. It usually makes sense to use it on fields  you're
-already faceting or sorting by.
+already aggregating or sorting by.
 
 [float]
 ==== Caching

docs/reference/query-dsl/filters/terms-filter.asciidoc

@@ -39,7 +39,7 @@ The `execution` option now has the following options :
     Generates a terms filters that uses the fielddata cache to
     compare terms.  This execution mode is great to use when filtering
     on a field that is already loaded into the fielddata cache from 
-    faceting, sorting, or index warmers.  When filtering on
+    aggregating, sorting, or index warmers.  When filtering on
     a large number of terms, this execution can be considerably faster
     than the other modes.  The total filter is not cached unless
     explicitly configured to do so.

docs/reference/query-dsl/queries/top-children-query.asciidoc

@@ -45,7 +45,7 @@ including the default values:
 [float]
 ==== Scope
 
-A `_scope` can be defined on the query allowing to run facets on the
+A `_scope` can be defined on the query allowing to run aggregations on the
 same scope name that will work against the child documents. For example:
 
 [source,js]

docs/reference/search/aggregations.asciidoc

@@ -1,18 +1,8 @@
 [[search-aggregations]]
 == Aggregations
 
-Aggregations grew out of the <<search-facets, facets>> module and the long experience of how users use it
-(and would like to use it) for real-time data analytics purposes. As such, it serves as the next generation
-replacement for the functionality we currently refer to as "faceting".
-
-<<search-facets, Facets>> provide a great way to aggregate data within a document set context.
-This context is defined by the executed query in combination with the different levels of filters that can be defined
-(filtered queries, top-level filters, and facet level filters). While powerful, their implementation is not designed
-from the ground up to support complex aggregations and is thus limited.
-
-The aggregations module breaks the barriers the current facet implementation put in place. The new name ("Aggregations")
-also indicates the intention here - a generic yet extremely powerful framework for building aggregations - any types of
-aggregations.
+The aggregations framework helps provide aggregated data based on a search query. It is based on simple building blocks
+called aggregations, that can be composed in order to build complex summaries of the data.
 
 An aggregation can be seen as a _unit-of-work_ that builds analytic information over a set of documents. The context of
 the execution defines what this document set is (e.g. a top-level aggregation executes within the context of the executed