[DOCS] Refactor glossary (#70516)

docs/reference/glossary.asciidoc

@@ -1,670 +1,533 @@
+////
+============
+IMPORTANT
+Add new terms to the Stack Docs glossary:
+https://github.com/elastic/stack-docs/tree/master/docs/en/glossary
+============
+////
+
 [glossary]
 [[glossary]]
 = Glossary of terms
 
 [glossary]
-[[glossary-analysis]] analysis ::
-+
---
+[[glossary-analysis]] analysis::
 // tag::analysis-def[]
-Analysis is the process of converting <<glossary-text,full text>> to
-<<glossary-term,terms>>. Depending on which analyzer is used, these phrases:
-`FOO BAR`, `Foo-Bar`, `foo,bar` will probably all result in the
-terms `foo` and `bar`. These terms are what is actually stored in
-the index.
-
-A full text query (not a <<glossary-term,term>> query) for `FoO:bAR` will
-also be analyzed to the terms `foo`,`bar` and will thus match the
-terms stored in the index.
-
-It is this process of analysis (both at index time and at search time)
-that allows Elasticsearch to perform full text queries.
-
-Also see <<glossary-text,text>> and <<glossary-term,term>>.
+Process of converting unstructured <<glossary-text,text>> into a format
+optimized for search. See {ref}/analysis.html[Text analysis].
 // end::analysis-def[]
---
 
-[[glossary-api-key]] API key ::
+[[glossary-api-key]] API key::
 // tag::api-key-def[]
-A unique identifier that you can use for authentication when submitting {es} requests.
-When TLS is enabled, all requests must be authenticated using either basic authentication
-(user name and password) or an API key.
+Unique identifier for authentication in {es}. When
+{ref}/encrypting-communications.html[transport layer security (TLS)] is enabled,
+all requests must be authenticated using an API key or a username and password.
+See the {ref}/security-api-create-api-key.html[Create API key API].
 // end::api-key-def[]
 
-
-[[glossary-auto-follow-pattern]] auto-follow pattern ::
+[[glossary-auto-follow-pattern]] auto-follow pattern::
 // tag::auto-follow-pattern-def[]
-An <<glossary-index-pattern,index pattern>> that automatically configures new indices as
-<<glossary-follower-index,follower indices>> for <<glossary-ccr,{ccr}>>.
-For more information, see {ref}/ccr-auto-follow.html[Managing auto follow patterns].
+<<glossary-index-pattern,Index pattern>> that automatically configures new
+<<glossary-index,indices>> as <<glossary-follower-index,follower indices>> for
+<<glossary-ccr,{ccr}>>. See {ref}/ccr-auto-follow.html[Manage auto-follow
+patterns].
 // end::auto-follow-pattern-def[]
 
-[[glossary-cluster]] cluster ::
+[[glossary-cluster]] cluster::
 // tag::cluster-def[]
-One or more <<glossary-node,nodes>> that share the
-same cluster name. Each cluster has a single master node, which is
-chosen automatically by the cluster and can be replaced if it fails.
+A group of one or more connected {es} <<glossary-node,nodes>>. See
+{ref}/scalability.html[Clusters, nodes, and shards].
 // end::cluster-def[]
 
-[[glossary-cold-phase]] cold phase ::
+[[glossary-cold-phase]] cold phase::
 // tag::cold-phase-def[]
-The third possible phase in the <<glossary-index-lifecycle,index lifecycle>>.
-In the cold phase, an index is no longer updated and seldom queried.
-The information still needs to be searchable, but it’s okay if those queries are slower.
+Third possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In the
+cold phase, data is no longer updated and seldom <<glossary-query,queried>>. The
+data still needs to be searchable, but it’s okay if those queries are slower.
+See {ref}/ilm-index-lifecycle.html[Index lifecycle].
 // end::cold-phase-def[]
 
 [[glossary-cold-tier]] cold tier::
 // tag::cold-tier-def[]
-A <<glossary-data-tier, data tier>> that contains nodes that hold time series data
-that is accessed occasionally and not normally updated.
+<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that hold
+time series data that is accessed occasionally and not normally updated. See
+{ref}/data-tiers.html[Data tiers].
 // end::cold-tier-def[]
 
-[[glossary-component-template]] component template ::
+[[glossary-component-template]] component template::
 // tag::component-template-def[]
-A building block for constructing <<index-templates,index templates>> that specifies index
-<<mapping,mappings>>, <<index-modules-settings,settings>>, and <<indices-aliases,aliases>>.
+Building block for creating <<glossary-index-template,index templates>>. A
+component template can specify <<glossary-mapping,mappings>>,
+{ref}/index-modules.html[index settings], and <<glossary-index-alias,index
+aliases>>. See {ref}/index-templates.html[index templates].
 // end::component-template-def[]
 
 [[glossary-content-tier]] content tier::
 // tag::content-tier-def[]
-A <<glossary-data-tier, data tier>> that contains nodes that handle the indexing and query load for
-content such as a product catalog.
+<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
+handle the <<glossary-index,indexing>> and <<glossary-query,query>> load for
+content, such as a product catalog. See {ref}/data-tiers.html[Data tiers].
 // end::content-tier-def[]
 
-[[glossary-ccr]] {ccr} (CCR)::
+[[glossary-ccr]] {ccr} ({ccr-init})::
 // tag::ccr-def[]
-A feature that enables you to replicate indices in remote clusters to your
-local cluster. For more information, see
-{ref}/xpack-ccr.html[{ccr-cap}].
+Replicates <<glossary-data-stream,data streams>> and <<glossary-index,indices>>
+from <<glossary-remote-cluster,remote clusters>> in a
+<<glossary-local-cluster,local cluster>>. See {ref}/xpack-ccr.html[{ccr-cap}].
 // end::ccr-def[]
 
 [[glossary-ccs]] {ccs} (CCS)::
 // tag::ccs-def[]
-A feature that enables any node to act as a federated client across
-multiple clusters.
-See {ref}/modules-cross-cluster-search.html[Search across clusters].
+Searches <<glossary-data-stream,data streams>> and <<glossary-index,indices>> on
+<<glossary-remote-cluster,remote clusters>> from a
+<<glossary-local-cluster,local cluster>>. See
+{ref}/modules-cross-cluster-search.html[Search across clusters].
 // end::ccs-def[]
 
-[[glossary-data-stream]] data stream ::
-+
---
+[[glossary-data-stream]] data stream::
 // tag::data-stream-def[]
-A named resource used to ingest, search, and manage time series data in {es}. A
-data stream's data is stored across multiple hidden, auto-generated
-<<glossary-index,indices>>. You can automate management of these indices to more
-efficiently store large data volumes.
-
-See {ref}/data-streams.html[Data streams].
+Named resource used to manage time series data. A data stream stores data across
+multiple backing <<glossary-index,indices>>. See {ref}/data-streams.html[Data
+streams].
 // end::data-stream-def[]
---
 
 [[glossary-data-tier]] data tier::
 // tag::data-tier-def[]
-A collection of nodes with the same data role that typically share the same hardware profile.
-See <<glossary-content-tier, content tier>>, <<glossary-hot-tier, hot tier>>, <<glossary-warm-tier, warm tier>>,
-<<glossary-cold-tier, cold tier>>.
+Collection of <<glossary-node,nodes>> with the same {ref}/modules-node.html[data
+role] that typically share the same hardware profile. Data tiers include the
+<<glossary-content-tier, content tier>>, <<glossary-hot-tier, hot tier>>,
+<<glossary-warm-tier, warm tier>>, <<glossary-cold-tier, cold tier>>, and
+{ref}/glossary.html#glossary-frozen-tier[frozen tier]. See
+{ref}/data-tiers.html[Data tiers].
 // end::data-tier-def[]
 
-[[glossary-delete-phase]] delete phase ::
+[[glossary-delete-phase]] delete phase::
 // tag::delete-phase-def[]
-The last possible phase in the <<glossary-index-lifecycle,index lifecycle>>.
-In the delete phase, an index is no longer needed and can safely be deleted.
+Last possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In the
+delete phase, an <<glossary-index,index>> is no longer needed and can safely be
+deleted. See {ref}/ilm-index-lifecycle.html[Index lifecycle].
 // end::delete-phase-def[]
 
-[[glossary-document]] document ::
-+
---
+[[glossary-document]] document::
 // tag::document-def[]
-A document is a JSON document which is stored in Elasticsearch. It is
-like a row in a table in a relational database. Each document is
-stored in an <<glossary-index,index>> and has a type
-and an <<glossary-id,id>>.
-
-A document is a JSON object (also known in other languages as a hash /
-hashmap / associative array) which contains zero or more
-<<glossary-field,fields>>, or key-value pairs.
-
-The original JSON document that is indexed will be stored in the
-<<glossary-source_field,`_source` field>>, which is returned by default when
-getting or searching for a document.
+JSON object containing data stored in {es}. See
+{ref}/documents-indices.html[Documents and indices].
 // end::document-def[]
---
 
 [[glossary-eql]]
-Event Query Language (EQL) ::
+Event Query Language (EQL)::
 // tag::eql-def[]
-A query language for event-based time series data, such as logs, metrics, and
-traces. EQL supports matching for event sequences. In the {security-app}, you
-use EQL to write event correlation rules. See {ref}/eql.html[EQL].
+<<glossary-query,Query>> language for event-based time series data, such as
+logs, metrics, and traces. EQL supports matching for event sequences. See
+{ref}/eql.html[EQL].
 // end::eql-def[]
 
-[[glossary-field]] field ::
-+
---
+[[glossary-field]] field::
 // tag::field-def[]
-A <<glossary-document,document>> contains a list of fields, or key-value
-pairs. The value can be a simple (scalar) value (eg a string, integer,
-date), or a nested structure like an array or an object. A field is
-similar to a column in a table in a relational database.
-
-The <<glossary-mapping,mapping>> for each field has a field _type_ (not to
-be confused with document type) which indicates the type
-of data that can be stored in that field, eg `integer`, `string`,
-`object`. The mapping also allows you to define (amongst other things)
-how the value for a field should be analyzed.
+Key-value pair in a <<glossary-document,document>>. See
+{ref}/mapping.html[Mapping].
 // end::field-def[]
---
 
-[[glossary-filter]] filter ::
+[[glossary-filter]] filter::
 // tag::filter-def[]
-A filter is a non-scoring <<glossary-query,query>>,
-meaning that it does not score documents.
-It is only concerned about answering the question - "Does this document match?".
-The answer is always a simple, binary yes or no. This kind of query is said to be made
-in a {ref}/query-filter-context.html[filter context],
-hence it is called a filter. Filters are simple checks for set inclusion or exclusion.
-In most cases, the goal of filtering is to reduce the number of documents that have to be examined.
+<<glossary-query,Query>> that does not score matching documents. See
+{ref}/query-filter-context.html[filter context].
 // end::filter-def[]
 
-[[glossary-flush]] flush ::
+[[glossary-flush]] flush::
 // tag::flush-def[]
-Peform a Lucene commit to write index updates in the transaction log (translog) to disk.
-Because a Lucene commit is a relatively expensive operation,
-{es} records index and delete operations in the translog and
-automatically flushes changes to disk in batches.
-To recover from a crash, operations that have been acknowledged but not yet committed
-can be replayed from the translog.
-Before upgrading, you can explicitly call the {ref}/indices-flush.html[Flush] API
-to ensure that all changes are committed to disk.
+Writes data from the {ref}/index-modules-translog.html[transaction log] to disk
+for permanent storage. See the {ref}/indices-flush.html[flush API].
 // end::flush-def[]
 
-[[glossary-follower-index]] follower index ::
+[[glossary-follower-index]] follower index::
 // tag::follower-index-def[]
-The target index for <<glossary-ccr,{ccr}>>. A follower index exists
-in a local cluster and replicates a <<glossary-leader-index,leader index>>.
+Target <<glossary-index,index>> for <<glossary-ccr,{ccr}>>. A follower index
+exists in a <<glossary-local-cluster,local cluster>> and replicates a
+<<glossary-leader-index,leader index>>. See {ref}/xpack-ccr.html[{ccr-cap}].
 // end::follower-index-def[]
 
-[[glossary-force-merge]] force merge ::
+[[glossary-force-merge]] force merge::
 // tag::force-merge-def[]
 // tag::force-merge-def-short[]
-Manually trigger a merge to reduce the number of segments in each shard of an index
-and free up the space used by deleted documents.
+Manually triggers a <<glossary-merge,merge>> to reduce the number of
+<<glossary-segment,segments>> in an index's <<glossary-shard,shards>>.
 // end::force-merge-def-short[]
-You should not force merge indices that are actively being written to.
-Merging is normally performed automatically, but you can use force merge after
-<<glossary-rollover,rollover>> to reduce the shards in the old index to a single segment.
 See the {ref}/indices-forcemerge.html[force merge API].
 // end::force-merge-def[]
 
-[[glossary-freeze]] freeze ::
+[[glossary-freeze]] freeze::
 // tag::freeze-def[]
 // tag::freeze-def-short[]
-Make an index read-only and minimize its memory footprint.
+Makes an index read-only and minimizes its memory footprint.
 // end::freeze-def-short[]
-Frozen indices can be searched without incurring the overhead of re-opening a closed index,
-but searches are throttled and might be slower.
-You can freeze indices to reduce the overhead of keeping older indices searchable
-before you are ready to archive or delete them.
 See the {ref}/freeze-index-api.html[freeze API].
 // end::freeze-def[]
 
-[[glossary-frozen-index]] frozen index ::
+[[glossary-frozen-index]] frozen index::
 // tag::frozen-index-def[]
-An index reduced to a low overhead state that still enables occasional searches.
-Frozen indices use a memory-efficient shard implementation and throttle searches to conserve resources.
-Searching a frozen index is lower overhead than re-opening a closed index to enable searching.
+An <<glossary-index,index>> reduced to a low overhead state that still enables
+occasional searches.
+See the {ref}/freeze-index-api.html[freeze API].
 // end::frozen-index-def[]
 
-[[glossary-frozen-phase]] frozen phase ::
+[[glossary-frozen-phase]] frozen phase::
 // tag::frozen-phase-def[]
-The fourth possible phase in the <<glossary-index-lifecycle,index lifecycle>>.
-In the frozen phase, an index is no longer updated and queried rarely.
-The information still needs to be searchable, but it’s okay if those queries are extremely slow.
+Fourth possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
+the frozen phase, an <<glossary-index,index>> is no longer updated and
+<<glossary-query,queried>> rarely. The information still needs to be searchable,
+but it’s okay if those queries are extremely slow. See
+{ref}/ilm-index-lifecycle.html[Index lifecycle].
 // end::frozen-phase-def[]
 
 [[glossary-frozen-tier]] frozen tier::
 // tag::frozen-tier-def[]
-A <<glossary-data-tier, data tier>> that contains nodes that hold time series data
-that is accessed rarely and not normally updated.
+<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
+hold time series data that is accessed rarely and not normally updated. See
+{ref}/data-tiers.html[Data tiers].
 // end::frozen-tier-def[]
 
-[[glossary-hidden-index]] hidden index ::
+[[glossary-hidden-index]] hidden data stream or index::
 // tag::hidden-index-def[]
-An index that is excluded by default when you access indices using a wildcard expression.
-You can specify the `expand_wildcards` parameter to include hidden indices.
-Note that hidden indices _are_ included if the wildcard expression starts with a dot, for example `.watcher-history*`.
+<<glossary-data-stream,Data stream>> or <<glossary-index,index>> excluded from
+most <<glossary-index-pattern,index patterns>> by default. See
+{ref}/multi-index.html#hidden-indices[Hidden data streams and indices].
 // end::hidden-index-def[]
 
-[[glossary-hot-phase]] hot phase ::
+[[glossary-hot-phase]] hot phase::
 // tag::hot-phase-def[]
-The first possible phase in the <<glossary-index-lifecycle,index lifecycle>>.
-In the hot phase, an index is actively updated and queried.
+First possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
+the hot phase, an <<glossary-index,index>> is actively updated and queried. See
+{ref}/ilm-index-lifecycle.html[Index lifecycle].
 // end::hot-phase-def[]
 
 [[glossary-hot-tier]] hot tier::
 // tag::hot-tier-def[]
-A <<glossary-data-tier, data tier>> that contains nodes that handle the indexing load
-for time series data such as logs or metrics and hold your most recent,
-most-frequently-accessed data.
+<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that
+handle the <<glossary-index,indexing>> load for time series data, such as logs or
+metrics. This tier holds your most recent, most frequently accessed data. See
+{ref}/data-tiers.html[Data tiers].
 // end::hot-tier-def[]
 
-[[glossary-id]] id ::
+[[glossary-id]] ID::
 // tag::id-def[]
-The ID of a <<glossary-document,document>> identifies a document. The
-`index/id` of a document must be unique. If no ID is provided,
-then it will be auto-generated. (also see <<glossary-routing,routing>>)
+Identifier for a <<glossary-document,document>>. Document IDs must be unique
+within an <<glossary-index,index>>. See the {ref}/mapping-id-field.html[`_id`
+field].
 // end::id-def[]
 
-[[glossary-index]] index ::
-+
---
+[[glossary-index]] index::
 // tag::index-def[]
-// tag::index-def-short[]
-An optimized collection of JSON documents. Each document is a collection of fields,
-the key-value pairs that contain your data.
-// end::index-def-short[]
-
-An index is a logical namespace that maps to one or more
-<<glossary-primary-shard,primary shards>> and can have zero or more
-<<glossary-replica-shard,replica shards>>.
+. Collection of JSON <<glossary-document,documents>>. See
+{ref}/documents-indices.html[Documents and indices].
+
+. To add one or more JSON documents to {es}. This process is called indexing.
 // end::index-def[]
---
 
-[[glossary-index-alias]] index alias ::
-+
---
+[[glossary-index-alias]] index alias::
 // tag::index-alias-def[]
-// tag::index-alias-desc[]
-An index alias is a logical name used to reference one or more indices.
-
-Most {es} APIs accept an index alias in place of an index name.
-// end::index-alias-desc[]
-
-See {ref}/indices-add-alias.html[Create or update index alias API].
+Secondary name for one or more <<glossary-index,indices>>. Most {es} APIs accept
+an index alias in place of an index name. See the
+{ref}/indices-add-alias.html[Create or update index alias API].
 // end::index-alias-def[]
---
 
-[[glossary-index-lifecycle]] index lifecycle ::
+[[glossary-index-lifecycle]] index lifecycle::
 // tag::index-lifecycle-def[]
-The four phases an index can transition through:
+Five phases an <<glossary-index,index>> can transition through:
 <<glossary-hot-phase,hot>>, <<glossary-warm-phase,warm>>,
-<<glossary-cold-phase,cold>>, and <<glossary-delete-phase,delete>>.
-For more information, see {ref}/ilm-policy-definition.html[Index lifecycle].
+<<glossary-cold-phase,cold>>, {ref}/glossary.html#glossary-frozen-phase[frozen],
+and <<glossary-delete-phase,delete>>. See {ref}/ilm-policy-definition.html[Index
+lifecycle].
 // end::index-lifecycle-def[]
 
-[[glossary-index-lifecycle-policy]] index lifecycle policy ::
+[[glossary-index-lifecycle-policy]] index lifecycle policy::
 // tag::index-lifecycle-policy-def[]
-Specifies how an index moves between phases in the index lifecycle and
-what actions to perform during each phase.
+Specifies how an <<glossary-index,index>> moves between phases in the
+<<glossary-index-lifecycle,index lifecycle>> and what actions to perform during
+each phase. See {ref}/ilm-policy-definition.html[Index lifecycle].
 // end::index-lifecycle-policy-def[]
 
-[[glossary-index-pattern]] index pattern ::
+[[glossary-index-pattern]] index pattern::
 // tag::index-pattern-def[]
-A string that can contain the `*` wildcard to match multiple index names.
-In most cases, the index parameter in an {es} request can be the name of a specific index,
-a list of index names, or an index pattern.
-For example, if you have the indices `datastream-000001`, `datastream-000002`, and `datastream-000003`,
-to search across all three you could use the `datastream-*` index pattern.
+String containing a wildcard (`*`) pattern that can match multiple
+<<glossary-data-stream,data streams>>, <<glossary-index,indices>>, or
+<<glossary-index-alias,index aliases>>. See {ref}/multi-index.html[Multi-target
+syntax].
 // end::index-pattern-def[]
 
-[[glossary-index-template]] index template ::
-+
---
+[[glossary-index-template]] index template::
 // tag::index-template-def[]
-// tag::index-template-def-short[]
-Defines settings and mappings to apply to new indexes that match a simple naming pattern, such as _logs-*_.
-// end::index-template-def-short[]
-
-An index template can also attach a lifecycle policy to the new index.
-Index templates are used to automatically configure indices created during <<glossary-rollover,rollover>>.
+Automatically configures the <<glossary-mapping,mappings>>,
+{ref}/index-modules.html[index settings], and <<glossary-index-alias,aliases>>
+of new <<glossary-index,indices>> that match its <<glossary-index-pattern,index
+pattern>>. You can also use index templates to create
+<<glossary-data-stream,data streams>>. See {ref}/index-templates.html[Index
+templates].
 // end::index-template-def[]
---
 
-[[glossary-leader-index]] leader index ::
+[[glossary-leader-index]] leader index::
 // tag::leader-index-def[]
-The source index for <<glossary-ccr,{ccr}>>. A leader index exists
-on a remote cluster and is replicated to
-<<glossary-follower-index,follower indices>>.
+Source <<glossary-index,index>> for <<glossary-ccr,{ccr}>>. A leader index
+exists on a <<glossary-remote-cluster,remote cluster>> and is replicated to
+<<glossary-follower-index,follower indices>>. See
+{ref}/xpack-ccr.html[{ccr-cap}].
 // end::leader-index-def[]
 
-[[glossary-local-cluster]] local cluster ::
+[[glossary-local-cluster]] local cluster::
 // tag::local-cluster-def[]
-The cluster that pulls data from a <<glossary-remote-cluster,remote cluster>> in {ccs} or {ccr}.
+<<glossary-cluster,Cluster>> that pulls data from a
+<<glossary-remote-cluster,remote cluster>> in <<glossary-ccs,{ccs}>> or
+<<glossary-ccr,{ccr}>>. See {ref}/modules-remote-clusters.html[Remote clusters].
 // end::local-cluster-def[]
 
-[[glossary-mapping]] mapping ::
-+
---
+[[glossary-mapping]] mapping::
 // tag::mapping-def[]
-A mapping is like a _schema definition_ in a relational database. Each
-<<glossary-index,index>> has a mapping,
-which defines a type,
-plus a number of index-wide settings.
-
-A mapping can either be defined explicitly, or it will be generated
-automatically when a document is indexed.
+Defines how a <<glossary-document,document>>, its <<glossary-field,fields>>, and
+its metadata are stored in {es}. Similar to a schema definition. See
+{ref}/mapping.html[Mapping].
 // end::mapping-def[]
---
 
-[[glossary-node]] node ::
+[[glossary-merge]] merge::
+// tag::merge-def[]
+Process of combining a <<glossary-shard,shard>>'s smaller Lucene
+<<glossary-segment,segments>> into a larger one. {es} manages merges
+automatically.
+// end::merge-def[]
+
+[[glossary-node]] node::
 // tag::node-def[]
-A running instance of {es} that belongs to a
-<<glossary-cluster,cluster>>. Multiple nodes can be started on a single
-server for testing purposes, but usually you should have one node per
-server.
+A single {es} server. One or more nodes can form a <<glossary-cluster,cluster>>.
+See {ref}/scalability.html[Clusters, nodes, and shards].
 // end::node-def[]
 
-[[glossary-primary-shard]] primary shard ::
-+
---
+[[glossary-primary-shard]] primary shard::
 // tag::primary-shard-def[]
-Each document is stored in a single primary <<glossary-shard,shard>>. When
-you index a document, it is indexed first on the primary shard, then
-on all <<glossary-replica-shard,replicas>> of the primary shard.
-
-By default, an <<glossary-index,index>> has one primary shard. You can specify
-more primary shards to scale the number of <<glossary-document,documents>>
-that your index can handle.
-
-You cannot change the number of primary shards in an index, once the index is
-created. However, an index can be split into a new index using the
-{ref}/indices-split-index.html[split index API].
-
-See also <<glossary-routing,routing>>.
+Lucene instance containing some or all data for an <<glossary-index,index>>.
+When you index a <<glossary-document,document>>, {es} adds the document to
+primary shards before <<glossary-replica-shard,replica shards>>. See
+{ref}/scalability.html[Clusters, nodes, and shards].
 // end::primary-shard-def[]
---
 
-[[glossary-query]] query ::
-+
---
+[[glossary-query]] query::
 // tag::query-def[]
-A request for information from {es}. You can think of a query as a question,
-written in a way {es} understands. A search consists of one or more queries
-combined.
-
-There are two types of queries: _scoring queries_ and _filters_. For more
-information about query types,
-see {ref}/query-filter-context.html[Query and filter context].
+Request for information about your data. You can think of a query as a
+question, written in a way {es} understands. See
+{ref}/search-your-data.html[Search your data].
 // end::query-def[]
---
 
-[[glossary-recovery]] recovery ::
-+
---
+[[glossary-recovery]] recovery::
 // tag::recovery-def[]
-Shard recovery is the process
-of syncing a <<glossary-replica-shard,replica shard>>
-from a <<glossary-primary-shard,primary shard>>.
-Upon completion,
-the replica shard is available for search.
-
-// tag::recovery-triggers[]
-Recovery automatically occurs
-during the following processes:
-
-* Node startup or failure.
-  This type of recovery is called a *local store recovery*.
-* <<glossary-replica-shard,Primary shard replication>>.
-* Relocation of a shard to a different node in the same cluster.
-* {ref}/snapshots-restore-snapshot.html[Snapshot restoration].
-// end::recovery-triggers[]
+Process of syncing a <<glossary-replica-shard,replica shard>> from a
+<<glossary-primary-shard,primary shard>>. Upon completion, the replica shard is
+available for searches. See the {ref}/indices-recovery.html[index recovery API].
 // end::recovery-def[]
---
 
-[[glossary-reindex]] reindex ::
-+
---
+[[glossary-reindex]] reindex::
 // tag::reindex-def[]
-Copies documents from a _source_ to a _destination_. The source and
-destination can be any pre-existing index, index alias, or
-{ref}/data-streams.html[data stream].
-
-You can reindex all documents from a source or select a subset of documents to
-copy. You can also reindex to a destination in a remote cluster.
-
-A reindex is often performed to update mappings, change static index settings,
-or upgrade {es} between incompatible versions.
+Copies documents from a source to a destination. The source and destination can
+be a <<glossary-data-stream,data stream>>, <<glossary-index,index>>, or
+<<glossary-index-alias,index alias>>. See the {ref}/docs-reindex.html[Reindex
+API].
 // end::reindex-def[]
---
-
-[[glossary-remote-cluster]] remote cluster ::
 
+[[glossary-remote-cluster]] remote cluster::
 // tag::remote-cluster-def[]
-A separate cluster, often in a different data center or locale, that contains indices that
-can be replicated or searched by the <<glossary-local-cluster,local cluster>>.
-The connection to a remote cluster is unidirectional.
+A separate <<glossary-cluster,cluster>>, often in a different data center or
+locale, that contains <<glossary-index,indices>> that can be replicated or
+searched by the <<glossary-local-cluster,local cluster>>. The connection to a
+remote cluster is unidirectional. See {ref}/modules-remote-clusters.html[Remote
+clusters].
 // end::remote-cluster-def[]
 
-[[glossary-replica-shard]] replica shard ::
-+
---
+[[glossary-replica-shard]] replica shard::
 // tag::replica-shard-def[]
-Each <<glossary-primary-shard,primary shard>> can have zero or more
-replicas. A replica is a copy of the primary shard, and has two
-purposes:
-
-1.  Increase failover: a replica shard can be promoted to a primary
-shard if the primary fails
-2.  Increase performance: get and search requests can be handled by
-primary or replica shards.
-
-By default, each primary shard has one replica, but the number of
-replicas can be changed dynamically on an existing index. A replica
-shard will never be started on the same node as its primary shard.
+Copy of a <<glossary-primary-shard,primary shard>>. Replica shards can improve
+search performance and resiliency by distributing data across multiple
+<<glossary-node,nodes>>. See {ref}/scalability.html[Clusters, nodes, and
+shards].
 // end::replica-shard-def[]
---
 
-[[glossary-rollover]] rollover ::
-+
---
+[[glossary-rollover]] rollover::
 // tag::rollover-def[]
 // tag::rollover-def-short[]
-Creates a new index for a rollover target when the existing index reaches a certain size, number of docs, or age.
-A rollover target can be either an <<indices-aliases, index alias>> or a <<data-streams, data stream>>.
+Creates a new write index when the current one reaches a certain size, number of
+docs, or age.
 // end::rollover-def-short[]
-
-For example, if you're indexing log data, you might use rollover to create daily or weekly indices.
-See the {ref}/indices-rollover-index.html[rollover index API].
+A rollover can target a <<data-streams, data stream>> or an
+<<indices-aliases,index alias>> with a write index.
 // end::rollover-def[]
---
 
 ifdef::permanently-unreleased-branch[]
 
-[[glossary-rollup]] rollup ::
+[[glossary-rollup]] rollup::
 // tag::rollup-def[]
-Aggregates an index's time series data and stores the results in a new read-only
-index. For example, you can roll up hourly data into daily or weekly summaries.
-See {ref}/xpack-rollup.html[Roll up your data].
+Aggregates an <<glossary-index,index>>'s time series data and stores the results
+in a new read-only index. For example, you can roll up hourly data into daily or
+weekly summaries. See {ref}/xpack-rollup.html[Rollups].
 // end::rollup-def[]
 
 endif::[]
 ifndef::permanently-unreleased-branch[]
 
-[[glossary-rollup]] rollup ::
+[[glossary-rollup]] rollup::
 // tag::rollup-def[]
-Summarize high-granularity data into a more compressed format to
-maintain access to historical data in a cost-effective way.
+Summarizes high-granularity data into a more compressed format to maintain access
+to historical data in a cost-effective way. See
+{ref}/xpack-rollup.html[Roll up your data].
 // end::rollup-def[]
 
-[[glossary-rollup-index]] rollup index ::
+[[glossary-rollup-index]] rollup index::
 // tag::rollup-index-def[]
-A special type of index for storing historical data at reduced granularity.
-Documents are summarized and indexed into a rollup index by a <<glossary-rollup-job,rollup job>>.
+Special type of <<glossary-index,index>> for storing historical data at reduced
+granularity. Documents are summarized and indexed into a rollup index by a
+<<glossary-rollup-job,rollup job>>. See {ref}/xpack-rollup.html[Rolling up
+historical data].
 // end::rollup-index-def[]
 
-[[glossary-rollup-job]] rollup job ::
+[[glossary-rollup-job]] rollup job::
 // tag::rollup-job-def[]
-A background task that runs continuously to summarize documents in an index and
-index the summaries into a separate rollup index.
-The job configuration controls what information is rolled up and how often.
+Background task that runs continuously to summarize documents in an
+<<glossary-index,index>> and index the summaries into a separate rollup index.
+The job configuration controls what data is rolled up and how often. See
+{ref}/xpack-rollup.html[Rolling up historical data].
 // end::rollup-job-def[]
 
 endif::[]
 
-[[glossary-routing]] routing ::
-+
---
+[[glossary-routing]] routing::
 // tag::routing-def[]
-When you index a document, it is stored on a single
-<<glossary-primary-shard,primary shard>>. That shard is chosen by hashing
-the `routing` value. By default, the `routing` value is derived from
-the ID of the document or, if the document has a specified parent
-document, from the ID of the parent document (to ensure that child and
-parent documents are stored on the same shard).
-
-This value can be overridden by specifying a `routing` value at index
-time, or a {ref}/mapping-routing-field.html[routing field]
-in the <<glossary-mapping,mapping>>.
+Process of sending and retrieving data from a specific
+<<glossary-primary-shard,primary shard>>. {es} uses a hashed routing value to
+choose this shard. You can provide a routing value in
+<<glossary-index,indexing>> and search requests to take advantage of caching.
+See the {ref}/mapping-routing-field.html[`_routing` field].
 // end::routing-def[]
---
 
-[[glossary-runtime-fields]] runtime field ::
+[[glossary-runtime-fields]] runtime field::
 // tag::runtime-fields-def[]
-A runtime field is a field that is evaluated at query time. You access runtime
-fields from the search API like any other field, and {es} sees runtime fields
-no differently. You can define runtime fields in the
-{ref}/runtime-mapping-fields.html[index mapping] or in the
-{ref}/runtime-search-request.html[search request].
+<<glossary-field,Field>> that is evaluated at query time. You access runtime
+fields from the search API like any other field, and {es} sees runtime fields no
+differently. See {ref}/runtime.html[Runtime fields].
 // end::runtime-fields-def[]
 
-[[glossary-searchable-snapshot]] searchable snapshot ::
+[[glossary-searchable-snapshot]] searchable snapshot::
 // tag::searchable-snapshot-def[]
-A <<glossary-snapshot, snapshot>> of an index that has been mounted as a
-<<glossary-searchable-snapshot-index, searchable snapshot index>> and can be
-searched as if it were a regular index.
+<<glossary-snapshot,Snapshot>> of an <<glossary-index,index>> mounted as a
+<<glossary-searchable-snapshot-index,searchable snapshot index>>. You can search
+this index like a regular index. See {ref}/searchable-snapshots.html[searchable
+snapshots].
 // end::searchable-snapshot-def[]
 
-[[glossary-searchable-snapshot-index]] searchable snapshot index ::
+[[glossary-searchable-snapshot-index]] searchable snapshot index::
 // tag::searchable-snapshot-index-def[]
-An <<glossary-index, index>> whose data is stored in a <<glossary-snapshot,
-snapshot>> that resides in a separate <<glossary-snapshot-repository,snapshot
-repository>> such as AWS S3. Searchable snapshot indices do not need
-<<glossary-replica-shard,replica>> shards for resilience, since their data is
-reliably stored outside the cluster.
+<<glossary-index,Index>> whose data is stored in a
+<<glossary-snapshot,snapshot>>. Searchable snapshot indices do not need
+<<glossary-replica-shard,replica shards>> for resilience, since their data is
+reliably stored outside the cluster. See
+{ref}/searchable-snapshots.html[searchable snapshots].
 // end::searchable-snapshot-index-def[]
 
-[[glossary-shard]] shard ::
-+
---
+[[glossary-segment]] segment::
+// tag::segment-def[]
+Data file in a <<glossary-shard,shard>>'s Lucene instance. {es} manages Lucene
+segments automatically.
+// end::segment-def[]
+
+[[glossary-shard]] shard::
 // tag::shard-def[]
-A shard is a single Lucene instance. It is a low-level “worker” unit
-which is managed automatically by Elasticsearch. An index is a logical
-namespace which points to <<glossary-primary-shard,primary>> and
-<<glossary-replica-shard,replica>> shards.
-
-Other than defining the number of primary and replica shards that an
-index should have, you never need to refer to shards directly.
-Instead, your code should deal only with an index.
-
-Elasticsearch distributes shards amongst all <<glossary-node,nodes>> in the
-<<glossary-cluster,cluster>>, and can move shards automatically from one
-node to another in the case of node failure, or the addition of new
-nodes.
+Lucene instance containing some or all data for an <<glossary-index,index>>.
+{es} automatically creates and manages these Lucene instances. There are two
+types of shards: <<glossary-primary-shard,primary>> and
+<<glossary-replica-shard,replica>>. See {ref}/scalability.html[Clusters, nodes,
+and shards].
 // end::shard-def[]
---
 
-[[glossary-shrink]] shrink ::
-+
---
+[[glossary-shrink]] shrink::
 // tag::shrink-def[]
 // tag::shrink-def-short[]
-Reduce the number of primary shards in an index.
+Reduces the number of <<glossary-primary-shard,primary shards>> in an index.
 // end::shrink-def-short[]
-
-You can shrink an index to reduce its overhead when the request volume drops.
-For example, you might opt to shrink an index once it is no longer the write index.
 See the {ref}/indices-shrink-index.html[shrink index API].
 // end::shrink-def[]
---
 
-[[glossary-snapshot]] snapshot ::
+[[glossary-snapshot]] snapshot::
 // tag::snapshot-def[]
-Captures the state of the whole cluster or of particular indices or data
-streams at a particular point in time. Snapshots provide a back up of a running
-cluster, ensuring you can restore your data in the event of a failure. You can
-also mount indices or datastreams from snapshots as read-only
-{ref}/glossary.html#glossary-searchable-snapshot-index[searchable snapshots].
+Backup taken of a running <<glossary-cluster,cluster>>. You can take snapshots
+of the entire cluster or only specific <<glossary-data-stream,data streams>> and
+<<glossary-index,indices>>. See {ref}/snapshot-restore.html[Snapshot and
+restore].
 // end::snapshot-def[]
 
-[[glossary-snapshot-lifecycle-policy]] snapshot lifecycle policy ::
+[[glossary-snapshot-lifecycle-policy]] snapshot lifecycle policy::
 // tag::snapshot-lifecycle-policy-def[]
-Specifies how frequently to perform automatic backups of a cluster and
-how long to retain the resulting snapshots.
+Specifies how frequently to perform automatic backups of a cluster and how long
+to retain the resulting <<glossary-snapshot,snapshots>>. See
+{ref}/snapshot-lifecycle-management.html[Manage the snapshot lifecycle]
 // end::snapshot-lifecycle-policy-def[]
 
-[[glossary-snapshot-repository]] snapshot repository ::
+[[glossary-snapshot-repository]] snapshot repository::
 // tag::snapshot-repository-def[]
-Specifies where snapshots are to be stored.
-Snapshots can be written to a shared filesystem or to a remote repository.
+Location where <<glossary-snapshot,snapshots>> are stored. A snapshot repository
+can be a shared filesystem or a remote repository, such as Azure or Google Cloud
+Storage. See {ref}/snapshot-restore.html[Snapshot and restore].
 // end::snapshot-repository-def[]
 
-[[glossary-source_field]] source field ::
+[[glossary-source_field]] source field::
 // tag::source-field-def[]
-By default, the JSON document that you index will be stored in the
-`_source` field and will be returned by all get and search requests.
-This allows you access to the original object directly from search
-results, rather than requiring a second step to retrieve the object
-from an ID.
+Original JSON object provided during <<glossary-index,indexing>>. See the
+{ref}/mapping-source-field.html[`_source` field].
 // end::source-field-def[]
 
-[[glossary-split]] split ::
+[[glossary-split]] split::
 // tag::split-def[]
-To grow the amount of shards in an index.
-See the {ref}/indices-split-index.html[split index API].
+Adds more <<glossary-primary-shard,primary shards>> to an
+<<glossary-index,index>>. See the {ref}/indices-split-index.html[split index
+API].
 // end::split-def[]
 
-[[glossary-system-index]] system index ::
+[[glossary-system-index]] system index::
 // tag::system-index-def[]
-An index that contains configuration information or other data used internally by the system,
-such as the `.security` index.
-The name of a system index is always prefixed with a dot.
-You should not directly access or modify system indices.
+<<glossary-index,Index>> containing configurations and other data used
+internally by the {stack}. System index names start with a dot (`.`), such as
+`.security`. Do not directly access or change system indices.
 // end::system-index-def[]
 
-[[glossary-term]] term ::
-+
---
+[[glossary-term]] term::
 // tag::term-def[]
-A term is an exact value that is indexed in Elasticsearch. The terms
-`foo`, `Foo`, `FOO` are NOT equivalent. Terms (i.e. exact values) can
-be searched for using _term_ queries.
-
-See also <<glossary-text,text>> and <<glossary-analysis,analysis>>.
+See {ref}/glossary.html#glossary-token[token].
 // end::term-def[]
---
 
-[[glossary-text]] text ::
-+
---
+[[glossary-text]] text::
 // tag::text-def[]
-Text (or full text) is ordinary unstructured text, such as this
-paragraph. By default, text will be <<glossary-analysis,analyzed>> into
-<<glossary-term,terms>>, which is what is actually stored in the index.
-
-Text <<glossary-field,fields>> need to be analyzed at index time in order to
-be searchable as full text, and keywords in full text queries must be
-analyzed at search time to produce (and search for) the same terms
-that were generated at index time.
-
-See also <<glossary-term,term>> and <<glossary-analysis,analysis>>.
+Unstructured content, such as a product description or log message. You
+typically <<glossary-analysis,analyze>> text for better search. See
+{ref}/analysis.html[Text analysis].
 // end::text-def[]
---
-
-[[glossary-type]] type ::
-// tag::type-def[]
-A type used to represent the _type_ of document, e.g. an `email`, a `user`, or a `tweet`.
-Types are deprecated and are in the process of being removed.
-See {ref}/removal-of-types.html[Removal of mapping types].
-// end::type-def[]
 
-[[glossary-warm-phase]] warm phase ::
+[[glossary-token]] token::
+// tag::token-def[]
+A chunk of unstructured <<glossary-text,text>> that's been optimized for search.
+In most cases, tokens are individual words. Tokens are also called terms. See
+{ref}/analysis.html[Text analysis].
+// end::token-def[]
+
+[[glossary-tokenization]] tokenization::
+// tag::tokenization-def[]
+Process of breaking unstructured text down into smaller, searchable chunks
+called <<glossary-token,tokens>>. See
+{ref}/analysis-overview.html#tokenization[Tokenization].
+// end::tokenization-def[]
+
+[[glossary-warm-phase]] warm phase::
 // tag::warm-phase-def[]
-The second possible phase in the <<glossary-index-lifecycle,index lifecycle>>.
-In the warm phase, an index is generally optimized for search and no longer updated.
+Second possible phase in the <<glossary-index-lifecycle,index lifecycle>>. In
+the warm phase, an <<glossary-index,index>> is generally optimized for search
+and no longer updated. See {ref}/ilm-policy-definition.html[Index lifecycle].
 // end::warm-phase-def[]
 
 [[glossary-warm-tier]] warm tier::
 // tag::warm-tier-def[]
-A <<glossary-data-tier, data tier>> that contains nodes that hold time series data
-that is accessed less frequently and rarely needs to be updated.
+<<glossary-data-tier,Data tier>> that contains <<glossary-node,nodes>> that hold
+time series data that is accessed less frequently and rarely needs to be
+updated. See {ref}/data-tiers.html[Data tiers].
 // end::warm-tier-def[]

docs/reference/indices/add-alias.asciidoc

@@ -6,7 +6,10 @@
 
 Creates or updates an index alias.
 
-include::{es-repo-dir}/glossary.asciidoc[tag=index-alias-desc]
+//tag::index-alias-desc[]
+An index alias is a secondary name for one or more indices. Most {es} APIs
+accept an index alias in place of an index name.
+//end::index-alias-desc[]
 
 [source,console]
 ----

docs/reference/indices/alias-exists.asciidoc

@@ -6,7 +6,7 @@
 
 Checks if an index alias exists.
 
-include::{es-repo-dir}/glossary.asciidoc[tag=index-alias-desc]
+include::{es-repo-dir}/indices/add-alias.asciidoc[tag=index-alias-desc]
 
 [source,console]
 ----

docs/reference/indices/delete-alias.asciidoc

@@ -6,7 +6,7 @@
 
 Deletes an existing index alias.
 
-include::{es-repo-dir}/glossary.asciidoc[tag=index-alias-desc]
+include::{es-repo-dir}/indices/add-alias.asciidoc[tag=index-alias-desc]
 
 [source,console]
 ----

docs/reference/indices/get-alias.asciidoc

@@ -6,7 +6,7 @@
 
 Returns information about one or more index aliases.
 
-include::{es-repo-dir}/glossary.asciidoc[tag=index-alias-desc]
+include::{es-repo-dir}/indices/add-alias.asciidoc[tag=index-alias-desc]
 
 [source,console]
 ----

docs/reference/indices/recovery.asciidoc

@@ -42,7 +42,13 @@ of syncing a replica shard from a primary shard.
 Upon completion,
 the replica shard is available for search.
 
-include::{es-repo-dir}/glossary.asciidoc[tag=recovery-triggers]
+Recovery automatically occurs during the following processes:
+
+* Node startup or failure. This type of recovery is called a local store
+  recovery.
+* <<glossary-replica-shard,Primary shard replication>>.
+* Relocation of a shard to a different node in the same cluster.
+* <<snapshots-restore-snapshot,Snapshot restoration>>.
 
 // end::shard-recovery-desc[]