elasticsearch-权威指南笔记-基础部分

参考这里的文档es权威指南

话说这个坑爹的文档是2.x版本的es，英文版本也是，所以就没啥好抱怨的了。

官方教程中有很多坑

例如，需要启动text上的索引。

还有就是get这个是不能带json的，所以很多get的操作其实都是直接用post。

关于集群

• 所有节点都是平等的，除了主节点。
• 任何节点都可接受查询并且了解所有文档所处位置。
• 默认每个分片都有一个副本，而且分布在不同的节点上，保证数据安全。
• 一个索引有多个分片，这个似乎是为了提高性能。
• 主分片数目是固定的，创建索引的时候指定，但是副本可以是随时添加的

关于文档

• es中文档就是一个数据记录，json格式
• _index, _type, _id唯一确定了一个文档
• _id基本是不冲突的
• 直接使用head就能在不返回的情况下查询文档是否存在，这个其实可以有其他的实现方式吧。
• 更新之后，旧文档就无法访问了，蛋疼，还以为这个功能可以实现版本控制。
• 可以用PUT /website/blog/123?op_type=create或者PUT /website/blog/123/_create确保创建新文档而不是更新已有文档。
• delete操作其实是更新文档版本加标记文档为已删除，这么做是为了跨节点同步，最终文档会被删除。
• 关于版本控制
  • es使用版本号控制文档更新和并发
  • 内部版本一定是递增的
  • 可以用PUT /website/blog/1?version=1方式来指定对版本号1进行修改，如果版本号已变则操作失败，这样可以保证冲突的情况下，不会出现未知问题。
  • 所有文档的更新或删除 API，都可以接受 version 参数
  • 可以通过PUT /website/blog/2?version=5&version_type=external的方式来使用外部api。
  • 可以通过/website/blog/1/_update这种的方式进行文档的部分更新，这个过程内部实际上就是post一个新文档过去，只不过省了一些操作而已
  • update还有一种操作是可以用脚本，不过看上去都是一些比较简单的脚本，另外脚本默认是禁用的。
  • update的操作，必须是已经存在的文档，如果不存在会出现错误。
• 获取多个文档，可以通过GET /_mget进行，而且灵活性比较大，可以在index下或者type下进行mget，参数是比较灵活的，而且某个文档没有不妨碍其他文档被检索到。
• bulkapi的处理有点蛋疼，它是给一个操作，指定相应的文档，然后给操作的body，一行行来的，python的api中，也遵循这个结构。
• 路由分片，也就是用hash%shards的方式，计算文档属于哪个分片，挺常用的技巧。
• 一个修改操作，将会由任何持有主分片的节点执行，但是结果会被同步转发到所有的分片副本节点，结果全部完成后才会发给客户端。
• 一个查询操作，任何主分片或者副本分片都可以响应，而且为了更大的性能，这个查询还会被负载均衡一下。
• update的请求转发，不是只转发操作，而是转发整个文档。看来es的内部通信还是挺大的流量的。
• mget内部会被分解为多个操作，由多个节点执行完后，由被访问节点构建最终的回复。
• bulk奇怪的结构是因为，这样的结构可以一边读取操作的数据，一边转发所有的操作到对应的分片节点，效率比较高。

查询

• well， for search

• 似乎6.x开始就不能在一个index下用多个type了，7.x直接没有type了，这个倒是简洁了，不过还是有点蛋疼。

• 搜索的结果还是很多信息的，不过都是json的，挺好理解。

• 搜索的url可以用来组合多个index和type，还能用通配符。

• 跟mongo差不多的skip方式GET /_search?size=5&from=10

• 简单查询使用url参数，以get方式进行

• 有一个默认的_all字段，等于是一个对整个文档的组合，默认在这上面查询。

• es里面有精确查询和全文查询的区别，对于文本是全文查询的，而日期之类有精确查询的功能。

• 倒排索引，蛋疼。。。

