elasticSearch笔记（一）

1，每次返回结果的时候，要报告哪些分片成功了，如果有不成功的分片返回，需要报警；
2，写入数据的时候要批量写入，数据大小在3-15M之间，这个文档的条数需要自己去试验；
3，_all字段是可以被停用的，可以定义自己的_all字段；
4，filter(转换)-》tokenizer（分词）->filter tokenizer（词型转换）
5，分词器
1）标准分词器（默认，根据unicode定义的词边界分词）
6，查询分类
1）确切查询：不分词，也可以指定分词器
2）全文查询：分词，执行查询
7，要求数量：默认主分片在尝试写入时需要规定数量(quorum)或过半的分片（可以是主节点或复制节点）可用。这是防止数据被写入到错的网络分区。
int quorum = int( (primary + number_of_replicas) / 2 ) + 1
consistency允许的值为one（只有一个主分片），all（所有主分片和复制分片）或者默认的quorum或过半分片
注意number_of_replicas是在索引中的的设置，用来定义复制分片的数量，而不是现在活动的复制节点的数量
8，验证分词器的效果：GET /_analyze?analyzer=standard&text=Text to analyze
9，查找分片算法：shard = hash(routing) % number_of_primary_shards，routing是可以自行指定的一个字段；
10，对于string字段，两个最重要的映射参数是index和analyer。
11，你可以向已有映射中增加字段，但你不能修改它。如果一个字段在映射中已经存在，这可能意味着那个字段的数据已经被索引。
如果你改变了字段映射，那已经被索引的数据将错误并且不能被正确的搜索到。
12，查询分为合并多子句查询，结构化查询，DSL
13，查询，过滤
过滤
一条过滤语句会询问每个文档的字段值是否包含着特定值：
created 的日期范围是否在 2013 到 2014 ?
status 字段中是否包含单词 “published” ?
lat_lon 字段中的地理位置与目标点相距是否不超过10km ?

使用过滤语句得到的结果集 – 一个简单的文档列表，快速匹配运算并存入内存是十分方便的， 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句要比 过滤语句更耗时，并且查询结果也不可缓存。

原则上来说，使用查询语句做全文本搜索或其他需要进行相关性评分的时候；

注意能用过滤的不用查询；

14，过滤
term,terms,range,exists,missing:null,bool,
must:and ,
must_not:not,
should:or
15，结果集默认按相关性排序，相关的在前
1）计算_score比较耗时，可以指定一个排序字段，这样默认不会计算score，可以提高查询速度；
2）对于数字和日期，你可以从多个值中取出一个来进行排序，你可以使用min, max, avg 或 sum这些模式。 比说你可以在 dates 字段中用最早的日期来进行排序：
这样可以在聚合前，提前做一些条件过滤；
3)使用raw字段,not_analyzed字段进行排序
4) 对 analyzed 字段进行强制排序会消耗大量内存
5）倒排索引在用于搜索时是非常卓越的，但却不是理想的排序结构，会将所有排序字段加载到内存，内存不够使用集群控制，横向扩展
16，文档的唯一性由_index, _type和routing-value（通常默认是该文档的_id）的组合来确定。这意味着我们可以准确知道集群中的哪个分片持有这个文档。
17，搜索的执行过程分两个阶段，称为查询然后取回（query then fetch）。
性能：
1）计算_score比较耗时，可以指定一个排序字段，这样默认不会计算score，可以提高查询速度，或者强制不计算score来加快查询速度；
4) 对 analyzed 字段进行强制排序会消耗大量内存
5）查询使用filter比查询快
18，避免结果振荡
方法就是使用一个随机字符串例如用户的会话ID（session ID）来设置preference参数。
19,scan and scroll,一些Elasticsearch官方客户端提供扫描和滚屏的小助手。小助手提供了一个对这个功能的简单封装。

