概述
这本书写的一版本。和官方手册差不多=。=,没意思
#搜索数据
##查询 ###partial_fields 可以指定返回哪些字段
###script_fields 执行脚本产生对应的值
###搜索类型
####query_and_fetch 最快最简单的搜索类型,查询语句在所有分片上执行,并且所有分片返回结果的规模为size参数的取值。所以,这种类型搜索返回文档数码最大为size参数的取值与分片数目的乘积
####query_then_fetch 查询语句首先得到文档排序所需的信息,然后得到要获取的文档内容的相关分片,与query_and_fetch不同,它返回文档数目最大为size参数的取值
####dfs_query_and_fetch 和query_and_fetch类似,在初始节点顺带还做了分布式的词频来更好的返回得分
####dfs_query_then_fetch 和query_then_fetch类似,在初始节点顺带还做了分布式的词频来更好的返回得分
####count 只返回匹配的文档数目
####scan 发送了一个请求之后,ES回一个_scroll_id,剩余的查询都在_search/scroll处运行 #扩展结构与搜索
ES的Mapping是动态映射的也可以通过将dynamic属性设置为false或者把index.mapper.dynamic设置为false关掉
##ES的一些字段
###_source _source字段存储了原始JSON文档,由于_source字段会引入额外的存储开销,所以我们可以选择亚索存储该字段的信息。可以把compress参数指定为true,还可以通过comptrss_threashold属性控制_source字段在多大的时候进行压缩
###_size 这个字段是默认禁用的,用来自动索引_source字段原始的,未经过压缩的大小
###_timestamp 默认是禁用并且不存储的,存储文档何时被索引
###_ttl 默认也是禁用了,用来指定一个文档的生命周期,在此之后会被自动删除
##高亮
ES的高亮是基于Lucence的,Lucence有2种高亮实现的方式,一种是标准实现,一种是FastVectorHighlighter,如果term_vector属性设置为with_positions_offsets,就会使用第二种。第二种索引的会变大,不过高亮速度会变快。
高亮的标签可以通过设置pre_tags
和post_tags
来设置
通过number_of_fragments
可以控制高亮片段数量,默认是5。fragment_size
可以用来指定高亮片段的最大字符长度,默认是100
假如需要仅显示高亮的字段,那么可以把require_field_match
设置为true
##自动补全
##prefix查询
curl -XGET 127.0.0.1:9200/_search?pretty -d '{"query":{"prefix":{"source":"e"}}}'
这种做法不科学
##edgeNGram
思想是把单词拆分为更小的部分,在索引进去的时候采用engram
token,然后直接查就好
##统计 用统计的方法给出自动补全数据源(呃。。这么看来ES并没给一个特别方便的方法嘛)
#搜索优化
##理解字段分析过程
一个常见的问题是为什么搜不到指定的文档,一般都是因为分词器配置造成的,可以通过查询接口来查看
curl -XGET 127.0.0.1:9200/_analyze?pretty -d 'This is a demo'
这个API还可以加上tokenizer的参数来设置分词器
curl -XGET '127.0.0.1:9200/_analyze?tokenizer=whitespace&filters=lowercase&pretty' -d 'This is a demo'
测试的时候挺有用的
##解释查询
可以解释为什么能查到对应的数据
curl -XGET '127.0.0.1:9200/graylog_0/message/6d1db5d0-c35c-11e6-a58c-b612b16053c2/_explain?pretty&q=index'
##用加权影响得分
主要是用于调整查询结果的权重,例如我们可以在查询语句里面调整字段的权重
{
"query":{
"query_string":{
"fields":["from^4","to^2"],
"query":"a",
"use_dis_max":false
}
}
}
constant_score
查询,可以让我们显示的为查询匹配的文档设置打分值 boosting
查询可以让我们降低匹配结果的打分值
##什么时候索引加权有意义
- 在输入数据中定义字段加权
- 在输入数据中对文档加权
- 在映射中定义加权
##同义词
ES可以对同义词进行处理,利用synonym
过滤器
##使用跨度查询
ES支持5种跨度查询:
- span_term
- span_first:只运行返回在字段的前几个位置上匹配的文档
- span_near:例如查a词项附近有b词的文档
- span_or:获取a字段前n个位置含有c或者离b字段不超过一个位置含有c的文档
- span_not:这种查询有include和exclude的部分
从性能角度来看,跨度查询的代价是比较高的,不仅要对词项进行匹配,还要对位置信息进行计算和检查
#组合索引、分析和搜索
##索引树型结构
ES能够存储树型结构的索引。叫做path_analyzer
,详细的使用方法可以看这里https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-pathhierarchy-tokenizer.html
##利用更新API修改索引结构
修改索引有几个要注意的地方:
- 不可以将not_analyzed改成analyzed
- 不可以改变字段的类型
- 不能将stored to field 改成not stored
- 不能更改被索引属性的取值
- 不能修改一个已经索引的文档分析器
一定要做的话,使用ignore_conflicts参数来用新的Schema覆盖原来的
##使用嵌套对象
嵌套对象比较常处理一对多的问题,在日志处理中看来是没什么机会用的了,商品还是可以的。使用的是variation
对象,要留意的是不用这个对象,索引进去的数据会搜索不到的。另外,这货连查询都要用专门的文档
##使用父子关系
嵌套文档可以以单独的文档形式分开索引,不过我们不能对任何一个嵌套文档进行修改,除非用更新的API。ES也提供了真正的父子关系的结构,子索引使用parent
的方式把他们联系起来。
可以使用has_child来查询对哪种文档的子文档进行查询,用top_child可以返回父文档。在子文档里面就可以用has_parent来反查
##父子关系对性能的影响
- 为了让查询能正常进行,父子文档需要放在一个分片里面,那么很容易会出现分片不均匀导致的性能波动的情况,而且父子查询本来就慢些
- 假如用了has_child这样的查询,ES是需要预加载文档的,留意内存,不然就OOM了
- 为了提升性能,可以合理使用预热的API
##从其他系统获取数据:river
各种river插件,从其他数据源同步到ES,不过映像中好像不怎么推荐了的样子?(我记错了?)
#批量索引以加快索引进程
ES可以把多个数据合成一个数据包,最大大小在ES里面可以配置的,默认是100M。另外Bulk可以一次塞很多数据进去外,还可以同事做CUD的操作哦。假如要更快的话,可以用UDP送,不过有可能会丢哦
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk-udp.html
UDP的API,1.4之后已经被干掉了
#搜索之外
##相似的文档
ES提供了More like this 的功能,其实是对Lucence的封装而已,需要的时候可以看看
##反查器
ES有一个叫做percolator的功能,它是用查询作为文档,可以实现类似:在这个商店中可以购买到符合标准的产品时通知我的功能。具体的去Java笔记里面看
绕了一圈看明白了,反查器就是把查询存进去,然后put一下文档进去,假如符合条件就会返回对应的查询ID信息。怪不得说可以拿来做告警的功能。不过功能不是特别强大呢,聚合类的貌似不行【没验证过,不过看例子不行】
#集群管理
##检查集群的健康状态
curl 127.0.0.1:9200/_cluster/health?pretty
还可以根据索引来检查状态,也可以等待直到状态为某种状态才返回,使用wait_for_status
、wait_for_nodes
这样的参数
##检查索引的状态
curl 127.0.0.1:9200/graylog_0/_stats?pretty
##检查节点的信息
curl "127.0.0.1:9200/_nodes?&pretty"
##检查集群状态信息
curl "127.0.0.1:9200/_cluster/state?&pretty"
##检查索引分段
curl "127.0.0.1:9200/_segments?&pretty"
##几个比较有用的插件
- BigDesk:节点信息统计情况插件,好像没维护了
- Head:没什么好说的
- paramedic:一定时间内服务器的统计信息工具
./bin/plugin install karmi/elasticsearch-paramedic
##防止脑裂
为了防止集群中的脑裂问题,discovery.zen.minimun_master_nodes需要设置为总节点的一半以上
#问题处理
##为什么查询靠后面页数的结果会比较慢
首先,不断翻页对搜索来说是有问题的,不过假如一定要这样做的话,用from,size来取数据并且是带排序的话,慢也正常,因为得把数据取出来排序完后再进行分页,这种情况下,使用scroll会是个比较不错的选择。这样的话就可以要求ES在一定的时间内缓存数据,不用每次都重头取。
curl '127.0.0.1:9200/_search?pretty&scroll=5m' //用滚动取
curl '127.0.0.1:9200/_search?pretty&scroll=5m&scroll_id=xxxx' //第二次带着滚动ID上
##控制集群再平衡
再平衡,是控制集群各个节点移动分片的过程
ES允许我们控制的内容:
- 再平衡的开始时间
- 节点间同时移动的分片个数
- 单个节点上同时进行初始化的分片个数
- 单个节点上同时进行初始化的主分片个数
- 禁止分片和副本分配
- 禁止副本分配
##验证查询
ES提供了语法校验的功能,把查询发到_validate/query就可以校验语法了
##预热
ES允许预先加载一些查询,使得查询的时候可以更快一些,预热查询和普通查询类似,只是它是放在一个特殊的_warmer索引上面。可以通过_warmer/yourtag
注册一个预热查询。预热查询可以定义在索引上,也可以定义在类型上
转载于:https://my.oschina.net/xiaomaijiang/blog/825672
最后
以上就是高高航空为你收集整理的ElasticSearch可扩展的开源弹性搜索解决方案的全部内容,希望文章能够帮你解决ElasticSearch可扩展的开源弹性搜索解决方案所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复