ElasticSearch 知识点整理

时间：2021-11-11 08:42:07

1：es介绍

         Elasticsearch是一个基于Lucene的实时的分布式搜索和分析引擎。设计用于云计算中，          能够达到实时搜索，稳定，可靠，快速，安装使用方便。基于RESTful接口。          普通请求是...get?a=1          rest请求....get/a/1

2：全文搜索的工具有哪些

         Lucene Solr Elasticsearch        

3：es的bulk的引用场景

1.bulk API可以帮助我们同时执行多个请求 2.create和index的区别 如果数据存在，使用create操作失败，会提示文档已经存在，使用index则可以成功执行。 3.可以使用文件操作 使用文件的方式 vi requests curl  -XPOST/PUT localhost:9200/_bulk --data-binary @request; bulk请求可以在URL中声明/_index或者/_index/_type 4.bulk一次最大处理多少数据量
  • bulk会把将要处理的数据载入内存中，所以数据量是有限制的
  • 最佳的数据量不是一个确定的数值，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载
  • 一般建议是1000-5000个文档，如果你的文档很大，可以适当减少队列,大小建议是5-15MB，默认不能超过100M，
  • 可以在es的配置文件中修改这个值http.max_content_length: 100mb
5.版本控制的一个问题
  • 在读数据与写数据之间如果有其他线程进行写操作，就会出问题，es使用版本控制才避免这种问题。
  • 在修改数据的时候指定版本号，操作一次版本号加1。

6.es的两个web访问工具
  • BigDesk Plugin (作者 Lukáš Vlček)          简介：监控es状态的插件,推荐！主要提供的是节点的实时状态监控，包括jvm的情况，linux的情况，elasticsearch的情况
  • Elasticsearch Head Plugin (作者 Ben Birch) 简介：很方便对es进行各种操作的客户端。        
        

4：核心概念

集群cluster*** 代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。         es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体， 你与任何一个节点的通信和与整个es集群通信是等价的。        主节点的职责是负责管理集群状态，包括管理分片的状态和副本的状态，以及节点的发现和删除。        只需要在同一个网段之内启动多个es节点，就可以自动组成一个集群。         默认情况下es会自动发现同一网段内的节点，自动组成集群。 分片shards*        代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。         可以在创建索引库的时候指定           curl -XPUT 'localhost:9200/test1/' -d'{"settings":{"number_of_shards":3}}'          默认是一个索引库有5个分片          index.number_of_shards: 5 副本   replicas*          代表索引副本，es可以给索引设置副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。           二是提高es的查询效率，es会自动对搜索请求进行负载均衡。           可以在创建索引库的时候指定，副本数后期可以更改。           curl -XPUT 'localhost:9200/test2/' -d'{"settings":{"number_of_replicas":2}}'            默认是一个分片有1个副本            index.number_of_replicas: 1   数据重新分布recovery * 代表数据恢复或叫数据重新分布，es在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。
数据的持久化操作gateway* 代表es索引的持久化存储方式，es默认是先把索引存放到内存中，当内存满了时再持久化到硬盘。 当这个es集群关闭再重新启动时就会从gateway中读取索引数据。es支持多种类型的gateway，有本地文件系统（默认），分布式文件系统，Hadoop的HDFS和amazon的s3云存储服务。
自动发现机制discovery.zen* 代表es的自动发现节点机制，es是一个基于p2p的系统，它先通过广播寻找存在的节点，再通过多播协议来进行节点之间的通信，同时也支持点对点的交互。
集群或节点与客户端交互的方式Transport* 代表es内部节点或集群与客户端的交互方式，默认内部是使用tcp协议进行交互，同时它支持http协议（json格式）、thrift、servlet、memcached、zeroMQ等的传输协议（通过插件方式集成）。          index        和rdbms中的数据库相似          type         表          document        行          field          列

5：serachType

四种搜索类型，详细介绍                                          分布式搜索的流程
  1. 先把查询请求发送给集群的某一个节点
  2. 某个节点把最终的结果返回给客户端
