一、getting started
-
use case 1.1 存储大数据,做查询 1.2 存储日志 1.3 从第三方收集数据,进行分析、查询 1.4 分析聚合数据,利用kibana展示
-
基本概念 2.1 near realtime 近实时
2.2 cluster(集群) 有多个node,每个cluster有唯一的一个名字,默认是‘elasticsearch’
2.3 node(节点) 一个集群中的其中一个服务节点,默认名字是一个uuid,可以指定它加入的集群的名字
2.4 index(索引)是具有稍微类似特征文档的集合,相当于数据库中的一个数据库实例。
一个索引也有一个名字,它在 对document(文档)执行 indexing(索引),search(搜索),update(更新)和 delete(删除)等操作时 会被涉及到。一个集群中可以有多个索引。
你也许已经注意到 索引 这个词在 Elasticsearch 语境中包含多重意思, 所以有必要做一点儿说明: 索引(名词): 如前所述,一个 索引 类似于传统关系数据库中的一个 数据库 ,是一个存储关系型文档的地方。 索引 (index) 的复数词为 indices 或 indexes 。 索引(动词): 索引一个文档 就是存储一个文档到一个 索引 (名词)中以便它可以被检索和查询到。这非常类似于 SQL 语句中的 INSERT 关键词,除了文档已存在时新文档会替换旧文档情况之外。 倒排索引: 关系型数据库通过增加一个 索引 比如一个 B树(B-tree)索引 到指定的列上,以便提升数据检索速度。Elasticsearch 和 Lucene 使用了一个叫做 倒排索引 的结构来达到相同的目的。
- 默认的,一个文档中的每一个属性都是 被索引 的(有一个倒排索引)和可搜索的。一个没有倒排索引的属性是不能被搜索到的。我们将在 倒排索引 讨论倒排索引的更多细节。
2.5 type (类型)相当于数据库中的一个表。
在 Index(索引)中,可以定义一个或多个类型。一个类型是索引中一个逻辑的种类/分区,它的语义完全取决于您自己。
一般情况下,一个类型被定义成一组常见字段的文档。例如,假设您运行着一个博客平台并且在一个单独的索引中存储了所有的数据。在这个索引中,您也许定义了一个用户数据类型,博客数据类型,和评论数据类型。在高版本中会被移除。
2.6 document (文档) 是索引信息的基本单位,相当于数据库中的一条数据
例如,您有一存储 customer(客户)数据的文档,另一个是存储 product(产品)数据的文档,还有一个是存储 order(订单)数据的文档。该文档可以使用 JSON 来表示,它是一种无处不在的互联网数据交换格式。在索引/类型中,您可以存储许多文档。
注意,尽管一个文档物理的存在于索引中,实际上一个文档必须被 索引/分配 给索引内的类型。
3. exploring cluster 探索集群
3.1 集群健康:Cluster Health
curl -XGET 'localhost:9200/_cat/health?v&pretty'
可以获得 green,yellow,或者 red 的 status。Green 表示一切正常(集群功能齐全), yellow 表示所有数据可用,但是有些副本尚未分配(集群功能齐全),red 意味着由于某些原因有些数据不可用。注意,集群是 red,它仍然具有部分功能(例如,它将继续从可用的分片中服务搜索请求),但是您可能需要尽快去修复它,因为您已经丢失数据了。
3.2 操作索引:Create an Index
curl -XGET 'localhost:9200/_cat/indices?v&pretty' 列出所有索引
curl -XPUT 'localhost:9200/customer?pretty' 添加索引
curl -XDELETE 'localhost:9200/customer?pretty' 删除索引
3.3 操作文档:Modifying Your Data
PUT:
curl -XPUT 'localhost:9200/customer/external/1?pretty&pretty' -d'{ "name": "John Doe"}'
添加文档,如果文档已存在,则更新。其中external是type(类型),其中 1 是 类型的ID
POST:
curl -XPOST 'localhost:9200/customer/external/1/_update?pretty&pretty' -d'{ "doc": { "name": "Jane Doe" }}'
_update 更新文档
curl -XDELETE 'localhost:9200/customer/external/2?pretty&pretty' 删除文档
curl -XGET 'localhost:9200/customer/external/1?pretty' 获取文档
curl -XPOST 'localhost:9200/customer/external/_bulk?pretty&pretty' -d'
_bulk 批量处理:
POST /customer/_doc/_bulk?pretty
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"2"}}
将 HTTP 命令由 PUT 改为 GET 可以用来检索文档,同样的,可以使用 DELETE 命令来删除文档,以及使用 HEAD 指令来检查文档是否存在。如果想更新已存在的文档,只需再次 PUT 。 PUT 和 POST 区别:他们都可以用来提交和更新资源,但是PUT的接口是幂等的。
二、 查询操作:The Search API ----> _search
1.REST request URI 根据uri查询
GET bank/account/_search?q=age:39&pretty&pretty
对index为bank,type为account进行检索
Multi-Index, Multi-Type : 多index、多type查询
It also support wildcards, for example: test* or test or tet or test, and the ability to "add" (+) and "remove" (-), for example: +test*,-test3. 更多语法查询官网
/_search 在所有的索引中搜索所有的类型
/gb/_search 在 gb 索引中搜索所有的类型
/gb,us/_search 在 gb 和 us 索引中搜索所有的文档
/g*,u*/_search 在任何以 g 或者 u 开头的索引中搜索所有的类型
/gb/user/_search 在 gb 索引中搜索 user 类型
/gb,us/user,tweet/_search 在 gb 和 us 索引中搜索 user 和 tweet 类型
/_all/user,tweet/_search 在所有的索引中搜索 user 和 tweet 类型
参数:
- q ----> map to query string query !!! 看完query string query回过头来看!!!???
- df 当没有指定查询的字段时,指定默认查询字段。
- analyzer 指定查询分析器???
- analyze_wildcard(通配符) 是否应分析通配符和前缀查询。默认为false。
- batched_reduce_size 减少每个分片查询的数据量。如果每次查询分片数大的话,减少这个值可以用来避免机器占用过多内存。
- default_operator 默认的操作符为 OR ,还可以是AND。
- lenient 宽容的。如果是true,则字段类型是敏感的,如向数字字段提供字符串查询,则会导致失败,默认是false
- explain 解释对命中的得分。
- _source 是否显示_source ,默认true。也可以使用_source_include 或者_source_exclude选择显示的字段。
- timeout
- from
- size
- search_type
- stored_fields ???
- sort 排序:sort=age:asc,好像也可以根据分数来排序???
- track_scores: ??? When sorting, set to true in order to still track scores and return them as part of each hit.
- track_total_hits: ??? Set to false in order to disable the tracking of the total number of hits that match the query
- terminate_after
- search_type :要执行的搜索操作的类型。可以是 dfs_query_then_fetch 或 query_then_fetch。默认为 query_then_fetch。有关可以执行的不同类型搜索的更多详细信息,请参阅搜索类型。
举例:
curl -XGET 'localhost:9200/bank/_search?q=*&sort=account_number:asc&pretty'
在响应中,我们可以看到以下几个部分 :
took - Elasticsearch 执行搜索的时间(毫秒)
time_out - 告诉我们搜索是否超时
_shards - 告诉我们多少个分片被搜索了,以及统计了成功/失败的搜索分片
hits - 搜索结果
hits.total - 搜索结果
hits.hits - 实际的搜索结果数组(默认为前 10 的文档)
sort - 结果的排序 key(键)(没有则按 score 排序)
score 和 max_score -现在暂时忽略这些字段
2.REST request body( 全文搜索编辑 ) : DSL
- query: 使用DSL查询,具体查看DSL语法
- from/size:
- sort:
- _source:
- stored_fields :存储字段。stored_fields 参数是关于显式标记为存储在映射中的字段,默认情况下关闭, ????
- script: 脚本。 看Modules » Scripting???
- docvalue_fields : Mapping » Mapping parameters » doc_values????
- filter/post_filter: filter先过滤再聚合,post_filter先聚合再过滤。
- highlight: 高亮
- rescoring: ??? 重新计算分数
- search_type:
- scroll API : 滚动api
- preference:控制要对其执行搜索请求的分片副本的首选项
- explain: 启用每次匹配对其评分计算方式的说明。
- version: 返回每个搜索匹配的版本。
- index_boost: 允许在跨多个索引搜索时为每个索引配置不同的查询级别。比如更希望从indexA中命中,则:
"indices_boost" : {
"index1" : 1.4,
"index2" : 1.3
}
- min_score: 排除 _score 小于 min_score 中指定的最小值的文档
- named queries : ????
- inner hits: ???
- search_after:分页深度太深。search_after 参数通过提供活动光标来规避此问题。 这个想法是使用前一页的结果来帮助检索下一页。
- field collapsing:字段折叠。允许基于字段对结果进行折叠。?????
Count API
_count 返回计数值
validate API
_validate 验证查询是否有效
Search 模板 ???
/_search/template
Search Shards API 查询分片API ???
_search_shards
suggesters ???
Multi Search API ???
_msearch 一次有多个query
Expliain API : Explain API 计算查询和特定文档的分数说明
_explain
Profile API
在_search中,添加参数:"profile": true 显示查询详细过程,可以用来判断为何比较慢
三、聚合Aggregations:每个聚合都是一个或者多个桶和零个或者多个指标的组合
- Bucket:桶,满足特定条件的文档的集合,类似于sql中的group by。它也可以嵌套使用。 有各种构造桶的方式,如:
- terms桶:会为每个碰到的唯一词项动态创建新的桶。 因为我们告诉它使用 color 字段,所以 terms 桶会为每个颜色动态创建新桶。其实就是看成一个分词是一个组。
"aggs" : { "popular_colors" : { 桶的名字 "terms" : { terms构建桶 "field" : "color" 构建的属性 } } }
2. date_histogram
3. date_range
4. Missing Aggregation
5. range aggregation
6. "size":0 , 去掉匹配的数据,只留aggregations
2. Metric(度量、指标):对桶内的文档进行统计计算。如:计数:value_count、平均值:avg、最大值max,最小值min。。。
```json
计算age字段的最大值,赋值给max_age。计算age的最小值,赋值给min_age
"aggs":{
"min_age":{
"min":{"field":"age"}
},
"max_age":{
"max":{"field":"age"}
}
}
结果:
"aggregations": {
"max_age": {
"value": 40
},
"min_age": {
"value": 20
}
}
- Matrix: 矩阵,与文件有关
- Pipeline: 将其他的聚类方法的输出结果以及与其相连的度量进行聚合。
- Structuring Aggregations:结构化聚合
- Values Source
四、索引API
- 创建、删除、获取、存在等。
以下特别重要:
正排索引是从文档到关键字的映射(已知文档求关键字);
倒排索引是从关键字到文档的映射(已知关键字求文档)。
搜索时,我们需要一个“词”到“文档”列表的映射
排序时,我们需要一个“文档”到“词“列表的映射,换句话说,我们需要一个在倒排索引的基础上建立的“正排索引”
在默认情况下许多字段都是 indexed(被索引的),这使得它们可以被搜索.反向索引允许查询通过唯一性排序的 term(词根)列表来查询 term(词根),并且可以立即访问包含该 term(词根)的文档.
这里的“正排索引”结构通常在其他系统中(如关系型数据库)被称为“列式存储”。本质上,它是在数据字段的一列上存储所有value,这种结构在某些操作上会表现得很高效,比如排序。
在ES里这种“列式存储”就是我们熟悉的“doc values”,默认情况下它是被启用的,doc values在index-time(索引期)被创建:当一个字段被索引时,ES会把“词”加入到倒排索引中,同时把这些词也加入到面向“列式存储”的doc values中(存储在硬盘上)。
搜索需要回答一个问题 “哪个 document(文档) 包含这个 term(词条)”,然而排序和聚合需要回答一个不同的问题 " 这个字段在这个 document(文档)中的值是多少?".!!!!!!!!!!!!!!!!
五、cat API
将以下信息在终端中显示的更好看
- /_cat/allocation
- /_cat/shards
- /_cat/shards/{index}
- /_cat/master
- /_cat/nodes
- /_cat/tasks
- /_cat/indices
- /_cat/indices/{index}
- /_cat/segments
- /_cat/segments/{index}
- /_cat/count
- /_cat/count/{index}
- /_cat/recovery
- /_cat/recovery/{index}
- /_cat/health
- /_cat/pending_tasks
- /_cat/aliases
- /_cat/aliases/{alias}
- /_cat/thread_pool
- /_cat/thread_pool/{thread_pools}
- /_cat/plugins
- /_cat/fielddata
- /_cat/fielddata/{fields}
- /_cat/nodeattrs
- /_cat/repositories
- /_cat/snapshots/{repository}
- /_cat/templates
六、集群API
- Cluster Allocation Explain API -> 它的目的是帮助回答这个问题 “为什么这个分片没有被分配”。为了说明分片的分配(未分配状态),发出一个这样的请求 :
- Cluster Health
- Cluster Reroute 路由
- Cluster State 状态
- Cluster Stats 统计
- Cluster Update Settings
- Nodes hot_threads
- Nodes Info (集群节点信息)API 可以获取集群中一个或多个节点的信息。
- Nodes Stats 节点统计信息
- Pending cluster tasks -> pending cluster tasks(添加集群任务)API 返回一个集群级别中还没有被执行的操作的列表(例如,创建索引,更新映射,分配或故障的分片)。
- Task Management API
七、es的各个Module(模块)
本章节负责介绍Elasticsearch包含的各个模块的功能,每个模块的配置都可以通过如下方式进行配置:
- 静态的
这些配置项必须基于节点来进行设置,在启动节点前可以通过elasticsearch.yml配置文件、环境变量、命令行参数方式来进行配置。他们必须明确地在集群中的每个节点上进行设置。
- 动态的
这些配置可以通过群集的cluster-update-settings API进行动态更新。
本节介绍的模块有:
-
Cluster-level routing and shard allocation(集群级别的路由与分片分配)) 用来控制在何处、何时、以及如何给节点分配分片。
-
Discovery(发现) 构成一个集群的节点彼此之间是如何发现的。
-
Gateway(网关) 集群启动恢复前需要多少个节点加入。
-
HTTP 用来控制配置HTTP REST接口。
-
Indices(索引) 所有跟索引相关的设置。
-
Network(网络) 控制默认的网络设置。
-
Node client(节点客户端) 一个加入集群的Java客户端节点,但不能保存数据或作为主节点。
-
Painless Elasticsearch内置的脚本语言,遵循尽可能的安全设计。
-
Plugins(插件) 通过插件来扩展Elasticsearch的功能。
-
Scripting(脚本) 通过Lucene表达式、Groovy、Python、以及Javascript来自定义脚本。你也可以使用内置的脚本语言Painless。
-
Snapshot/Restore(快照/还原) 通过快照与还原模块来备份你的数据。
-
Thread pools(线程池) Elasticsearch专用的线程池的信息。
-
Transport(传输) Elasticsearch内部各节点之间的网络传输层通信配置。
-
Tribe nodes Tribe节点能加入一个或多个集群,并作为它们之间的联合客户端。
-
Cross cluster Search(跨集群搜索) 跨集群搜索功能可以通过一个不加入集群、并且能作为它们之间的联合客户端来实现一个以上集群的搜索。
八、索引模块
包括索引的各个设置和信息查看 Settings in other index modules(其他索引模块的设置) 在索引模块中其他可用的索引设置 :
-
Analysis(分析) 定义 analyzers(分析器)、tokenizers(分词器)、token filters(词元过滤器)和 character filters(字符过滤器)。
-
Index shard allocation(索引分片分配) 控制索引分配给节点的位置、时间、以及分片的方式。
-
Mapping(映射) 启用或禁用索引的动态映射。
-
Merging(合并) 控制后台合并线程如何合并分片。
-
Similarities(相似性) 配置自定义相似性设置以自定义搜索结果的计分方式。
-
Slowlog(慢日志) 控制记录搜索和索引请求的响应时间。
-
Store(存储)) 配置用于存储分片数据的文件系统类型。
-
Translog(事务日志) 控制事务日志和后台刷新操作。
九、查询DSL
Elasticsearch 提供了一个基于 JSON 的完整的查询 DSL 来定义查询。将查询 DSL 视为查询的 AST,由两种类型的子句组成:
一个查询语句 的典型结构!!!!!!!!!!!!!:
{
QUERY_NAME: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}
如果是针对某个字段,那么它的结构如下:
{
QUERY_NAME: {
FIELD_NAME: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}
}
-
叶查询子句 -> 叶查询子句在特定查询中查找特定值,例如匹配match、项值term、范围查询range。这些查询都可以给自己使用。
-
复合查询子句 -> 主要用于 合并其它查询语句,用于以逻辑方式组合多个查询(例如 bool 或 dis_max 查询),或更改其行为(如 constant_score 查询)。 比如,一个 bool 语句 允许在你需要的时候组合其它语句,无论是 must 匹配、 must_not 匹配还是 should 匹配,同时它可以包含不评分的过滤器(filters):
{
"bool": {
"must": { "match": { "tweet": "elasticsearch" }},
"must_not": { "match": { "name": "mary" }},
"should": { "match": { "tweet": "full text" }},
"filter": { "range": { "age" : { "gt" : 30 }} }
}
}
一条复合语句可以合并 任何 其它查询语句,包括复合语句,了解这一点是很重要的。这就意味着,复合语句之间可以互相嵌套,可以表达非常复杂的逻辑。
{
"bool": {
"must": { "match": { "email": "business opportunity" }},
"should": [
{ "match": { "starred": true }},
{ "bool": {
"must": { "match": { "folder": "inbox" }},
"must_not": { "match": { "spam": true }}
}}
],
"minimum_should_match": 1
}
}
Elasticsearch 使用的查询语言(DSL) 拥有一套查询组件,这些组件可以以无限组合的方式进行搭配。这套组件可以在以下两种情况下使用:过滤情况(filtering context)和查询情况(query context)。
当使用于 过滤情况 时,查询被设置成一个“不评分”或者“过滤”查询。即,这个查询只是简单的问一个问题:“这篇文档是否匹配?”。回答也是非常的简单,yes 或者 no ,二者必居其一。 最重要的是,filter不需要统计评分,而且es会缓存,因此更快,更高效!!!!
查询子句的行为有所不同,具体取决于它们是在查询上下文还是过滤器上下文中使用。
查询上下文: query
在查询上下文中使用的查询子句回答了问题“此文档与此查询子句匹配程度如何?”除了决定文档是否匹配之外,查询子句还计算一个得分( _score )表示文档相对于其他文档的匹配程度。 每当将查询子句传递给 query 参数(例如,search API中的 query 参数)时,查询上下文都有效。
过滤上下文: filter
在过滤器上下文中,查询子句回答问题“此文档是否匹配此查询子句?”答案是一个简单的是或否——不计算得分。 过滤器上下文主要用于过滤结构化数据,例如:
此 timestamp 是否在2015年至2016年的范围内? status 字段是否设置为 "published"
-
单个查询条件 0. match_all / match_none -> match_all 查询简单的 匹配所有文档。在没有指定查询方式时,它是默认的查询
-
match -> 匹配查询(match) 用于执行全文查询的标准查询,包括模糊匹配和词组或邻近程度的查询。
- match -> {"query":{"bool":{"must":[{"match":{"age":20}},{"match":{"age":30}}]}}}
-
短语匹配查询(match_phrase) 与匹配查询类似,但是是用于更加精确的匹配相似的词组或单词。
-
短语前缀匹配查询(match_phrase_prefix) 这是一种弱类型的查询,类似短语匹配查询,但是它对最终要查询的单词的前缀进行模糊匹配的查询
-
多字段查询(multi_match) 可以用来对多个字段的版本进行匹配查询
-
常用术语查询(common) 可以对一些比较专业的偏门词语进行的更加专业的查询
-
查询语句查询(query_string) 与lucene查询语句的语法结合的更加紧密的一种查询,允许你在一个查询语句中使用多个 特殊条件关键字(如:AND|OR|NOT )对多个字段进行查询,当然这种查询仅限专家用户去使用。
-
简单查询语句(simple_query_string) 是一种适合直接暴露给用户的简单的且具有非常完善的查询语法的查询语句
-
范围查询语句(range) gt大于、gte大于等于、lt小于、lte小于等于
-
精确匹配 (term / trems) term 查询对于输入的文本不 分析 ,所以它将给定的值进行精确查询。
-
是否存在查询 (exists / missing)
11.查询语句查询 (query_string ) 使用查询解析器为了解析其内容的查询。
- boost -> 我们可以通过指定 boost 来控制任何查询语句的相对的权重, boost 的默认值为 1 ,大于 1 会提升一个语句的相对权重。boost 参数被用来提升一个语句的相对权重( boost 值大于 1 )或降低相对权重( boost 值处于 0 到 1 之间),但是这种提升或降低并不是线性的,换句话说,如果一个 boost 值为 2 ,并不能获得两倍的评分 _score 。
-
{ "match": {
"content": {
"query": "Lucene",
"boost": 2
}
}
}
-
组合查询(将上面多个单查询组合起来)
- must 文档 必须 匹配这些条件才能被包含进来。
- must_not 文档 必须不 匹配这些条件才能被包含进来。
- should 如果满足这些语句中的任意语句,将增加 _score ,否则,无任何影响。它们主要用于修正每个文档的相关性得分。
- filter 必须 匹配,但它以不评分、过滤模式来进行。这些语句对评分没有贡献,只是根据过滤标准来排除或包含文档。
-
复合查询(将上面多个组合查询 组合起来)
- bool 如:age=30并且gender=F
{
"query": {
"bool": {
"must": [
{
"match": {
"age": 30
}
},
{
"match": {
"gender": "F"
}
}
]
}
}
}
2. constant_score 查询
这是一个包装其他查询的查询,并且在过滤器上下文中执行。与此查询匹配的所有文件都需要返回相同的“常量” _score 。
3. dis_max 即分离 最大化查询(Disjunction Max Query)-> 分离(Disjunction)的意思是 或(or) ,这与可以把结合(conjunction)理解成 与(and) 相对应。分离最大化查询(Disjunction Max Query)指的是: 将任何与任一查询匹配的文档作为结果返回,但只将最佳匹配的评分作为查询的评分结果返回 :
4. Function_Score -> function_score 允许你修改一个查询检索文档的分数。
5. boosting 查询 -> 可以用来有效地降级能匹配给定查询的结果
- 上述基本都是针对整个词的操作,接下来是部分匹配
- Term Query(项查询) 查询包含在指定字段中指定的确切值的文档。
- Terms Query(多项查询) 查询包含任意一个在指定字段中指定的多个确切值的文档。
- Range Query(范围查询) 查询指定字段包含指定范围内的值(日期,数字或字符串)的文档。
- Exists Query(非空值查询) 查询指定的字段包含任何非空值的文档。
- Prefi Query(前缀查询) 查找指定字段包含以指定的精确前缀开头的值的文档。
- Wildcard Query(通配符查询) 查询指定字段包含与指定模式匹配的值的文档,其中该模式支持单字符通配符(?)和多字符通配符(),如:"wildcard" : { "user" : "kiy" }
- Regexp Query(正则表达式查询) 查询指定的字段包含与指定的正则表达式匹配的值的文档。如:"regexp":{"name.first":"s.*y"}
- Fuzzy Query(模糊查询) 查询指定字段包含与指定术语模糊相似的术语的文档。模糊性测量为1或2的 Levenshtein。
- Type Query(类型查询) 查询指定类型的文档。
- Ids Query(ID查询) 查询具有指定类型和 ID 的文档。
八、Mapping映射
映射索引myindex中的mytype类型,这个类型中有一个text类型的title属性和一个text类型的content属性。
(其他字段类型见文档)
PUT myindex
{
"mappings": {
"mytype": {
"properties": {
"title": {
"type": "text"
},
"content": {
"type": "text"
}
}
}
}
}
一个文档的被映射的字段类型有两种:元数据类型 和 属性(properties), 元数据类型是每个字段固有的,而属性是用来描述这个字段的,用法如下:
- 一、元数据类型(可以理解成每个类型都会有的字段!!!!):Meta-Fields,如
- _all
- _field_names(字段名)
- _id
- _index
- _meta
- _parent
- _routing
- _source
- _type
其中:
- _all 该字段允许您搜索文件中的值不知道哪个字段包含的值。这使其成为一个有用的选项时,开始使用一种新的数据集。但他需要消耗更多的资源,因此默认是禁用的。例如:
"query": {
"match": {
"_all": "john smith 1970"
}
}
- text 该字段用于索引全文文本,例如电子邮件的正文或产品的描述。 对这些字段进行analyzed ,即通过分析器将其转换成索引之前的各个术语列表。 分析过程允许Elasticsearch搜索每个全文本字段中的单个单词。 文本字段不用于排序,很少用于聚合(尽管重要的术语聚合是一个显着的例外)。如果您需要索引结构化内容(如电子邮件地址,主机名,状态代码或标签),则可能您应该使用keyword字段。 对于代码或标签,您也可能应该使用keyword字段。
- 二、字段(属性,也就是自定义的,可以指定类型和参数映射):Fields or properties。 默认情况下,每个字段都是被索引的(使用倒排索引),所有字段是默认被 indexed(被索引的),这使得它们是可搜索的.可以在脚本中排序,聚合和获取字段值,但是需要不同的搜索模式.
如
- analyzer(分析器)
- normalizer(归一化)
- boost(提升权重)
- Coerce(强制类型转换)
- copy_to(合并参数)
- doc_values(文档值)-> 默认开启,Doc values 是在 document 索引时间内构建在磁盘上的数据结构,这使得上面所说的数据访问模式成为可能.它们存储与 _source 相同的值,但是以列为主的方式存储.这使得排序和聚合效率更高。默认情况下,支持 doc values 的所有字段都是开启的.如果你确定不需要在字段上进行排序和聚合,活从脚本中访问字段值,则可以禁用 doc values 来节省磁盘空间.
- dynamic(动态设置)-> 默认情况下,字段会动态的添加到 document 或者 document 的 inner objects(内部对象),只需要通过索引包含这个新字段的 document。
- enabled(开启字段)-> enabled 设置只可以应用于映射类型和 object 字段,导致 Elasticsearch 完全跳过字段内容的解析.这个 JSON 仍然可以从 _source 字段中检索,但是不能以任何其他方式搜索或存储:
- fielddata(字段数据)-> 许多字段可以使用 index-time,在磁盘上的 doc_values 支持这种数据访问模式, 但是 text 字段不支持 doc_values。相反,text 字段使用查询时存在于内存的数据结构 fielddata.这个数据结构是第一次将字段用于聚合,排序,或者脚本时基于需求构建的。它是通过读取磁盘上的每个 segment(片段)的整个反向索引来构建的,将 term(词条)和 document(文档)关系反转,并将结果存储在内存中,在JVM的堆中.
- format (日期格式)
- ignore_above(忽略超越限制的字段)
- ignore_malformed(忽略格式不对的数据)
- include_in_all(是否在 _all 查询包含该字段)
- index_options(索引设置)
- index (是否建立索引,如果设置成false,则无法被搜索)
- fields(字段) -> 我们经常会因为不同的目的将同一个字段用不同的方式索引。这就相当于实现了 multi-fields。例如,一个 string 类型字段可以被映射成 text 字段作为 full-text 进行搜索,同时也可以作为 keyword 字段用于排序和聚合:
- Norms (标准信息)
- null_value(空值)
- position_increment_gap(短语位置间隙)
- properties (属性)
- search_analyzer (搜索分析器)
- similarity (匹配方法)
- store(存储)-> 默认情况下,字段值会被索引使他们能搜索,但他们不会被 stored(存储)。意思就是这个字段能查询,但不能取回他的原始值。
- Term_vectors(词根信息)
fielddata 和 doc_value的比较
4.1 相同点
都要创建正排索引,数据结构类似于列式存储
都是为了可以聚合,排序之类的操作
4.2 不同点
存储索引数据的方式不一样:
fielddata: 内存存储;doc_values: OS Cache+磁盘存储
对应的字段类型不一样
fielddata: 对应的字段类型是text; doc_values:对应的字段类型是keyword
针对的类型,也不一样
field_data主要针对的是分词字段;doc_values针对大是不分词字段
是否开启
fielddata默认不开启;doc_values默认是开启
fields(字段) 我们经常会因为不同的目的将同一个字段用不同的方式索引。这就相当于实现了 multi-fields。例如,一个 string 类型字段可以被映射成 text 字段作为 full-text 进行搜索,同时也可以作为 keyword 字段用于排序和聚合:
"lastname": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword", --> 因为fieldfata默认是关闭的,所以直接对这个字段聚合会报错,所以使用.keyword就可以进行聚合了!!!
"ignore_above": 256
}
}
}
举例!!!!:
GET /bank/account/_search
{
"query": {
"bool": {
"must": [
{
"prefix": {
"firstname": "m"
}
}
]
}
},
"aggs":{
"gender":{
"terms":{
"field":"gender.keyword"
},
"aggs":{
"avg_age":{
"avg":{
"field":"age"
}
}
}
}
}
}
结果:
"aggregations": {
"gender": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "F",
"doc_count": 59,
"avg_age": {
"value": 30.93220338983051
}
},
{
"key": "M",
"doc_count": 52,
"avg_age": {
"value": 30.23076923076923
}
}
]
}
}
- 三、Dynamic Mapping(动态映射)
九、管理、监控、部署
十、词汇表
-
analysis(分析) Analysis(分析)是将 full text(全文)转化为 terms(词条)的过程。使用不同的 analyzer(分词器), FOO BAR,Foo-Bar,foo,bar 这些短语可能都会生成 foo 和 bar 两个词条,实际的 index(索引)里面存储的就是这些 terms(词条)。针对 FoO:bAR 的 full text query(全文检索),会先将其分析成为 foo,bar 这样的词条,然后匹配存储在 index(索引)中的 term(词条)。正是这个 analysis(分析)的过程(发生在索引和搜索时)使得 elasticsearch 能够执行 full text queries(全文检索)。也可以参阅 text(文本)和 term(词条)了解更多细节信息。
-
term (词条) term(词条)是elasticsearch中被索引的确切值。foo, Foo, FOO 这些term(词条)不相等。term(词条)可以通过词条搜索来检索。查询text(文本)和anaylsis(分词)获取更多信息。
-
text (文本) text(文本)(或者说全文)是普通的非结构化文本,如一个段落。默认情况下,text(文本)会被analyzed(分词)成term(词条),term(词条)是实际存储在索引中的内容。文本的field(属性)必须在索引时完成analyzed(分词)来支持全文检索的功能,全文检索使用的关键词也必须在搜索时analyzed(分词)成索引时产生的相同term(词条)。查询term(词条)和analysis(分词)获取更多信息。
-
cluster (集群) cluster(集群)是由拥有同一个集群名的一个或者多个节点组成。每个集群拥有一个主节点,它由集群自行选举出来,在当前主节点挂了,能被其他节点取代。
-
index (索引) index(索引)类似于关系型数据库中的表。它有一个mapping(映射)来定义索引中的fields(属性),这些属性被分组成多种type(类型)。索引是一个逻辑命名空间,它对应一到多个primary shards(主分片)和零到多个replica shards(副本分片)。
-
document (文档) document(文档)是存储在elasticsearch中的json文档。类似于关系型数据库中的一行记录。每个文档存储在一个index(索引)中,它具有一个type(类型)和一个id。文档是包含零到多个fields(属性)或者键值对的json对象(类似于其他语言中的hash/hashmap/associative array)。当一个文档被indexed(索引)的时候,它的原始json文档会被存储成_source属性,对该文档进行get或者search操作时,默认返回的就是改属性。
-
term (词条) term(词条)是elasticsearch中被索引的确切值。foo, Foo, FOO 这些term(词条)不相等。term(词条)可以通过词条搜索来检索。查询text(文本)和anaylsis(分词)获取更多信息。
-
text (文本) text(文本)(或者说全文)是普通的非结构化文本,如一个段落。默认情况下,text(文本)会被analyzed(分词)成term(词条),term(词条)是实际存储在索引中的内容。文本的field(属性)必须在索引时完成analyzed(分词)来支持全文检索的功能,全文检索使用的关键词也必须在搜索时analyzed(分词)成索引时产生的相同term(词条)。查询term(词条)和analysis(分词)获取更多信息。
-
type (类型) type(类型)代表文档的类型,如一封邮件,一个用户,一条推文。搜索API可以通过文档类型来过滤。index(索引)可以包涵多个类型,每一个type(类型)有一系列的fields(属性)。同一个index(索引)中不同type(类型)的同名fields(属性)必须使用相同的mapping(映射)(定义文档的属性如何索引以及是文档能被搜索)。
-
id 文档的ID标识一个文档。文档的index/type/id必须唯一。如果没有提供ID,elasticsearch会自动生成一个ID。(查询routing(路由)获取更多信息)
-
field(属性) 一个文档包涵一系列的属性或者键值对。它的值可以是简单标量值(如字符串,整型数,日期),或者是像数组和对象一样的嵌套结构。属性类似于关系型数据库中的列。每个属性的mapping(映射)都有其类型(不同于document(文档)的type(类型)),表明该属性能存储成改类型的数据,例如 integer, string, object。mapping(映射)也允许你定义属性的值是否需要analyzed(分词)。
-
mapping (映射) mapping(映射)类似于关系型数据库中的元数据定义。每一个index(索引)对应一个mapping(映射),它定义了index(索引)中的每一个type(类型),另外还有一些索引级别的设置。mapping(映射)可以显式定义,或者当一个文档进行索引时自动生成。
-
node (节点) node(节点)是从属于一个elasticsearch集群的正在运行的节点。当以测试为目的时,可以在一台主机上启动多个节点,但是通常一台主机最好运行一个节点。在启动时,节点会使用广播的方式,自动感知(网络中)具有相同集群名的集群,并尝试加入它。
-
primary shard (主分片) 每个文档存储在单primary shard (主分片)中。当索引一个文档时,它会首先被索引到主分片上,然后索引到主分片的所有副本上。默认情况下,一个index(索引)有5个primary shard (主分片)。根据index(索引)的处理能力,你可以指定更少或者更多的primary shard (主分片)来扩展文档数量。当index(索引)创建之后,primary shard (主分片)的数量不可更改。查询routing(路由)获取更多信息。
-
replica shard (副本分片) 每一个primary shard (主分片)拥有零到多个副本。副本是primary shard (主分片)的拷贝,它的存在有两个目的:
- 增加容错:当主分片失败时,一个replica shard(副本分片)可以提升为primary shard (主分片)
- 提升性能:primary shard (主分片)和replica shard(副本分片)都能处理get和shearch请求。默认情况下,每个primary shard (主分片)有一个副本,副本的个数可以动态的修改。replica shard(副本分片)不会和primary shard (主分片)分配在同一个节点上。
-
routing (路由) 当你索引一个文档时,它会被存储在一个单独的主分片上。通过对routing值进行哈希计算来决定具体是哪一个主分片。默认情况下,routing值是来自于文档ID,如果文档指定了一个父文档,则通过其父文档ID(保证父子文档存储在同一个分片上)。如果你不想使用默认的文档ID来作为routing值,你可以在索引时直接指定一个routing值,或者在mapping中指定一个字段的值来作为routing值。
-
shard (分片) 一个Shard就是一个Lucene实例,是一个完整的搜索引擎。一个索引可以只包含一个Shard,只是一般情况下会用多个分片,可以拆分索引到不同的节点上,分担索引压力。 shard(分片)是一个Lucene实例。它是由elasticsearch管理的低层次的工作单元。index(索引)是指向 主分片和副本分片的逻辑命名空间。除了定义index(索引)应该具有的primary shard(主分片)和replica shard(副本分片)的数量之外,你不需要对shard(分片)作其它的工作。相反,你的代码应该只处理index(索引)。elasticsearch将shards(分片)分配到整个集群的所有节点上,当节点失败时可以自动将分片迁移到其他节点或者新增的节点上。
-
segment elasticsearch中的每个分片包含多个segment,每一个segment都是一个倒排索引;在查询的时,会把所有的segment查询结果汇总归并后最为最终的分片查询结果返回; 在创建索引的时候,elasticsearch会把文档信息写到内存bugffer中(为了安全,也一起写到translog),定时(可配置)把数据写到segment缓存小文件中,然后刷新查询,使刚写入的segment可查。 虽然写入的segment可查询,但是还没有持久化到磁盘上。因此,还是会存在丢失的可能性的。 所以,elasticsearch会执行flush操作,把segment持久化到磁盘上并清除translog的数据(因为这个时候,数据已经写到磁盘上,不在需要了)。 当索引数据不断增长时,对应的segment也会不断的增多,查询性能可能就会下降。因此,Elasticsearch会触发segment合并的线程,把很多小的segment合并成更大的segment,然后删除小的segment。 segment是不可变的,当我们更新一个文档时,会把老的数据打上已删除的标记,然后写一条新的文档。在执行flush操作的时候,才会把已删除的记录物理删除掉。
-
source field (源属性) 在默认情况下,你索引的json document(文档)会存储在_source field(属性)中,get和search请求会返回该field(属性)。这样可以直接在搜索结果中获取原始文档对象,不需要通过ID再检索一次文档对象。
截止目前的搜索相对都很简单:单个姓名,通过年龄过滤。现在尝试下稍微高级点儿的全文搜索——一项 传统数据库确实很难搞定的任务。
搜索下所有喜欢攀岩(rock climbing)的雇员:
GET /megacorp/employee/_search
{
"query" : {
"match" : {
"about" : "rock climbing"
}
}
}
拷贝为 CURL在 SENSE 中查看 显然我们依旧使用之前的 match 查询在about 属性上搜索 “rock climbing” 。得到两个匹配的文档:
{
...
"hits": {
"total": 2,
"max_score": 0.16273327,
"hits": [
{
...
"_score": 0.16273327,
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
},
{
...
"_score": 0.016878016,
"_source": {
"first_name": "Jane",
"last_name": "Smith",
"age": 32,
"about": "I like to collect rock albums",
"interests": [ "music" ]
}
}
]
}
}
相关性得分 - _score
Elasticsearch 默认按照相关性得分排序,即每个文档跟查询的匹配程度。第一个最高得分的结果很明显:John Smith 的 about 属性清楚地写着 “rock climbing” 。
但为什么 Jane Smith 也作为结果返回了呢?原因是她的 about 属性里提到了 “rock” 。因为只有 “rock” 而没有 “climbing” ,所以她的相关性得分低于 John 的。
这是一个很好的案例,阐明了 Elasticsearch 如何 在 全文属性上搜索并返回相关性最强的结果。Elasticsearch中的 相关性 概念非常重要,也是完全区别于传统关系型数据库的一个概念,数据库中的一条记录要么匹配要么不匹配。
短语搜索编辑 - match_phrase
找出一个属性中的独立单词是没有问题的,但有时候想要精确匹配一系列单词或者短语 。 比如, 我们想执行这样一个查询,仅匹配同时包含 “rock” 和 “climbing” ,并且 二者以短语 “rock climbing” 的形式紧挨着的雇员记录。
为此对 match 查询稍作调整,使用一个叫做 match_phrase 的查询:
GET /megacorp/employee/_search
{
"query" : {
"match_phrase" : {
"about" : "rock climbing"
}
}
}
拷贝为 CURL在 SENSE 中查看 毫无悬念,返回结果仅有 John Smith 的文档。
{
...
"hits": {
"total": 1,
"max_score": 0.23013961,
"hits": [
{
...
"_score": 0.23013961,
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
}
]
}
}
3.5 REST request body方法查询
curl -XGET 'localhost:9200/bank/_search?pretty' -d'
{
"query": {
"bool": {
"must": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
过滤:
{
"query": {
"bool": {
"must": { "match_all": {} },
"filter": {
"range": {
"balance": {
"gte": 20000,
"lte": 30000
}
聚合:
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword"
}
}
-
setup es 暂时跳过,某些生产上的设置至关重要
-
API 规范
5.1 Multiple Indices(多个索引)
/g*,u*/_search 在任何以 g 或者 u 开头的索引中搜索所有的类型
5.2 Date math support in index names(索引名称对 Date 和 Math 的支持)
Date math 索引名称解析可以让您搜索一系列 time-series indices(时间序列索引),而不是搜索所有时间序列索引并过滤结果或维护 aliases(别名)。限制搜索的索引数量减少了集群上的负载,并提高了执行性能。例如,如果您在日常日志中 searching for errors(搜索错误 ),则可以使用 date math name 模板将搜索限制为过去两天。
-
document api
-
search api
-
aggregation api 聚合api
-
index api 索引api
-
cat api
-
cluster api
-
查询 DSL Elasticsearch提供了一个基于JSON的完整的查询DSL来定义查询。将查询DSL视为查询的AST,由两种类型的子句组成:
叶查询子句
叶查询子句在特定查询中查找特定值,例如匹配、项值、范围查询。这些查询都可以给自己使用。
复合查询子句
复合查询子句包装其他叶子或复合查询,用于以逻辑方式组合多个查询(例如bool或dis_max查询),或更改其行为(如constant_score查询)。
查询子句的行为有所不同,具体取决于它们是在查询上下文还是过滤器上下文中使用。
- mapping 映射