20,分片之所以重要，主要有两方面的原因：
允许你水平分割/扩展你的内容容量
允许你在分片（位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量
21,建议在同一个索引的每一个类型中，确保用同样的方式映射同名的字段,不同解析的字段名称不同；
22，自行指定的ID字段虽然用起来很方面，但是在bulk请求的时候对性能有影响，处理请求的节点将不能仅靠解析元数据行来决定将请求分配给哪一个分片，而需要解析整个文档主体。
23，为了更高效的索引旧索引中的文档，使用【scan-scoll】来批量读取旧索引的文档，然后将通过【bulk API】来将它们推送给新的索引。
24，你可以检测这个别名指向哪个索引：
GET /*/_alias/my_index
显示所有索引
GET /_cat/indices?v
25，指定索引别名
PUT /my_index_v1/_alias/my_index
26，迁移
POST /_aliases
{
“actions”: [
{ “remove”: { “index”: “my_index_v1”, “alias”: “my_index” }},
{ “add”: { “index”: “my_index_v2”, “alias”: “my_index” }}
]
}
27，分片每30分钟，或事务日志过大会进行一次flush操作。
28，如果写入日志完毕最好手动flush一次，这样确保都写入磁盘，在实时应用时，不需要手动，但是实时需要重启机器，重启前需要手动flush一下，这样重启的速度加快；
29，通过设置这个字段为 not_analyzed 来告诉 Elasticsearch 它包含一个准确值。
30，结构化查询
term,terms,tag_count,range
31，叶子过滤器会被缓存，而组合过滤器不会被缓存；
32，匹配查询match
高级查询，支持全文及精确检索
33，在索引级别通过mapping指定不同的分析器，而不是在节点上指定，因为在节点上指定分析器会导致必须重启节点，在服务器的维护上是不允许这样做的；
34，同阶子句权重相同；
35，对于多词，多字段查询并没有一种万能(one-size-fits-all)的方法。要得到最佳的结果，你需要了解你的数据以及如何使用恰当的工具。
1）最佳字段(Best fields)：文档在相同的字段中应该有尽可能多的单词；
dis_max查询，匹配最佳字段
{
“query”: {
“dis_max”: {
“queries”: [
{ “match”: { “title”: “Quick pets” }},
{ “match”: { “body”: “Quick pets” }}
]
}
}
}
最佳字段查询调优，由于dis_max只匹配最佳字段，加入tie_breaker以后，就计算全部字段的匹配结果了。
{
“query”: {
“dis_max”: {
“queries”: [
{ “match”: { “title”: “Quick pets” }},
{ “match”: { “body”: “Quick pets” }}
],
“tie_breaker”: 0.3
}
}
}
2）多数字段(Most fields)：越多的字段被匹配则意味着文档的相关度越高。
3）跨字段(Cross fields):对于一些实体，标识信息会在多个字段中出现，每个字段中只含有一部分信息
例如：Book: title, author, 和 description，
36，多重匹配查询
1）
{
“dis_max”: {
“queries”: [
{
“match”: {
“title”: {
“query”: “Quick brown fox”,
“minimum_should_match”: “30%”
}
}
},
{
“match”: {
“body”: {
“query”: “Quick brown fox”,
“minimum_should_match”: “30%”
}
}
},
],
“tie_breaker”: 0.3
}
}
这种适用于设置不同的minimum_should_match，如果这个值相同，可以改成以下的查询：
{
“multi_match”: {
“query”: “Quick brown fox”,
“type”: “best_fields”, <1>
“fields”: [ “title”, “body” ],
“tie_breaker”: 0.3,
“minimum_should_match”: “30%” <2>
}
}
2）通配符
{
“multi_match”: {
“query”: “Quick brown fox”,
“fields”: “*_title”
}
}
37，召回率(Recall) - 返回所有相关的文档，准确率(Precision) - 不返回无关文档

提高性能的方法：
1)可否只查询或返回指定的字段，然后根据字段的ID逐条取出符合条件的记录，这样是不是就很快了？
2)如果你确实需要从集群里获取大量documents，你可以通过设置搜索类型scan禁用排序，来高效地做这件事。这一点将在后面的章节讨论。
导出的数据，不需要排序，导出后再由用户自己进行排序就可以了。
那么当前的要求是导出全部数据，那么不分页就很快了，使用scan-and-scroll进行查询；
3）自行指定的ID字段虽然用起来很方面，但是在bulk请求的时候对性能有影响，处理请求的节点将不能仅靠解析元数据行来决定将请求分配给哪一个分片，而需要解析整个文档主体。
关键是实时的要求，写入及查询的速度都要快，才能支持实时分析；
4）你可以通过修改配置项refresh_interval减少刷新的频率，这样可以提高性能，让其近实时搜索就可以，延时在3-5分钟就可以了；
你在创建大索引的时候可以关闭自动刷新，在要使用索引的时候再打开它。指的是批量任务，对于实时任务，必须一直打开；
5)不要在动态的索引（正在活跃更新）上使用optimize API。后台的合并处理已经做的很好了，优化命令会阻碍它的工作。不要干涉！
6)为了在字符串上执行范围操作，Elasticsearch 会在这个范围内的每个短语执行 term 操作。这比日期或数字的范围操作慢得多。+
字符串范围适用于一个基数较小的字段，一个唯一短语个数较少的字段。你的唯一短语数越多，搜索就越慢。
7）在 bool 条件中过滤器的顺序对性能有很大的影响。更详细的过滤条件应该被放置在其他过滤器之前，以便在更早的排除更多的文档。
{ “range” : {
“timestamp” : {
“gt” : “now-1h/d” <1>
}
}}
为了缩小范围，需要把限制范围的过滤器放在前面执行。
8）精确查询时，使用过滤器会提高查询性能；

按天查询的过滤器被缓存，而按天以下的时间单位不会被缓存；
mapping定义
{
“mappings”: {
“post”: {
“properties”: {
“id”: {“type”:”long”, “store”:”yes”, “precision_step”:”8” },
“name”: {“type”:”string”, “store”:”yes”, “index”:”analyzed” },
“published”: {“type”:”date”, “store”:”yes”, “precision_step”:”8” },
“contents”: {“type”:”string”, “store”:”no”, “index”:”analyzed” }
}
}
}
}

PUT /stock_index
{
“settings”: {
“number_of_shards” : 1,
“number_of_replicas” : 0
},

"mappings": {
    "yahoo": {
        "dynamic":      "strict", 
        "properties": {
            "id":  { "type": "long","index":"not_analyzed"},
            "stockDate":  { "type": "date","format":"yyyy-MM-dd","index":"not_analyzed"},
            "open": { "type": "float","index":"not_analyzed"},
            "low": { "type": "float","index":"not_analyzed"},
            "high": { "type": "float","index":"not_analyzed"},
            "close": { "type": "float","index":"not_analyzed"},
            "volume": { "type": "float","index":"not_analyzed"},
            "adjClose": { "type": "float","index":"not_analyzed"}
        }   
    }
}

}

更新mapping
curl -XPOST ‘192.168.99.100:9200/library/book/_mapping’ -d’
{
“book”: {
“properties”: {
“description”: {
“type”: “string”,
“store”: “yes”,
“index”: “analyzed”
}
}
}
}