QUERY_AND_FETCH 1：客户端把请求发送给集群中的某一个节点，这个节点会把查询请求发 送给所有分片去执行， 2：每个分片会把查询的数据(包含数据的分值,以及数据的详细内容)返回给某一个节点进行汇总，排序，然后把这些数据返回给客户端 这样客户端可能会收到(10*分片数量)的数据 这种方案，数据量和排名都有问题。 优点：效率高，查询速度快                                    
QUERY_THEN_FETCH（默认） 1：客户端把请求发送给集群中的某一个节点，这个节点会把查询请求发送给所有分片去执行， 2：每个分片会把查询的数据(包含数据的分值,以及数据ID)返回给某一个 节点进行汇总，排序，取前10名 3：根据前10名的id到对应的分片查询数据的详细内容，返回给客户端 这种方案，解决了数据量的问题。 但是排名还有有问题。
(DFS：初始化散发过程) DFS_QUERY_AND_FETCH 1：在查询之前，会把所有分片的词频和文档频率(打分依据)汇总到一块 2：客户端把请求发送给集群中的某一个节点，这个节点会把查询请求发送给所有分片去执行， 3：每个分片会把查询的数据(包含数据的分值,以及数据的详细内容)返回给某一个节点进行汇总，排序，然后把这些数据返回给客户端 解决了排名的问题 还存在数据量的问题                                
DFS_QUERY_THEN_FETCH 1：在查询之前，会把所有分片的词频和文档频率(打分依据)汇总到一块 2：客户端把请求发送给集群中的某一个节点，这个节点会把查询请求发送给所有分片去执行， 3：每个分片会把查询的数据(包含数据的分值,以及数据ID)返回给某一个节点进行汇总，排序，取前10名 4：根据前10名的id到对应的分片查询数据的详细内容，返回给客户端 既解决了排名问题，也解决了数据量的问题 但是性能最低 总结一下，从性能考虑QUERY_AND_FETCH是最快的，DFS_QUERY_THEN_FETCH是最慢的。从搜索的准确度来说，DFS要比非DFS的准确度更高。
高亮       补：高亮的注意事项： 高亮的内容和原始内容是分开返回的 高亮字段的内容必须在es中存储(是否存储这个属性的值必须是true) 分组：分组统计数量或者分组统计分数 删除索引库：两种方式xurl或者java api Timeout  ：


6：建立索引和查询的流程

建立索引的流程： 首先根据空白符进行分割再切分关键词，去除停用词，如果有英文全部转换为小写，对切分的关键词建立索引，每个关键词都有对应的id，还有一个倒排索引队列存储该关键词出现在文档的id，在该文档出现的次数，在该文档出现的位置 查询的流程： 首先根据空白符进行分割，再切分关键词，去除停用词，如果有英文全部转换为小写，将切分后的到的关键词和索引库进行匹配 中文分词器-IK es官方提供的分词插件对中文分词效果不是很好，可以集成ik分词，对中文分词效果比较好 如果想根据自己的规则进行分词，可以自定义分词库，自定义分词库文件必须以.dic结尾，词库文件的编码为utf—8 without bom，一个词语一行，将自定义的文件库加入到ES_HOME/config/ik/目录下，修改ik的配置文件，重启生效    

7：为什么使用索引工具查询快

(使用了倒排索引的技术，大致介绍一下倒排索引，还有索引库中的词都是按照顺序排列， 后期根据一个关键词查询的时候，可以利用类似折半查找的算法，查询效率非常高) 使用了倒排索引的技术，一般我们都是这样定义id 关键词，倒排索引是关键词  id正好相反，使用索引工具进行查询时，首先得到关键词，建立倒排索引表，关键词----索引列表包含该关键词所在的文档的id、在该文档中出现的次数、在该文档中出现的位置信息，这种由属性值确定记录的位置的方式成为倒排索引。还有索引库中的词都是按照顺序排列 ，后期根据一个关键词查询的时候， ElasticSearch 知识点整理
可以利用类似折半查找的算法，查询效率非常高 ElasticSearch 知识点整理

8.setting与mapping作用

settings修改索引库默认配置 ElasticSearch 知识点整理 例如：分片数量，副本数量 查看：curl -XGET http://localhost:9200/crxy/_settings?pretty (操作不存在索引) curl -XPUT 'localhost:9200/crxy/' -d'{"settings":"number_of_shards":3,"number_of_replicas":2}}' (操作已存在索引) curl -XPUT 'localhost:9200/crxy/_settings' -d'{"index":{"number_of_replicas":2}}' Mapping,动态mapping机制：这个机制会自定识别参数值的类型，自动给这个参数设置属性 好处：操作方便，不需要提前考虑这个字段是否在es中定义过。 弊端：针对一个未知的数据，本来不应该存储的，这样也会存储了，对数据基本没有什么可控性 在实际开发中，如果数据类型已知，建议还是关闭自动mapping。 如果数据类型未知，只能使用自定mapping机制  

9：分片查询方式：

es中默认的分片查询方式为随机从分片中取数据，其他的分片查询方式还有如：
  • _local:查询操作首先在本地查找，如果本地没有再到其他节点进行查找
  • _primary:只在主分片中查询
  • _shads:按照指定的分片进行查询，这种查询方式实现了es的极速查询
