237 lines
9.3 KiB
Plaintext
237 lines
9.3 KiB
Plaintext
[glossary]
|
|
[[glossary]]
|
|
= Glossary of terms
|
|
|
|
[glossary]
|
|
[[glossary-analysis]] analysis ::
|
|
|
|
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>>.
|
|
|
|
[[glossary-cluster]] cluster ::
|
|
|
|
A cluster consists of one or more <<glossary-node,nodes>> which share the
|
|
same cluster name. Each cluster has a single master node which is
|
|
chosen automatically by the cluster and which can be replaced if the
|
|
current master node fails.
|
|
|
|
[[glossary-ccr]] {ccr} (CCR)::
|
|
|
|
The {ccr} feature enables you to replicate indices in remote clusters to your
|
|
local cluster. For more information, see
|
|
{stack-ov}/xpack-ccr.html[{ccr-cap}].
|
|
|
|
[[glossary-ccs]] {ccs} (CCS)::
|
|
|
|
The {ccs} feature enables any node to act as a federated client across
|
|
multiple clusters. See <<modules-cross-cluster-search>>.
|
|
|
|
[[glossary-document]] document ::
|
|
|
|
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 <<glossary-type,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.
|
|
|
|
[[glossary-field]] field ::
|
|
|
|
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 <<glossary-type,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.
|
|
|
|
[[glossary-filter]] filter ::
|
|
|
|
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 <<query-filter-context,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-follower-index]] follower index ::
|
|
|
|
Follower indices are the target indices for <<glossary-ccr,{ccr}>>. They exist
|
|
in your local cluster and replicate <<glossary-leader-index,leader indices>>.
|
|
|
|
[[glossary-id]] id ::
|
|
|
|
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>>)
|
|
|
|
[[glossary-index]] index ::
|
|
|
|
An index is like a _table_ in a relational database. It has a
|
|
<<glossary-mapping,mapping>> which contains a <<glossary-type,type>>,
|
|
which contains the <<glossary-field,fields>> in the index.
|
|
+
|
|
An index is a logical namespace which maps to one or more
|
|
<<glossary-primary-shard,primary shards>> and can have zero or more
|
|
<<glossary-replica-shard,replica shards>>.
|
|
|
|
[[glossary-leader-index]] leader index ::
|
|
|
|
Leader indices are the source indices for <<glossary-ccr,{ccr}>>. They exist
|
|
on remote clusters and are replicated to
|
|
<<glossary-follower-index,follower indices>>.
|
|
|
|
[[glossary-mapping]] mapping ::
|
|
|
|
A mapping is like a _schema definition_ in a relational database. Each
|
|
<<glossary-index,index>> has a mapping, which defines a <<glossary-type,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.
|
|
|
|
[[glossary-node]] node ::
|
|
|
|
A node is a running instance of Elasticsearch which 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.
|
|
+
|
|
At startup, a node will use unicast to discover an existing cluster with
|
|
the same cluster name and will try to join that cluster.
|
|
|
|
[[glossary-primary-shard]] primary shard ::
|
|
|
|
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
|
|
index is created. However, an index can be split into a new index using the
|
|
<<indices-split-index, split API>>.
|
|
+
|
|
See also <<glossary-routing,routing>>
|
|
|
|
[[glossary-query]] query ::
|
|
|
|
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 <<query-filter-context>>.
|
|
|
|
[[glossary-recovery]] recovery ::
|
|
The process of syncing a shard copy from a source shard. Upon completion, the recovery process makes the shard copy available for queries.
|
|
+
|
|
Recovery automatically occurs anytime a shard moves to a different node in the same cluster, including:
|
|
|
|
* Node startup
|
|
* Node failure
|
|
* Index shard replication
|
|
* Snapshot restoration
|
|
|
|
[[glossary-replica-shard]] replica shard ::
|
|
|
|
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.
|
|
|
|
[[glossary-routing]] routing ::
|
|
|
|
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 <<mapping-routing-field,routing
|
|
field>> in the <<glossary-mapping,mapping>>.
|
|
|
|
[[glossary-shard]] shard ::
|
|
|
|
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.
|
|
|
|
[[glossary-source_field]] source field ::
|
|
|
|
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.
|
|
|
|
[[glossary-term]] term ::
|
|
|
|
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>>.
|
|
|
|
[[glossary-text]] text ::
|
|
|
|
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>>.
|
|
|
|
[[glossary-type]] type ::
|
|
|
|
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 <<removal-of-types>>.
|
|
|