diff --git a/docs/reference/glossary.asciidoc b/docs/reference/glossary.asciidoc index b6ce23ad3b087..e340268e4bbda 100644 --- a/docs/reference/glossary.asciidoc +++ b/docs/reference/glossary.asciidoc @@ -5,222 +5,223 @@ [glossary] [[glossary-analysis]] analysis :: - Analysis is the process of converting <> to - <>. 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 <> 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 <> and <>. +Analysis is the process of converting <> to +<>. 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 <> 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 <> and <>. [[glossary-cluster]] cluster :: - A cluster consists of one or more <> 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. - +A cluster consists of one or more <> 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}]. - +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 <>. +The {ccs} feature enables any node to act as a federated client across +multiple clusters. See <>. [[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 <> and has a <> and an - <>. - + - A document is a JSON object (also known in other languages as a hash / - hashmap / associative array) which contains zero or more - <>, or key-value pairs. - + - The original JSON document that is indexed will be stored in the - <>, which is returned by default when - getting or searching for a 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 <> and has a <> and an +<>. ++ +A document is a JSON object (also known in other languages as a hash / +hashmap / associative array) which contains zero or more +<>, or key-value pairs. ++ +The original JSON document that is indexed will be stored in the +<>, which is returned by default when +getting or searching for a document. [[glossary-field]] field :: - A <> 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 <> for each field has a field _type_ (not to - be confused with document <>) 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. +A <> 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 <> for each field has a field _type_ (not to +be confused with document <>) 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 <>, 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 <>, - 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. - +A filter is a non-scoring <>, 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 <>, +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 <>. They exist - in your local cluster and replicate <>. - + +Follower indices are the target indices for <>. They exist +in your local cluster and replicate <>. + [[glossary-id]] id :: - The ID of a <> 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 <>) +The ID of a <> 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-index]] index :: - An index is like a _table_ in a relational database. It has a - <> which contains a <>, - which contains the <> in the index. - + - An index is a logical namespace which maps to one or more - <> and can have zero or more - <>. - +An index is like a _table_ in a relational database. It has a +<> which contains a <>, +which contains the <> in the index. ++ +An index is a logical namespace which maps to one or more +<> and can have zero or more +<>. + [[glossary-leader-index]] leader index :: - - Leader indices are the source indices for <>. They exist - on remote clusters and are replicated to - <>. + +Leader indices are the source indices for <>. They exist +on remote clusters and are replicated to +<>. [[glossary-mapping]] mapping :: - A mapping is like a _schema definition_ in a relational database. Each - <> has a mapping, which defines a <>, - 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. +A mapping is like a _schema definition_ in a relational database. Each +<> has a mapping, which defines a <>, +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 - <>. 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 <>. When - you index a document, it is indexed first on the primary shard, then - on all <> of the primary shard. - + - By default, an <> has 5 primary shards. You can - specify fewer or more primary shards to scale the number of - <> that your index can handle. - + - You cannot change the number of primary shards in an index, once the - index is created. - + - See also <> +A node is a running instance of Elasticsearch which belongs to a +<>. 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 <>. When +you index a document, it is indexed first on the primary shard, then +on all <> of the primary shard. ++ +By default, an <> has 5 primary shards. You can +specify fewer or more primary shards to scale the number of +<> that your index can handle. ++ +You cannot change the number of primary shards in an index, once the +index is created. ++ +See also <> [[glossary-query]] query :: - A query is the basic component of a search. A search can be defined by one or more queries - which can be mixed and matched in endless combinations. While <> are - queries that only determine if a document matches, those queries that also calculate how well - the document matches are known as "scoring queries". Those queries assign it a score, which is - later used to sort matched documents. Scoring queries take more resources than <> - and their query results are not cacheable. As a general rule, use query clauses for full-text - search or for any condition that requires scoring, and use filters for everything else. - - [[glossary-replica-shard]] replica shard :: - - Each <> 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. +A query is the basic component of a search. A search can be defined by one or more queries +which can be mixed and matched in endless combinations. While <> are +queries that only determine if a document matches, those queries that also calculate how well +the document matches are known as "scoring queries". Those queries assign it a score, which is +later used to sort matched documents. Scoring queries take more resources than <> +and their query results are not cacheable. As a general rule, use query clauses for full-text +search or for any condition that requires scoring, and use filters for everything else. + +[[glossary-replica-shard]] replica shard :: ++ +-- +Each <> can have zero or more +replicas. A replica is a copy of the primary shard, and has two +purposes: + +. increase failover: a replica shard can be promoted to a primary +shard if the primary fails +. 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 - <>. 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 <> in the <>. +When you index a document, it is stored on a single +<>. 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 <> in the <>. [[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 <> and - <> 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 <> in the - <>, 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. +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 <> and +<> 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 <> in the +<>, 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 <> and <>. +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 <> and <>. [[glossary-text]] text :: - Text (or full text) is ordinary unstructured text, such as this - paragraph. By default, text will be <> into - <>, which is what is actually stored in the index. - + - Text <> 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 <> and <>. +Text (or full text) is ordinary unstructured text, such as this +paragraph. By default, text will be <> into +<>, which is what is actually stored in the index. ++ +Text <> 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 <> and <>. [[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 <>. - +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 <>. \ No newline at end of file