ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式的全文搜索引擎,其对外服务是基于RESTful web接口发布的。Elasticsearch是用Java开发的应用,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到近实时搜索,稳定,可靠,快速,安装使用方便。

  cluster集群。ElasticSearch集群由一或多个节点组成,其中有一个主节点,这个主节点是可以通过选举产生的,主从节点是对于集群内部来说的。ElasticSearch的一个概念就是去中心化,字面上理解就是无中心节点,这是对于集群外部来说的,因为从外部看ElasticSearch集群,在逻辑上是个整体,你与集群中的任何一个节点通信和与整个ElasticSearch集群通信是等价的。也就是说,主节点的存在不会产生单点安全隐患、并发访问瓶颈等问题。

  primary shard:代表索引的主分片,ElasticSearch可以把一个完整的索引分成多个primary shard,这样的好处是可以把一个大的索引拆分成多个分片,分布存储在不同的ElasticSearch节点上,从而形成分布式存储,并为搜索访问提供分布式服务,提高并发处理能力primary shard的数量只能在索引创建时指定并且索引创建后不能再更改primary shard数量(重新分片需要重新定义分片规则)。es5.x之后默认为5,es7.x默认为1。

  replica shard:代表索引主分片的副本,ElasticSearch可以设置多个replica shard。replica shard的作用:一是提高系统的容错性,当某个节点某个primary shard损坏或丢失时可以从副本中恢复。二是提高ElasticSearch的查询效率,ElasticSearch会自动对搜索请求进行负载均衡,将并发的搜索请求发送给合适的节点,增强并发处理能力。可取值为0~n,默认为1。

  索引。相当于关系型数据库中的表。其中存储若干相似结构的Document数据。如:客户索引,订单索引,商品索引等。ElasticSearch中的索引不像数据库表格一样有强制的数据结构约束,在理论上,可以存储任意结构的数据。但了为更好的为业务提供搜索数据支撑,还是要设计合适的索引体系来存储不同的数据。

  类型。每个索引中都必须有唯一的一个Type,Type是Index中的一个逻辑分类。ElasticSearch中的数据Document是存储在索引下的Type中的。

  注意:ElasticSearch5.x及更低版本中,一个Index中可以有多个Type。ElasticSearch6.x版本之后,type概念被弱化,一个index中只能有唯一的一个type。且在7.x版本之后,删除type定义。

  文档。ElasticSearch中的最小数据单元。一个Document就是一条数据,一般使用JSON数据结构表示。每个Index下的Type中都可以存储多个Document。一个Document中可定义多个field,field就是数据字段。如:学生数据({“name”:”张三”, “age”:20, “gender”:”男”})。

  对数据进行分析,抽取出数据中的词条,以词条作为key,对应数据的存储位置作为value,实现索引的存储。这种索引称为倒排索引。倒排索引是Document写入ElasticSearch时分析维护的

  

 3,比数据库做搜索的优势

  • 数据库查询复杂度高。比如:like ‘%关键字%’不能命中索引,搜索复杂度高
  • 数据库关键字的搜索不全面,搜索结果不符合要求。比如:搜索商品为’笔记本电脑’,不能搜索到只有’笔记本’或者只有’电脑’的数据
  • 数据库搜索的效率问题。数据量越大,查询效率越低。

  GET _cat/health?v

  

  其中status的状态分为三种:green、yellow和red

  • green:每个索引的primary shard和replica shard都是active的
  • yellow:每个索引的primary shard都是active的,但部分的replica shard不是active的。比如:当前只有两个node结点,需要创建大于等于两个repica shard副分片,由于主分片和副分片均不能在同一个结点上,所有必定有副分片不能正常的active。
  • red:不是所有的索引的primary shard都是active状态的。
  1. #查看健康状态
  2. GET _cat/health?v
  3. #查看节点信息
  4. GET _cat/nodes?v
  5. #查看索引信息
  6. GET _cat/indices?v
  7. #查看分片信息
  8. GET _cat/shards?v
  1. #创建my_index索引(settings可以省略),创建后shards分片数不能修改,只能修改shards副本数
  2. PUT my_index
  3. {
  4. "settings": {
  5. "number_of_shards": 5,
  6. "number_of_replicas": 1
  7. }
  8. }

  在ElasticSearch中,默认的创建索引的时候,会分配5个primary shard,并为每个primary shard分配一个replica shard(在ES7版本后,默认创建1个primary shard)。在ElasticSearch中,默认的限制是:如果磁盘空间不足15%的时候,不分配replica shard。如果磁盘空间不足5%的时候,不再分配任何的primary shard。ElasticSearch中对shard的分布是有要求的。ElasticSearch尽可能保证primary shard平均分布在多个节点上。Replica shard会保证不和他备份的那个primary shard分配在同一个节点上

  1. #修改索引
  2. PUT my_index/_settings
  3. {
  4. "number_of_replicas": 2
  5. }

  注意:索引一旦创建,primary shard数量不可变化,可以改变replica shard数量。

  1. DELETE my_index

  GET _cat/indices?v

  

  在索引中增加文档。在index中增加document。

  ElasticSearch有自动识别机制。如果增加的document对应的index不存在,自动创建index;如果index存在,type不存在,则自动创建type。如果index和type都存在,则使用现有的index和type。

  PUT  索引名/类型名/唯一ID{字段名:字段值}

  1. #如果当前id已经存在,那么就是修改,如果不存在就是新增
    PUT my_index/_doc/1
  2. {
  3. "name":"test_doc_01",
  4. "remark":"first test elastic search",
  5. "order_no":1
  6. }

  

  如果当前索引中的document的id已经存在,那么就是修改,如果不存在就是新增。但是如果此时id已经存在,想要强制新增会报错,强制新增的语法为:

  PUT 索引名/类型名/唯一ID/_create{字段名:字段值}   或者是  PUT 索引名/类型名/唯一ID?op_type=create{字段名:字段值}

  此操作为ElasticSearch自动生成id的新增Document方式。此语法格式和PUT请求的数据新增,只有唯一的区别,就是可以自动生成主键id,其他的和PUT请求新增数据完全一致。

  POST 索引名/类型名[/唯一ID]{字段名:字段值}

  1. #此时,如果新增时唯一id(2)不存在就是新增,如果唯一id(2)存在就是修改。这个与PUT相同
    #可以直接变为没有id,会随机生成一个GUID作为id
    POST my_index/_doc
  2. {
  3. "name":"test_doc_02",
  4. "remark":"second test elastic search",
  5. "order_no":2
  6. }

  GET 索引名/类型名/唯一ID

  1. GET my_index/_doc/1

  批量查询可以提高查询效率。推荐使用(相对于单数据查询来说)。

  1. #语法
  2. GET 索引名/类型名/_mget
  3. {
  4. "docs" : [
  5. {
  6. "_id" : "唯一ID值"
  7. },
  8. {
  9. "_id" : "唯一ID值"
  10. }
  11. ]
  12. }

  PUT|POST 索引名/类型名/唯一ID{字段名:字段值}

  本操作相当于覆盖操作。全量替换的过程中,ElasticSearch不会真的修改Document中的数据,而是标记ElasticSearch中原有的Document为deleted状态,再创建一个新的Document来存储数据,当ElasticSearch中的数据量过大时,ElasticSearch后台回收deleted状态的Document。

  1. PUT my_index/_doc/1
  2. {
  3. "name":"test_doc_01111",
  4. "remark":"first 111",
  5. "order_no":1111
  6. }

  POST 索引名/类型名/唯一ID/_update{doc:{字段名:字段值}}

  只更新某Document中的部分字段。这种更新方式也是标记原有数据为deleted状态,创建一个新的Document数据,将新的字段未更新的原有字段组成这个新的Document,并创建。对比全量替换而言,只是操作上的方便,在底层执行上几乎没有区别。

  1. POST my_index/_doc/1/_update
  2. {
  3. "doc":{
  4. "name":" test_doc_01_for_update"
  5. }
  6. }

  DELETE 索引名/类型名/唯一ID

  ElasticSearch中执行删除操作时,ElasticSearch先标记Document为deleted状态,而不是直接物理删除。当ElasticSearch存储空间不足或工作空闲时,才会执行物理删除操作。标记为deleted状态的数据不会被查询搜索到。

  1. DELETE my_index/_doc/2