（在存储数据的时候通过rooting参数可以指定将数据分配到某一个分片中，rooting参数值相同的分配到一个分片中，后期查询时可以根据rooting参数值指定到哪个分片中查找，从而实现了极速查询） 修改源码自定义从多个节点进行查询等    

10：es集群的脑裂问题

                   es集群有可能会出现脑裂问题，原因主要有两个：                    1）如果集群中节点不在同一个网段有可能是网络延迟造成的                    2）如果集群中的节点在同一个网段，有可能是主节点负载太大造成的                   解决方案主要有两种：                    1） 把主从节点的职责分离,设置三个储备主节点，        node.master=true,node.data=false                            从节点只存储数据，node.master=false,node.data=true                    2)增加延迟时间                   将储备主节点数最小设为n/2+1个              

11：优化

  1. 适当调大系统打开的最大打开文件数，默认为1024
  2. 修改配置文件调整es的jvm内存的大小，根据服务器内存的大小，一般分配60%左右，默认是256M
  3. 分片的数量最好设置为5-20个（es中一个分片最多存20G的数据，分片数在创建索引库时就指定，而且创建后不能修改，分片数最少设置为：数据量/20G个，如果所有分片都存满数据，需要再重新建立索引库）分片设置的过多过少都会导致检索比较慢，分片数过多会导致检索时打开比较多的文件，
  4. 也会导致多台服务器之间的通信；分片数过少会导致单个分片索引过大，所以检索速度慢。
  5. 副本数多可以提升搜索能力，但是如果设置的副本数过多也会对服务器造成额外的压力，因为需要同步数据，所以设置2-3个即可
  6. 定时对索引进行优化，合并索引片段，一个索引片段的最好不要超过1G，将多个索引片段合并成一个大的索引片段时，不要太大，太大打开会很慢。
  7. 删除一条数据时不会立即删除，而是产生一个.del的文件，在检索过程中这部分数据也会参与检索，在检索过程中会判断是否删除了，如果删除了再过滤掉，这样会降低检索效率，可以定时执行curl命令进行删除或通过程序代码进行删除。
  8. 如果项目开始的时候需要批量入库大量数据，建议将副本数设为0，因为副本存在，数据要同步到副本，增加es的压力，索引完成后再将副本数修改过来，这样可以提高索引效率。
  9. 去掉mapping中的_all域，这个虽然会给查询带来方便，但是会增加索引时间和所以尺寸
  10. Log输出的水平默认为trace，查询超过500ms即为慢查询，就要打日志，造成cpu，内存，io负载很高，把log水平调为info或是修改配置将查询超时时间调的长一些。 

12：典型的应用场景

es+hbase 利用两个框架的优点实现快速复杂查询和海量数据存储 Es+hbase：利用这两个框架的优点实现快速复杂查询和海量数据存储。 Es通过建立索引实现快速查询，它也可以存储但是不适合海量数据的存储，只存储需要那些需要从索引库中直接返回给客户的内容 Hbase适合海量数据存储，按rowkey查询可以实现快速查询，但是按列查询效率不高，所以结合es实现按字段快速查询 例如：针对海量的文章数据进行存储和快速复杂查询服务就可以通过es+hbase 比如文章数据有：（如果是面试题，需要问清楚需求，需要根据哪些字段进行查询，哪些内容直接从索引库中直接返回给客户，再进行下面的设置） Es的设计：
  • Id：es内置，既建立索引也存储
  • Title：既建立索引也存储
  • Author：不建立索引，存储
  • Describe：既建立索引也存储
  • Content：建立索引不存储
  • Hbase的设计：
  • Rowkey的设计：文章的id
  • 一个列族：info
  • 列限定符：title，author，describe，content

13.客户端请求过程

文档能够通过主要分片(Primary Shard)或者任意一个副本分片(Replica Shard)获取。 每个步骤解释如下：
  1. 客户端(Client)发送一个请求到节点1。
  2. 该节点利用文档的_id字段来判断该文档属于分片0。分片0的分片拷贝(主要分片或者是副本分片)存在于所有的3个节点上。这一次，它将请求转发到了节点2。
  3. 节点2将文档返回给节点1，节点1随即将文档返回给客户端。 对于读请求(Read Request)，
  4. 请求节点(Requesting Node)每次都会选择一个不同的分片拷贝来实现负载均衡 -循环使用所有的分片拷贝。
  5.  可能存在这种情况，当一份文档正在被索引时，该文档在主要分片已经就绪了，但是还未被拷贝到其他副本分片上。
  6.  此时副本分片或许报告文档不存在(译注：此时有读请求来获取该文档)，然而主要分片能够成功返回需要的文档。
  7. 一旦索引请求返回给用户的响应是成功，那么文档在主要分片以及所有副本分片上都是可用的。
 
标签：

相关文章