mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
518 lines
20 KiB
Text
518 lines
20 KiB
Text
////
|
||
============
|
||
IMPORTANT
|
||
Add new terms to the Stack Docs glossary:
|
||
https://github.com/elastic/stack-docs/tree/master/docs/en/glossary
|
||
============
|
||
////
|
||
|
||
[glossary]
|
||
[[glossary]]
|
||
= Glossary
|
||
|
||
[glossary]
|
||
[[glossary-analysis]] analysis::
|
||
// tag::analysis-def[]
|
||
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::
|
||
// tag::api-key-def[]
|
||
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::
|
||
// tag::auto-follow-pattern-def[]
|
||
<<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::
|
||
// tag::cluster-def[]
|
||
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::
|
||
// tag::cold-phase-def[]
|
||
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[]
|
||
<<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::
|
||
// tag::component-template-def[]
|
||
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[]
|
||
<<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-init})::
|
||
// tag::ccr-def[]
|
||
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[]
|
||
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::
|
||
// tag::data-stream-def[]
|
||
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[]
|
||
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
|
||
<<glossary-frozen-tier,frozen tier>>. See {ref}/data-tiers.html[Data tiers].
|
||
// end::data-tier-def[]
|
||
|
||
[[glossary-delete-phase]] delete phase::
|
||
// tag::delete-phase-def[]
|
||
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::
|
||
// tag::document-def[]
|
||
JSON object containing data stored in {es}. See
|
||
{ref}/documents-indices.html[Documents and indices].
|
||
// end::document-def[]
|
||
|
||
[[glossary-eql]]
|
||
Event Query Language (EQL)::
|
||
// tag::eql-def[]
|
||
<<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::
|
||
// tag::field-def[]
|
||
Key-value pair in a <<glossary-document,document>>. See
|
||
{ref}/mapping.html[Mapping].
|
||
// end::field-def[]
|
||
|
||
[[glossary-filter]] filter::
|
||
// tag::filter-def[]
|
||
<<glossary-query,Query>> that does not score matching documents. See
|
||
{ref}/query-filter-context.html[filter context].
|
||
// end::filter-def[]
|
||
|
||
[[glossary-flush]] flush::
|
||
// tag::flush-def[]
|
||
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::
|
||
// tag::follower-index-def[]
|
||
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::
|
||
// tag::force-merge-def[]
|
||
// tag::force-merge-def-short[]
|
||
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[]
|
||
See the {ref}/indices-forcemerge.html[force merge API].
|
||
// end::force-merge-def[]
|
||
|
||
[[glossary-freeze]] freeze::
|
||
// tag::freeze-def[]
|
||
// tag::freeze-def-short[]
|
||
Makes an index read-only and minimizes its memory footprint.
|
||
// end::freeze-def-short[]
|
||
See the {ref}/freeze-index-api.html[freeze API].
|
||
// end::freeze-def[]
|
||
|
||
[[glossary-frozen-index]] frozen index::
|
||
// tag::frozen-index-def[]
|
||
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::
|
||
// tag::frozen-phase-def[]
|
||
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[]
|
||
<<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 data stream or index::
|
||
// tag::hidden-index-def[]
|
||
<<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::
|
||
// tag::hot-phase-def[]
|
||
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[]
|
||
<<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::
|
||
// tag::id-def[]
|
||
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::
|
||
// tag::index-def[]
|
||
. 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::
|
||
// tag::index-alias-def[]
|
||
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::
|
||
// tag::index-lifecycle-def[]
|
||
Five phases an <<glossary-index,index>> can transition through:
|
||
<<glossary-hot-phase,hot>>, <<glossary-warm-phase,warm>>,
|
||
<<glossary-cold-phase,cold>>, <<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::
|
||
// tag::index-lifecycle-policy-def[]
|
||
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::
|
||
// tag::index-pattern-def[]
|
||
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::
|
||
// tag::index-template-def[]
|
||
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::
|
||
// tag::leader-index-def[]
|
||
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::
|
||
// tag::local-cluster-def[]
|
||
<<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::
|
||
// tag::mapping-def[]
|
||
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-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 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::
|
||
// tag::primary-shard-def[]
|
||
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::
|
||
// tag::query-def[]
|
||
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::
|
||
// tag::recovery-def[]
|
||
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::
|
||
// tag::reindex-def[]
|
||
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::
|
||
// tag::remote-cluster-def[]
|
||
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::
|
||
// tag::replica-shard-def[]
|
||
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::
|
||
// tag::rollover-def[]
|
||
// tag::rollover-def-short[]
|
||
Creates a new write index when the current one reaches a certain size, number of
|
||
docs, or age.
|
||
// end::rollover-def-short[]
|
||
A rollover can target a <<glossary-data-stream,data stream>> or an
|
||
<<glossary-index-alias,index alias>> with a write index.
|
||
// end::rollover-def[]
|
||
|
||
[[glossary-rollup]] rollup::
|
||
// tag::rollup-def[]
|
||
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::
|
||
// tag::rollup-index-def[]
|
||
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::
|
||
// tag::rollup-job-def[]
|
||
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[]
|
||
|
||
[[glossary-routing]] routing::
|
||
// tag::routing-def[]
|
||
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::
|
||
// tag::runtime-fields-def[]
|
||
<<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::
|
||
// tag::searchable-snapshot-def[]
|
||
<<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::
|
||
// tag::searchable-snapshot-index-def[]
|
||
<<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-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[]
|
||
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::
|
||
// tag::shrink-def[]
|
||
// tag::shrink-def-short[]
|
||
Reduces the number of <<glossary-primary-shard,primary shards>> in an index.
|
||
// end::shrink-def-short[]
|
||
See the {ref}/indices-shrink-index.html[shrink index API].
|
||
// end::shrink-def[]
|
||
|
||
[[glossary-snapshot]] snapshot::
|
||
// tag::snapshot-def[]
|
||
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::
|
||
// tag::snapshot-lifecycle-policy-def[]
|
||
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::
|
||
// tag::snapshot-repository-def[]
|
||
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::
|
||
// tag::source-field-def[]
|
||
Original JSON object provided during <<glossary-index,indexing>>. See the
|
||
{ref}/mapping-source-field.html[`_source` field].
|
||
// end::source-field-def[]
|
||
|
||
[[glossary-split]] split::
|
||
// tag::split-def[]
|
||
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::
|
||
// tag::system-index-def[]
|
||
<<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::
|
||
// tag::term-def[]
|
||
See {ref}/glossary.html#glossary-token[token].
|
||
// end::term-def[]
|
||
|
||
[[glossary-text]] text::
|
||
// tag::text-def[]
|
||
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-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[]
|
||
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[]
|
||
<<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[]
|