定义:

  1. POST _bulk
  2. { "action_type" : { "metadata_name" : "metadata_value" } }
  3. { document datas | action datas }
  4. action_type
  5. create: 强制创建,相当于PUT 索引名/类型名/唯一ID/_create
  6. index : 普通的PUT操作,相当于创建Document或全量替换
  7. update: 更新操作(partial update),相当于 POST 索引名/类型名/唯一ID/_update
  8. delete: 删除操作

案例:

  1. #如果index和type为同一个可以提出来,此时创建ID为111,覆盖ID为1,修改ID为2,删除ID为3
  2. POST my_index/_doc/_bulk
  3. {"create":{"_id":111}}
  4. {"name":"zs","age":15}
  5. {"index":{"_id":1}}
  6. {"name":"first","sort":1}
  7. {"update":{"_id":2}}
  8. {"doc":{"sort":2}}
  9. {"delete":{"_id":3}}

  注意bulk语法中要求一个完整的json串不能有换行不同的json串必须使用换行分隔。多个操作中,如果有错误情况,不会影响到其他的操作,只会在批量操作返回结果中标记失败。bulk语法批量操作时,bulk request会一次性加载到内存中,如果请求数据量太大性能反而下降(内存压力过高),需要反复尝试一个最佳的bulk request size。一般从1000~5000条数据开始尝试,逐渐增加。如果查看bulk request size的话,一般是5~15MB之间为好。

  bulk语法要求json格式是为了对内存的方便管理,和尽可能降低内存的压力。如果json格式没有特殊的限制,ElasticSearch在解释bulk请求时,需要对任意格式的json进行解释处理,需要对bulk请求数据做json对象会json array对象的转化,那么内存的占用量至少翻倍,当请求量过大的时候,对内存的压力会直线上升,且需要jvm gc进程对垃圾数据做频繁回收,影响ElasticSearch效率。

  生成环境中,bulk api常用。都是使用java代码实现循环操作。一般一次bulk请求,执行一种操作。如:批量新增10000条数据等

  Mapping在ElasticSearch中是非常重要的一个概念。决定了一个index中的field使用什么数据格式存储,使用什么分词器解析,是否有子字段等。

 

 

  • 文本(字符串):text
  • 整数:byte、short、integer、long
  • 浮点型:float、double
  • 布尔类型:boolean
  • 日期类型:date
  • 数组类型:array  {a:[]}
  • 对象类型:object  {a:{}}
  • 不分词的字符串(关键字): keyword
  • true or false -> boolean
  • 123 -> long
  • 123.123 -> double
  • 2018-01-01 -> date
  • hello world -> text
  • [] -> array
  • {} -> object

  在上述的自动mapping字段类型分配的时候,只有text类型的字段需要分词器。默认分词器是standard分词器。

  GET 索引名/_mapping 

  1. {
  2. "my_index": { # 索引名
  3. "mappings": { # 映射列表
  4. "my_type": { # 类型名
  5. "properties": { # 字段列表
  6. "age": { # 字段名
  7. "type": "long" # 字段类型
  8. },
  9. "gender": { #字段名
  10. "type": "text", #字段类型
  11. "fields": { # 子字段列表
  12. "keyword": { # 子字段名
  13. "type": "keyword", # 子字段类型,keyword不进行分词处理的文本类型。gender.keyword可以进行排序
  14. "ignore_above": 256 # 子字段存储数据长度
  15. }
  16. }
  17. }
  18. }
  19. }
  20. }
  21. }
  22. }

  可以通过命令,在创建index和type的时候来定制mapping映射,也就是指定字段的类型和字段数据使用的分词器

  手工定制mapping时,只能新增mapping设置不能对已有的mapping进行修改

  如:有索引a,其中有类型b,增加字段f1的mapping定义。后续可以增加字段f2的mapping定义,但是不能修改f1字段的mapping定义。

 

  1. PUT 索引名称
  2. {
  3. "mappings":{
  4. "类型名称":{
  5. "properties":{
  6. "字段名":{
  7. "type":类型,
  8. ["analyer":字段的分词器,]
  9. ["fields":{
  10. "子字段名称":{
  11. "type":类型,
  12. "ignore_above":长度限制
  13. }
  14. }]
  15. }
  16. }
  17. }
  18. }
  19. }

 