• 分析分析要索引的文档以及查询的关键词，其中包含分词器。分词器有默认的，但是我们要的是自己定义的。有些分析器支持拼音检索，或者首字母检索。

• 虽然说，get的查询方式带body是被es支持的，但是真心不推荐用，因为很多时候都不好用。

• 查询语句，貌似其本质跟mongo的真没啥太大的区别，就是形式上不太一样而已：

  {
      "bool": {
          "must":     { "match": { "tweet": "elasticsearch" }},
          "must_not": { "match": { "name":  "mary" }},
          "should":   { "match": { "tweet": "full text" }},
          "filter":   { "range": { "age" : { "gt" : 30 }} }
      }
  }

• 查询分为查询与过滤，查询是给结果进行排序的，而且比较慢，过滤则是直接给出结果，所以比较快。

• 几种基本查询：

  • { "match_all": {}}
    

  • { "match": { "age":    26           }}
    { "match": { "date":   "2014-09-01" }}
    { "match": { "public": true         }}
    { "match": { "tag":    "full_text"  }}
    

  • {
        "multi_match": {
            "query":    "full text search",
            "fields":   [ "title", "body" ]
        }
    }
    

  • {
        "range": {
            "age": {
                "gte":  20,
                "lt":   30
            }
        }
    }
    

  • { "term": { "age":    26           }}
    { "term": { "date":   "2014-09-01" }}
    { "term": { "public": true         }}
    { "term": { "tag":    "full_text"  }}
    这个只适用于精确查询，也就是字符串不会被解析。
    

  • { "terms": { "tag": [ "search", "full_text", "nosql" ] }}
    

  • {
        "exists":   {
            "field":    "title"
        }
    }
    只要有就返回，不解析内容
    missing被删掉了，所以需要用bool和must_not来进行组合，蛋疼
    

• 可以用bool来组合多查询

  • must 文档 必须 匹配这些条件才能被包含进来。
  • must_not文档 必须不 匹配这些条件才能被包含进来。
  • should 如果满足这些语句中的任意语句，将增加 _score ，否则，无任何影响。它们主要用于修正每个文档的相关性得分。
  • filter 必须 匹配，但它以不评分、过滤模式来进行。这些语句对评分没有贡献，只是根据过滤标准来排除或包含文档。这个不会被评分，很快而且内部有优化。

• 一个很复杂的查询。
  {
      "bool": {
          "must":     { "match": { "title": "how to make millions" }},
          "must_not": { "match": { "tag":   "spam" }},
          "should": [
              { "match": { "tag": "starred" }}
          ],
          "filter": {
            "bool": {
                "must": [
                    { "range": { "date": { "gte": "2014-01-01" }}},
                    { "range": { "price": { "lte": 29.99 }}}
                ],
                "must_not": [
                    { "term": { "category": "ebooks" }}
                ]
            }
          }
      }
  }
  

• 不评分的查询，很快，而且也很常用。

• {
      "constant_score":   {
          "filter": {
              "term": { "category": "ebooks" }
          }
      }
  }
  

• 排序就是应用了sort关键字，但是需要注意，排序之后，不再计算score

  • GET /_search
    {
        "query" : {
            "bool" : {
                "filter" : { "term" : { "user_id" : 1 }}
            }
        },
        "sort": { "date": { "order": "desc" }}
    }
    

• Elasticsearch 的相似度算法 被定义为检索词频率/反向文档频率， TF/IDF ，包括以下内容

  • 检索词频率
        检索词在该字段出现的频率？出现频率越高，相关性也越高。 字段中出现过 5 次要比只出现过 1 次的相关性高。
    
    反向文档频率
        每个检索词在索引中出现的频率？频率越高，相关性越低。检索词出现在多数文档中会比出现在少数文档中的权重更低。
    
    字段长度准则
        字段的长度是多少？长度越长，相关性越低。 检索词出现在一个短的 title 要比同样的词出现在一个长的 content 字段权重更大。
    

索引管理

