• elasticsearch6 学习之基础CURD


    环境:elasticsearch6.1.2        kibana6.1.2 

    基础概念:

    1、_index元数据

    (1)代表一个document存放在哪个index中
    (2)类似的数据放在一个索引,非类似的数据放不同索引:product index(包含了所有的商品),sales index(包含了所有的商品销售数据),inventory index(包含了所有库存相关的数据)。如果你把比如product,sales,human resource(employee),全都放在一个大的index里面,比如说company index,不合适的。
    (3)index中包含了很多类似的document:类似是什么意思,其实指的就是说,这些document的fields很大一部分是相同的,你说你放了3个document,每个document的fields都完全不一样,这就不是类似了,就不太适合放到一个index里面去了。
    (4)索引名称必须是小写的,不能用下划线开头,不能包含逗号。

    2、_type元数据

    (1)代表document属于index中的哪个类别(type)
    (2)一个索引通常会划分为多个type,逻辑上对index中有些许不同的几类数据进行分类:因为一批相同的数据,可能有很多相同的fields,但是还是可能会有一些轻微的不同,可能会有少数fields是不一样的,举个例子,就比如说,商品,可能划分为电子商品,生鲜商品,日化商品,等等。
    (3)type名称可以是大写或者小写,但是同时不能用下划线开头,不能包含逗号

    3、_id元数据

    (1)代表document的唯一标识,与index和type一起,可以唯一标识和定位一个document
    (2)我们可以手动指定document的id(put /index/type/id),也可以不指定,由es自动为我们创建一个id

    一、插入

      数据准备(插入):es会自动建立index和type,不需要提前创建,而且es默认会对document每个field都建立倒排索引,让其可以被搜索。

    PUT /ecommerce/product/1
    {
        "name" : "gaolujie yagao",
        "desc" :  "gaoxiao meibai",
        "price" :  30,
        "producer" :      "gaolujie producer",
        "tags": [ "meibai", "fangzhu" ]
    }
    PUT /ecommerce/product/2
    {
        "name" : "jiajieshi yagao",
        "desc" :  "youxiao fangzhu",
        "price" :  25,
        "producer" :      "jiajieshi producer",
        "tags": [ "fangzhu" ]
    }
    
    PUT /ecommerce/product/3
    {
        "name" : "zhonghua yagao",
        "desc" :  "caoben zhiwu",
        "price" :  40,
        "producer" :      "zhonghua producer",
        "tags": [ "qingxin" ]
    }

    插入数据时的id生成策略

      手动指定document id当es的数据来源于其他系统,比如mysql而这些数据都有主键ID,建议使用该方式,可以直接将mysql的主键作为es中的ID。

      自动生成的id当我们的数据是直接存储到es中时,建议采用该方式。该方式的特点,长度为20个字符,URL安全,base64编码,GUID,分布式系统并行生成时不可能会发生冲突

    POST /test_index/test_type
    {
      "test_content": "my test"
    }
    结果: {
    "_index": "test_index", "_type": "test_type", "_id": "fkSoJ2EBuYE9HLKhxglD", "_version": 1, "result": "created", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "_seq_no": 0, "_primary_term": 1 }

    二、修改

    1、document的全量替换型修改:该方式是直接替换类型是 product  id=1的文档。该方式必须带上所有的field,才能去进行信息的修改。

    PUT /ecommerce/product/1
    {
        "name" : "jiaqiangban gaolujie yagao",
        "desc" :  "gaoxiao meibai",
        "price" :  30,
        "producer" :      "gaolujie producer",
        "tags": [ "meibai", "fangzhu" ]
    }

    注意:

    1、document的全量替换

    (1)语法与创建文档是一样的,如果document id不存在,那么就是创建;如果document id已经存在,那么就是全量替换操作,替换document的json串内容
    (2)document是不可变的,如果要修改document的内容,第一种方式就是全量替换,直接对document重新建立索引,替换里面所有的内容
    (3)es会将老的document标记为deleted,然后新增我们给定的一个document,当我们创建越来越多的document的时候,es会在适当的时机在后台启动线程删除标记为deleted的document,释放空间。

    2、partial update  指定修改内容修改(推荐该方式)

    POST /ecommerce/product/1/_update
    {
      "doc": {
        "name": "jiaqiangban gaolujie yagao"
      }
    }

      该方式发生的步骤与全量替换基本一样,不过该方式将这些流程放在es内部,这样减少了放了请求,减少并发冲突发的概率。他同样会生成两份document,老的document标记为deleted,partial update 修改的数据更新到新的document中

    retry_on_conflict(重策略)当执行索引和更新的时候,有可能另一个进程正在执行更新。这个时候就会造成冲突,这个参数就是用于定义当遇到冲突时,再过多长时间执行操作,通过retry_on_conflict参数设置重试次数来自动完成,这样update操作将会在发生错误前重试——这个值默认为0。

    例如:

    POST /test_index/test_type/1/_update?retry_on_conflict=5
    {
      "doc": {
        "test_name": "update book re",
        "test_id":11122
      }
    }

    三、删除 

      根据类型的Id直接删除

    DELETE /ecommerce/product/1

      注意 不是物理删除,只会将其标记为deleted,当数据越来越多的时候,在后台启动线程自动删除,释放空间

    四、查询

    (一)、query string search

        什么是query string search:search参数都是以http请求的query string来附带的

    语法:

    /_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 类型
    
    当在单一的索引下进行搜索的时候,Elasticsearch 转发请求到索引的每个分片中,可以是主分片也可以是副本分片,然后从每个分片中收集结果。多索引搜索恰好也是用相同的方式工作的--只是会涉及到更多的分片。

    demo:

    1、搜索全部商品:

    GET /ecommerce/product/_search
    {
      
    }

    结果分析:

    took:耗费了几毫秒
    timed_out:是否超时,这里是没有
    _shards:数据拆成了5个分片,所以对于搜索请求,会打到所有的primary shard(或者是它的某个replica shard也可以)
    hits.total:查询结果的数量,3个document
    hits.max_score:score的含义,就是document对于一个search的相关度的匹配分数,越相关,就越匹配,分数也高
    hits.hits:包含了匹配搜索的document的详细数据

    2、搜索商品名称中包含yagao的商品,并按照价格倒序:

    GET /ecommerce/product/_search?q=name:yagao&sort=price:desc
    {
      
    }

    (二)、query DSL

    DSL:Domain Specified Language,特定领域的语言
    http request body:请求体,可以用json的格式来构建查询语法,比较方便,可以构建各种复杂的语法。

    1、分页查询所有商品并按照价格倒序

    GET /ecommerce/product/_search
    {
      "query": { "match_all": {} },
      "sort": [
            { "price": "desc" }
        ],
      "from": 0,
      "size": 3
    }

    query:包装查询条件

    sort:包装排序条件

    form:第几页

    size:每页几条

    2、根据名称查询,并按照价格倒序

    GET /ecommerce/product/_search
    {
      "query": { "match": {
                  "name":"yagao"
              } 
      },
      "sort": [
            { "price": "desc" }
        ]
    }

    3、指定返回结果的列(field)

    GET /ecommerce/product/_search
    {
      "query": { "match_all": {} },
      "_source": ["name", "price"]
    }

    _source元数据:就是说,我们在创建一个document的时候,使用的那个放在request body中的json串,默认情况下,在get的时候,会原封不动的给我们返回回来。我们可以指定_source中,返回哪些field。

    在分布式系统中深度分页
        理解为什么深度分页是有问题的,我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页(结果从 1 到 10 ),每一个分片产生前 10 的结果,并且返回给 协调节点 ,协调节点对 50 个结果排序得到全部结果的前 10 个。
        现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
        可以看到,在分布式系统中,对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。

    (三)、query filter

    1、搜索商品名称包含yagao,而且售价大于25元的商品

    GET /ecommerce/product/_search
    {
        "query" : {
            "bool" : {
                "must" : {
                    "match" : {
                        "name" : "yagao" 
                    }
                },
                "filter" : {
                    "range" : {
                        "price" : { "gt" : 25 } 
                    }
                }
            }
        }
    }

    (四)full-text search (全文检索)

    全文检索会将输入的搜索串拆解开来,去倒排索引里面去一一匹配,只要能匹配上任意一个拆解后的单词,就可以作为结果返回。

    1、根据一段文字进行查找

    GET /ecommerce/product/_search
    {
        "query" : {
            "match" : {
                "producer" : "yagao producer"
            }
        }
    }

    producer这个字段,会先被拆解,建立倒排索引。根据es中这个字段的所有数据分词后有 jiajieshi、gaolujie、zhonghua、producer

    查询条件producer 也会被分词  ,分词为 yagao 和 producer

    结果分析: "max_score": 0.2876821 匹配度

    (五)、phrase search (短语查找)

    输入的搜索串,必须在指定的字段文本中,完全包含一模一样的,才可以算匹配,作为结果返回。

    GET /ecommerce/product/_search
    {
        "query" : {
            "match_phrase" : {
                "producer" : "yagao producer"
            }
        }
    }

    结果为空

    (六)、highlight search (高亮搜索结果)

    GET /ecommerce/product/_search
    {
        "query" : {
            "match" : {
                "producer" : "producer"
            }
        },
        "highlight": {
            "fields" : {
                "producer" : {}
            }
        }
    }
  • 相关阅读:
    史上最详细 github 使用教程(英文烂的血泪史)
    如何解决跨域问题
    KSImageNamed 安装
    VVDocumenter插件安装
    通过appearance设置app主题
    UITableViewCell注册情况
    iOS9.2 xcode 7.1.1真机测试
    UIAlertController iOS9
    Values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead
    GIT
  • 原文地址:https://www.cnblogs.com/jalja/p/8337169.html
Copyright © 2020-2023  润新知