例如:

  1. PUT test_index
  2. {
  3. "settings": {
  4. "number_of_shards": 2,
  5. "number_of_replicas": 1
  6. },
  7. "mappings": {
  8. "test_type":{
  9. "properties": {
  10. "author_id" : {
  11. "type": "byte",
  12. "index": false
  13. },
  14. "title" : {
  15. "type": "text",
  16. "analyzer": "ik_max_word",
  17. "fields": {
  18. "keyword" : {
  19. "type": "keyword",
  20. "ignore_above": 256
  21. }
  22. }
  23. },
  24. "content" : {
  25. "type": "text",
  26. "analyzer": "ik_max_word"
  27. },
  28. "post_date" : {
  29. "type": "date"
  30. }
  31. }
  32. }
  33. }
  34. }
  35. "index" - 是否可以作为搜索索引。可选值:true | false
  36. "analyzer" - 指定分词器。
  37. "type" - 指定字段类型
  1. PUT 索引名/_mapping/类型名
  2. {
  3. "properties":{
  4. "新字段名":{
  5. "type":类型,
  6. "analyer":字段的分词器,
  7. "fields":{
  8. "子字段名":{
  9. "type":类型,
  10. "ignore_above":长度
  11. }
  12. }
  13. }
  14. }

例如:

  1. PUT /test_index/_mapping/test_type
  2. {
  3. "properties" : {
  4. "new_field" : { "type" : "text" , "analyzer" : "standard" }
  5. }
  6. }
  1. GET 索引名称/_analyze
  2. {
  3. "field":"索引中的text类型的字段名",
  4. "text":"要分词处理的文本数据"
  5. }

例如:

  1. #测试content字段的分词效果
    GET test_index/_analyze
  2. {
  3. "field": "content",
  4. "text": "我是一个程序员"
  5. }

 

版权声明:本文为bbgs-xc原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/bbgs-xc/p/14334769.html