• 直接put数据就可以创建索引，但是这时候的索引是默认的，可能不具备很多特性

• 主分片，创建好了就不能修改了，副本可以随时扩增，甚至可以为0。

• 分析器的配置，看一个自定义的例子

  PUT /my_index
  {
      "settings": {
          "analysis": {
              "char_filter": {
                  "&_to_and": {
                      "type":       "mapping",
                      "mappings": [ "&=> and "]
              }},
              "filter": {
                  "my_stopwords": {
                      "type":       "stop",
                      "stopwords": [ "the", "a" ]
              }},
              "analyzer": {
                  "my_analyzer": {
                      "type":         "custom",
                      "char_filter":  [ "html_strip", "&_to_and" ],
                      "tokenizer":    "standard",
                      "filter":       [ "lowercase", "my_stopwords" ]
              }}
  }}}

• 目前已经不允许在同一个索引中创建两个以上的type，7.x会直接移除type

• _source作为一个保存原始文档的手段，是可以被禁用的，这个觉得有点奇怪。

• dynamic可以被关掉，而且可以针对每一个field单独开关。

• 动态映射模板，用于默认的行为不符合我们的要求的情况下，似乎平时不太能用到，如果系统规划做的很合适的话：

  PUT /my_index
  {
      "mappings": {
          "my_type": {
              "dynamic_templates": [
                  { "es": {
                        "match":              "*_es",
                        "match_mapping_type": "string",
                        "mapping": {
                            "type":           "string",
                            "analyzer":       "spanish"
                        }
                  }},
                  { "en": {
                        "match":              "*",
                        "match_mapping_type": "string",
                        "mapping": {
                            "type":           "string",
                            "analyzer":       "english"
                        }
                  }}
              ]
  }}}

• 一般来说，需要事先规划好索引的mapping等，但是计划总没有变化快，偶尔还是需要对索引进行设置变更，但是既存的是无法修改设置的，所以要么重建一个，复制数据，要么就用alias建一个索引别名。alias通常更快。

  • 感觉alias其实就是在同一份数据上，进行了不同的倒排表的创建。

  • 步骤，有点奇怪这些json的文档描述是怎么定义的

    • 用新的设置创建新的索引

    • 创建alias

    • PUT /my_index_v2
      {
          "mappings": {
              "my_type": {
                  "properties": {
                      "tags": {
                          "type":   "string",
                          "index":  "not_analyzed"
                      }
                  }
              }
          }
      }
      
      POST /_aliases
      {
          "actions": [
              { "remove": { "index": "my_index_v1", "alias": "my_index" }},
              { "add":    { "index": "my_index_v2", "alias": "my_index" }}
          ]
      }
      

吐槽，难怪es引入版本和各种文档更新的手段，es内部的数据是写完了就不改的，新追加的数据不会导致以前的索引重建，而是直接新建一块索引，并将原来的索引加入新建的索引块，所以es中的文档可以认为都是只读的。因而查询效率比较高，但是也引入了很多的问题。

最终，所有新建的索引都会被合并优化。这是后台低优先级执行的，所以不要指望每天有大量数据写入的情况下还能很好的合并优化，除非机器资源很足。

es的文档索引并不是实时的，有个1S的间隔，但是这个一般足够长了，如果不够的话，可以手动刷新，用

POST /_refresh
POST /blogs/_refresh

另外刷新的频率是可以i设置的

PUT /my_logs
{
  "settings": {
    "refresh_interval": "30s"
  }
}

映射

• 映射就是为了让es知道某个文档应该怎么去分析。
• 核心简单域类型
  • 字符串: text
  • 整数 : byte, short, integer, long
  • 浮点数: float, double
  • 布尔型: boolean
  • 日期: date
• 6.x以后，就已经没有string了，都是text类型
• 空值不会被索引
• 话说，多层次的（nested）object会被扁平化处理，这个是内部的处理，不需要外部知道。

关于URL

url中的一些特殊字段都是有特殊含义的，例如_search, _mapping之类的。