ElasticSearch非权威完整指南（实战）

已于 2022-06-19 11:58:16 修改
阅读量177 收藏 1
点赞数 1
文章标签： elasticsearch 大数据 数据库 搜索引擎 nosql
于 2020-11-16 08:28:46 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_52571715/article/details/109713515
版权

ElasticSearch非权威完整指南

原创博客不易，如若转载请注明来源。
如有错误及问题，欢迎评论指出。一起学习

文章目录

前言

感谢

这里感谢，网络上的无名大佬的无私分享。我们正站在巨人的肩膀上！Standing on the shoulders of giants

技术栈说明

简介

带着问题上路 - ES是如何产生的？

  • 大规模数据如何检索？

    如：当系统数据量上了10亿、100亿条的时候，我们在做系统架构的时候通常会从以下角度去考虑问题：

    1. 用什么数据库好？(mysql、sybase、oracle、达梦、神通、mongodb、hbase…)
    2. 如何解决单点故障；(lvs、F5、A10、Zookeep、MQ)
    3. 如何保证数据安全性；(热备、冷备、异地多活)
    4. 如何解决检索难题；(数据库代理中间件：mysql-proxy、Cobar、MaxScale等;)
    5. 如何解决统计分析问题；(离线、近实时)

  • 传统数据库的应对解决方案

    对于关系型数据，我们通常采用以下或类似架构去解决查询瓶颈和写入瓶颈：

    1. 通过主从备份解决数据安全性问题。
    2. 通过数据库代理中间件心跳监测，解决单点故障问题。
    3. 通过代理中间件将查询语句分发到多个slave节点，再对查询结果汇总

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T0oEHuuK-1589796555961)(http://minio.hujinwen.com/joe-data/pic-bed/2020-04-29/b952cdef2b29b20792e0ee51ac65b328.png)]

  • 非关系型数据库的解决方案

    对于Nosql数据库，以mongodb为例，其它原理类似：

    1. 通过副本备份保证数据安全性
    2. 通过节点竞选机制解决单点问题
    3. 先从配置库检索分片信息，然后将请求分发到各个节点，最后由路由节点合并汇总结果

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9NRoNNj4-1589796555962)(http://minio1.hujinwen.com/joe-data/pic-bed/2020-04-29/0360ad43f52602fdf21837f5bcbbf0de.png)]

  • 另辟蹊径 - 完全把数据放到内存会怎么样？

    我们知道，完全把数据放在内存中是不可靠的，实际上也不太现实，当我们的数据达到PB级别时，按照每个节点96G内存计算，在内存完全装满的数据情况下，我们需要的机器是：1PB=1024T=1048576G
    节点数=1048576/96=10922个
    实际上，考虑到数据备份，节点数往往在2.5万台左右。成本巨大决定了其不现实！

从前面讨论我们了解到，把数据放在内存也好，不放在内存也好，都不能完完全全解决问题。
全部放在内存速度问题是解决了，但成本问题上来了。
为解决以上问题，从源头着手分析，通常会从以下方式来寻找方法：

  1. 存储数据时按有序存储；
  2. 将数据和索引分离；
  3. 压缩数据；

这就引出了Elasticsearch。

ES基础

什么是es

Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。
Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

lucene和es的关系
  • Lucene只是一个库。想要使用它，你必须使用Java来作为开发语言并将其直接集成到你的应用中，更糟糕的是，Lucene非常复杂，你需要深入了解检索的相关知识来理解它是如何工作的。
  • Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能（索引的每个分片相当于一个lucene索引），但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单
es解决的问题
  • 检索相关数据
  • 返回统计结果
  • 速度要快
es的工作原理

当ElasticSearch的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示：

http://minio1.hujinwen.com/joe-data/pic-bed/2020-04-29/5d26f5fe795a06fcec9d8954c1e017f0.png

es的核心概念

  • Cluster（集群）

    ES可以作为一个独立的单个搜索服务器。不过，为了处理大型数据集，实现容错和高可用性，ES可以运行在许多互相合作的服务器上。这些服务器的集合称为集群。

  • Node（节点）

    形成集群的每个服务器称为节点。

  • Index（索引）

    数据存储在不同的索引中，类似于关系型数据库的database

  • Shard（分片）

    当有大量的文档时，由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等，一个节点可能不够。这种情况下，数据可以分为较小的分片。每个分片放到不同的服务器上。
    当你查询的索引分布在多个分片上时，ES会把查询发送给每个相关的分片，并将结果组合在一起，而应用程序并不知道分片的存在。即：这个过程对用户来说是透明的。

  • Replicas（副本）

    索引副本，ES可以设置多个索引的副本，副本的作用一是提高系统的容错性，当个某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高ES的查询效率，ES会自动对搜索请求进行负载均衡。

  • Type

    索引下的数据存储在不同的Type中，相当于关系型数据库中table。

    在es7.0之后，Type概念已被废弃。统一使用了_doc类型，比较官方的说明如下：

    • 起初，我们说"索引"和关系数据库的“库”是相似的，“类型”和“表”是对等的。
      这是一个不正确的对比，导致了不正确的假设。在关系型数据库里,"表"是相互独立的,一个“表”里的列和另外一个“表”的同名列没有关系，互不影响。但在类型里字段不是这样的。

    • 在一个Elasticsearch索引里，所有不同类型的同名字段内部使用的是同一个lucene字段存储。也就是说，上面例子中，user类型的user_name字段和tweet类型的user_name字段是存储在一个字段里的，两个类型里的user_name必须有一样的字段定义。

    • 这可能导致一些问题，例如你希望同一个索引中"deleted"字段在一个类型里是存储日期值，在另外一个类型里存储布尔值。

    • 最后,在同一个索引中，存储仅有小部分字段相同或者全部字段都不相同的文档，会导致数据稀疏，影响Lucene有效压缩数据的能力。

      因为这些原因，我们决定从Elasticsearch中移除类型的概念。

  • Document

    每一条数据，相当于关系型数据库中的Row

  • Field

    为数据定义的每一个字段，相当于关系型数据库的Column

附上es和关系型数据库的对比：

安装

快速开始

零配置，快速启动一个单机测试节点

  • 去官网下载对应版本的ES -> 传送门

  • 直接启动

    cd elasticsearch-<version>
./bin/elasticsearch

  • 浏览器访问

    http://<ip>:9200

  • 出现以下界面即为成功

    you know for search!

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S2APx43I-1589796555965)(http://minio.hujinwen.com/joe-data/pic-bed/2020-05-18/d624ce7147727d5118cc7fa27f78b69d.png)]

安装ik分词插件

由于ES本身并不支持中文分词。所以需要我们安装中文分词插件。这里介绍比较热门的ik分词插件。

  • github中下载压缩包 -> 传送门

  • 将下载的压缩包解压、重命名，并移动到<ES安装路径>/plugins中

    unzip elasticsearch-analysis-ik-7.1.0.zip -d analysis-ik
mv analysis-ik ******/elasticsearch-7.1.0/plugins

  • 重启ES

  • 可以在Kibana中测试分词效果

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JECJBOTH-1589796555965)(http://minio.hujinwen.com/joe-data/pic-bed/2020-05-18/a8d8542bceb6dc92fcd2608b0c7cf5d6.png)]

  • IK分词插件还支持一些自定义配置，例如：

    • 添加自定义词典
    • 设置停用词

    具体用法，还请自行了解。

集群搭建

这里只简单的介绍，搭建集群的方式和一些关键的配置。至于为什么及思路请看集群管理

# ---------------------------------- Cluster -----------------------------------
# 集群名称，相同集群名称的节点会组成一个集群
cluster.name: firstbrave-es
# ------------------------------------ Node ------------------------------------
# 节点名称
node.name: node-1
# 该节点是否有资格作为master节点
node.master: true
# 该节点是否作为data节点
node.data: true
# ----------------------------------- Paths ------------------------------------
# 数据存储位置（最好配置该参数，数据不要默认放在es的安装路径中）
path.data: /home/opt/fbitext/elasticsearch-7.6.2/data/data
# 日志文件路径（原因同上）
path.logs: /home/opt/fbitext/elasticsearch-7.6.2/data/log
# ----------------------------------- Memory -----------------------------------
# 禁用内存交换（es性能优化中非常重要的一个点）
bootstrap.memory_lock: true
# ---------------------------------- Network -----------------------------------
# 配置该节点ip
network.host: 10.0.0.27
# 配置该节点端口（在一台机器上，安装多个节点时，该参数起到区分的作用）
http.port: 9200
# --------------------------------- Discovery ----------------------------------
# 节点发现，节点通过该配置发现集群中的其他节点（注意端口配置，不要配成了默认的http端口9200）
discovery.seed_hosts: ["10.0.0.27:9300", "10.0.0.39:9300"]
# 初始化master节点（初始化master节点，将从这几个节点中推举）
cluster.initial_master_nodes: ["node-1", "node-2"]
# 防脑裂配置（集群部分中，最少存在多少个备选master节点，才会推举新的master节点）
discovery.zen.minimum_master_nodes: 1

集群管理

详细的解释在集群搭建过程中需要注意的问题（问题如下）：

  1. 我们需要多大规模的集群？
  2. 集群中的节点角色如何分配？
  3. 如何避免脑裂？
  4. 索引应设置多少个分片？
  5. 分片应该设置几个副本？
需要多大的集群规模

  • 我们需要从以下两个角度来考虑：

    1. 当前的数据量多大？数据增长情况如何？
    2. 机器配置如何？cpu？内存？硬盘容量？

  • 推算的依据：

    ES JVM heap 最大可以设置32G 。
    30G heap 大概能处理的数据量 10 T。如果内存很大如128G，可在一台机器上运行多个ES节点实例。

    备注：集群规划满足当前数据规模+适量增长规模即可，后续可按需扩展。

  • 两类应用场景：

    1. 用于构建业务搜索功能模块，且多是垂直领域的搜索。数据量级几千万到数十亿级别。一般2-4台机器的规模。
    2. 用于大规模数据的实时OLAP（联机处理分析），经典的如ELK Stack，数据规模可能达到千亿或更多。几十到上百节点的规模。
集群节点角色分配

  • 节点分为哪些角色：

    1. Master node

      主节点。

      普通服务器即可(CPU 内存 消耗一般)。

      起到集群管理的作用。维护集群状态，索引创建、删除，索引的分片在节点中的分配。

      配置文件中配置 node.master: true。表示该节点具有成为主节点的资格。具体角色会由多个具有主节点资格的节点选举产生。

    2. Data node

      数据节点。

      主要消耗磁盘，内存。

      配置文件中配置 node.data: true。表示该节点是否存储数据

    3. Coordinate node

      协调节点。

      普通服务器即可(如果要进行分组聚合操作的话，建议这个节点内存也分配多一点)。

      某个节点，上述两个配置均为false的情况，那么该节点即为协调节点。协调节点起到接收、转发请求，汇总节点返回的数据，等功能。

  • 如何分配：

    • 默认情况下，每个节点都有成为master、data、coordinate节点的资格。

    • 小规模集群不需要严格区分。

    • 中大规模集群（十个以上节点），应考虑单独的角色充当。区分每个节点角色。角色分开的好处是分工分开，不互影响。例如不会因协调角色负载过高而影响数据节点的能力。分配时可如下考虑：

      • 设置3台以上（奇数个数，防止脑裂）的节点只作为master节点，这些节点只负责成为主节点，维护整个集群状态。（主节点对 CPU、内存 的消耗一般）

  • 设置一批 data节点。这些节点负责存储数据，后期提供建立索引、查询搜索的功能。这些节点的压力较大（data节点，对内存、磁盘有一定的要求）

    • 设置一批 coordinate节点。特别是在并发查询量大、查询的合并量大的时候。这些节点负责处理用户请求，实现请求转发，负载均衡等功能。
防脑裂

  • 什么是脑裂

    在es集群中，Master节点起着集群状态管理、分片分配的作用。

    且Master节点是在所有有资格成为Master节点的节点中推举而来。

    当集群中某些节点无法发现Master节点（可能是网络原因）。那么它就会重新推举新的Master节点。

    这种一个集群中出现了多个Master节点的情况。我们称为脑裂。

    会导致数据不统一、集群不可用。

  • 如何避免，有以下几个要点

    • 关键配置discovery.zen.minimum_master_nodes: (有master资格节点数/2) + 1

      这个配置的作用是，在最少发现了几个Master候选节点的情况下，才推举Master节点。

      这里配置为有master资格节点数/2) + 1。

      所以在集群配置中设置奇数个数的资格节点

    • 单播发现机制，配置master资格节点：

      discovery.zen.ping.multicast.enabled: false —— 关闭多播发现机制，默认是关闭的

      discovery.zen.ping.unicast.hosts: [“master1″, “master2″, “master3″] —— 配置单播发现的主节点ip地址，其他从节点要加入进来，就得去询问单播发现机制里面配置的主节点我要加入到集群里面了，主节点同意以后才能加入，然后主节点再通知集群中的其他节点有新节点加入。

    • 配置选举发现数，及延长ping master的等待时长

      discovery.zen.ping_timeout: 30（默认值是3秒）——其他节点ping主节点多久时间没有响应就认为主节点不可用了
      discovery.zen.minimum_master_nodes: 2 —— 选举主节点时需要看到最少多少个具有master资格的活节点，才能进行选举

索引分片数量设置

分片数量一旦设定，不可更改。除非重建或拆分索引

  • 思考

    1. 分片对应的存储实体是什么？

      每个分片对应的存储实体是lucene索引。

    2. 分片是不是越多越好？

      不是。

    3. 分片多有什么影响？

      浪费存储空间、占用资源、影响性能。

  • 分片过多的影响

    1. 每个分片本质上就是一个Lucene索引，因此会消耗对应的文件句柄、内存、CPU资源。

    2. 每个搜索请求会被调度到索引的每个分片中，如果分片分布在不同的节点（机器）上，那么问题不大。分片一旦在同一个节点（机器）上，便会竞争硬件资源，影响查询速度。

    3. ES使用词频统计来计算相关性. 当然这些统计也会分配到各个分片上. 如果在大量分片上只维护了很少的数据, 则将导致最终的文档相关性较差。

  • 应该为我们的索引设置多少个分片

    • ElasticSearch推荐的最大JVM堆空间是30~32G, 所以把你的分片最大容量限制为30GB, 然后再对分片数量做合理估算。例如，你认为你的数据能达到200GB, 推荐你最多分配7到8个分片。
    • 在开始阶段, 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片. 例如,如果你有3个节点, 则推荐你创建的分片数最多不超过9(3×3)个。当性能下降时，增加节点，ES会平衡分片的放置。
    • 对于基于日期的索引需求, 并且对索引数据的搜索场景非常少. 也许这些索引量将达到成百上千, 但每个索引的数据量只有1GB甚至更小. 对于这种类似场景, 建议只需要为索引分配1个分片。如日志管理就是一个日期的索引需求，日期索引会很多，但每个索引存放的日志数据量就很少。
分片副本数量设置

分片副本的数量是可以随时调整的

  • 思考

    1. 副本的作用是什么？

      • 容灾，保证数据不丢失
      • 高并发时参与数据查询

    2. 该如何设置它的副本数？

      通常情况下，为分片设置一个副本即可满足数据高可用性的要求。

    3. 副本过多有什么影响？

      过多的副本浪费空间、占用资源、影响性能。

  • 副本设置的原则

    创建新的副本时（分片同理）。主节点会对副本进行均衡分配。尽量保证副本不在同一个节点（机器）上

    1. 为保证数据高可用，副本数量设为1～2即可。
    2. 集群中至少需要有3个以上的节点，保证分片和副本被均衡分配在不同的节点上（如果设置了2个副本）。
    3. 如果发现并发量大，影响了查询效率。可适当的增加副本数量。来提升并发查询能力。

性能优化

详见官方文档

加大jvm内存分配

按照分片配比，详情见官方文档

vim config/jvm.options
避免内存交换

由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。

vim config/elasticsearch.yml
# 设置
bootstrap.memory_lock: true

此时启动es会报错

ERROR: [1] bootstrap checks failed
[1]: memory locking requested for elasticsearch process but memory is not locked

需要切换到root权限做以下修改

vim /etc/security/limits.conf
# 添加以下内容，*号代表所有用户，可以指定为具体用户
* soft nofile 65536
* hard nofile 65536
* soft nproc 32000
* hard nproc 32000
* hard memlock unlimited
* soft memlock unlimited

vim /etc/systemd/system.conf
# 添加以下内容
DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity

执行使权限生效

systemctl daemon-reload
分片策略

选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：

我们应该使用最少的分片！

主分片，副本和节点最大数之间数量存在以下关系：

节点数<=主分片数*（副本数+1）

**控制分片分配行为。**以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。

每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。

杀手锏：Filesystem Cache

你往 ES 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 Filesystem Cache 里面去。

ES 的搜索引擎严重依赖于底层的 Filesystem Cache，你如果给 Filesystem Cache 更多的内存，尽量让内存可以容纳所有的 IDX Segment File 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。

性能差距究竟可以有多大?我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。

但如果是走 Filesystem Cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。

这里有个真实的案例：某个公司 ES 节点有 3 台机器，每台机器看起来内存很多 64G，总内存就是 64 * 3 = 192G。

每台机器给 ES JVM Heap 是 32G，那么剩下来留给 Filesystem Cache 的就是每台机器才 32G，总共集群里给 Filesystem Cache 的就是 32 * 3 = 96G 内存。

而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，ES 数据量是 1T，那么每台机器的数据量是 300G。这样性能好吗?

Filesystem Cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。

归根结底，你要让 ES 性能好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。

根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 ES 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 Filesystem Cache 的是 100G，那么你就将索引数据控制在 100G 以内。

这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内。

比如说你现在有一行数据：id，name，age … 30 个字段。但是你现在搜索，只需要根据 id，name，age 三个字段来搜索。

如果你傻乎乎往 ES 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的。

结果硬是占据了 ES 机器上的 Filesystem Cache 的空间，单条数据的数据量越大，就会导致 Filesystem Cahce 能缓存的数据就越少。

其实，仅仅写入 ES 中要用来检索的少数几个字段就可以了，比如说就写入 es id，name，age 三个字段。然后你可以把其他的字段数据存在 MySQL/HBase 里，我们一般是建议用 ES + HBase 这么一个架构。

HBase 的特点是适用于海量数据的在线存储，就是对 HBase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。

从 ES 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 HBase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。

写入 ES 的数据最好小于等于，或者是略微大于 ES 的 Filesystem Cache 的内存容量。

然后你从 ES 检索可能就花费 20ms，然后再根据 ES 返回的 id 去 HBase 里查询，查 20 条数据，可能也就耗费个 30ms。

可能你原来那么玩儿，1T 数据都放 ES，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。

数据预热

假如说，哪怕是你就按照上述的方案去做了，ES 集群中每个机器写入的数据量还是超过了 Filesystem Cache 一倍。

比如说你写入一台机器 60G 数据，结果 Filesystem Cache 就 30G，还是有 30G 数据留在了磁盘上。

其实可以做数据预热。举个例子，拿微博来说，你可以把一些大 V，平时看的人很多的数据，提前在后台搞个系统。

每隔一会儿，自己的后台系统去搜索一下热数据，刷到 Filesystem Cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。

或者是电商，你可以将平时查看最多的一些商品，比如说 iPhone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 Filesystem Cache 里去。

对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统。

**就是对热数据每隔一段时间，就提前访问一下，让数据进入 Filesystem Cache 里面去。**这样下次别人访问的时候，性能一定会好很多。

冷热分离

ES 可以做类似于 MySQL 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。

最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 Filesystem OS Cache 里，别让冷数据给冲刷掉。

你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 Shard。3 台机器放热数据 Index，另外 3 台机器放冷数据 Index。

这样的话，你大量的时间是在访问热数据 Index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 Filesystem Cache 里面了，就可以确保热数据的访问性能是很高的。

但是对于冷数据而言，是在别的 Index 里的，跟热数据 Index 不在相同的机器上，大家互相之间都没什么联系了。

如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。

索引拆分

单索引存储的数据不宜多大，可再次对索引进行拆分。

# 根据日期进行数据拆分
POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "index_name"
  },
  "dest": {
    "index": "index_name-"
  },
  "script": {
    "inline": "def sf = new SimpleDateFormat(\"yyyy-MM-dd'T'HH:mm:ss\");def o = new SimpleDateFormat(\"yyyy-MM-dd\");def dt = sf.parse(ctx._source.created_at);ctx._index='index_name-' + o.format(dt);"
  }
}
# 按照 ID 范围，比如根据ID / 10000000取整，也就是1千万数据放一个index
POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "index_name"
  },
  "dest": {
    "index": "index_name-"
  },
  "script": {
    "inline": "ctx._index='index_name-' + Long.valueOf(ctx._source.id / 10000000).toString();"
  }
}

查询详解

查询Demo

# 创建index
PUT test_index
# 删除index
DELETE flume-6666
# 查询所有的index
GET _cat/indices

# 向指定index的type中POST数据
POST flume-2020-03-31/_doc
{
  "content": "null"
}

# 向指定index的指定type的指定id中PUT进数据
PUT flume-2020-03-31/_doc/666
{
  "content": "null"
}

# 查询所有数据
GET /flume-2020-03-31/_search
{
  "query": {
    "match_all": {}
  }
}

# 根据index、type、id精确查找
GET /flume-2020-03-31/_doc/QMMjL3EB4usxco8zG808

# 替换一条数据
PUT /flume-2020-03-31/_doc/QMMjL3EB4usxco8zG808
{
  "content": "null"
}

# 相似度匹配
GET /flume-2020-04-01/_search
{
  "query": {  
    "match": {
      "content": "2020-04-01 08:09:12.390"
    }
  }
}

# 包含匹配
GET /flume-2020-04-01/_search
{
  "query": {  
    "query_string": {
      "default_field": "content",
      "query": "7e2c0f7b-64cc-482b-8990-9a78d4cd0254"
    }
  }
}

# 查询数据统计
GET /flume-2020-04-01/_count
{
  "query": {
    "match_all": {}
  }
}

# 查看集群健康
GET /_cluster/health

集群状态

集群健康状态
GET /_cluster/health
集群节点状态
GET _nodes/stats

获取所有

GET /flume-*/_search
{
  "query": {
    "match_all": {}
  }
}

复合查询

  • must

    表示文档一定要包含查询的内容

  • must_not

    表示文档一定不要包含查询的内容

  • should

    表示文档如果匹配上可以增加文档相关性得分

GET /flume-2020-04-07/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {
          "name": "phone"
        }}
      ]
      , "must_not": [
        {"match": {
          "color": "red"
        }}
      ]
      , "should": [
        {"match": {
          "price": 5000
        }}
      ]
      , "filter": {
          "term": {
            "label": "phone"
          }
      }
    }
  }
}

分页查询

不要进行深度分页，会有性能问题。

假设你的一个index有10个分片。分页每次取10条。

当取第一页时，会从每个分片取出10条，一共10*10=100条。再汇总，返回得分最高的10条。

当取第100页时，会从每个分片取出100*10=1000条，一共1000*10=10000条。再汇总。深度分页时查询速度会非常慢。

GET /flume-*/_search
{
  "query": {
    "match_all": {}
  },
  "from": 1,
  "size": 2
}

指定返回的FIELD

GET /flume-*/_search
{
  "query": {
    "match_all": {}
  },
  "_source": ["name","price"]
}

排序

GET /ad/phone/_search
{
  "query": {
    "match": {
      "ad": "white"
    }
  }, 
  "sort": [
    {
      "price": {
        "order": "asc"
      }
    }
  ]
}

查询统计

GET /flume-*/_count
{
  "query": {
    "match_all": {}
  }
}

operator操作

match 查询还可以接受 operator 操作符作为输入参数，默认情况下该操作符是 or 。我们可以将它修改成 and 让所有指定词项都必须匹配

GET /flume-*/_search
{
  "query": {
    "match": {
      "content": {
        "query": "a red",
        "operator": "and"
      }
    }
  }
}

精确度匹配

match 查询支持 minimum_should_match 最小匹配参数， 可以指定必须匹配的词项数用来表示一个文档是否相关。我们可以将其设置为某个具体数字（指需要匹配倒排索引的词的数量），更常用的做法是将其设置为一个百分数，因为我们无法控制用户搜索时输入的单词数量

GET /flume-*/_search
{
  "query": {
    "match": {
      "ad": {
        "query": "a red",
        "minimum_should_match": "2"
      }
    }
  }
}

多FIELD匹配

多字段查询，比如查询color和ad字段包含单词red的文档

GET /ad/phone/_search
{
  "query": {
    "multi_match": {
      "query": "red",
      "fields": ["color","ad"]
    }
  }
}

range查询

范围查询，查询价格大于4000小于6000的文档

GET /ad/phone/_search
{
  "query": {
    "range": {
      "price": {
        "gt": 4000,
        "lt": 6000
      }
    }
  }
}

term查询

精确值查询，查询price字段等于6000的文档

GET /ad/phone/_search
{
  "query": {
    "term": {
      "price": {
        "value": "6000"
      }
    }
  }
}

查询name字段等于phone 8的文档

GET /ad/phone/_search
{
  "query": {
    "term": {
      "name": {
        "value": "phone 8"
      }
    }
  }
}

返回值如下，没有查询到名称为phone 8的文档

{
  "took": 5,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": null,
    "hits": []
  }
}

为什么没有查到phone 8的这个文档那，这里需要介绍一下term的查询原理

term查询会去倒排索引中寻找确切的term,它并不会走分词器，只会去配倒排索引 ，而name字段的type类型是text，会进行分词，将phone 8 分为phone和8，我们使用term查询phone 8时倒排索引中没有phone 8，所以没有查询到匹配的文档

term查询与match查询的区别

  • term查询时，不会分词，直接匹配倒排索引
  • match查询时会进行分词，查询phone 8时，会先分词成phone和8，然后去匹配倒排索引，所以结果会将phone 8和xiaomi 8两个文档都查出来

还有一点需要注意，因为term查询不会走分词器，但是回去匹配倒排索引，所以查询的结构就跟分词器如何分词有关系，比如新增一个/ad/phone类型下的文档，name字段赋值为Oppo，这时使用term查询Oppo不会查询出文档，这时因为es默认是用的standard分词器，它在分词后会将单词转成小写输出，所以使用oppo查不出文档，使用小写oppo可以查出来

GET /ad/phone/_search
{
  "query": {
    "term": {
      "name": {
        "value": "Oppo" //改成oppo可以查出新添加的文档
      }
    }
  }
}

terms查询

terms查询与term查询一样，但它允许你指定多直进行匹配，如果这个字段包含了指定值中的任何一个值，那么这个文档满足条件

GET /ad/phone/_search
{
  "query": {
    "terms": {
      "ad": ["red","blue"]
    }
  }
}

exists 查询和 missing 查询

用于查找那些指定字段中有值 (exists) 或无值 (missing) 的文档

  • 指定name字段有值

    GET /ad/phone/_search
{
  "query": {
    "bool": {
      "filter": {
        "exists": {
          "field": "name"
        }
      }
    }
  }
}

  • 指定name字段无值

    GET /ad/phone/_search
{
  "query": {
    "bool": {
      "filter": {
        "missing": {
          "field": "name"
        }
      }
    }
  }
}

match_phrase查询

短语查询，精确匹配，查询a red会匹配ad字段包含a red短语的，而不会进行分词查询，也不会查询出包含a 其他词 red这样的文档

GET /ad/phone/_search
{
  "query": {
    "match_phrase": {
      "ad": "a red"
    }
  }
}

scroll查询

类似于分页查询，不支持跳页查询，只能一页一页往下查询，scroll查询不是针对实时用户请求，而是针对处理大量数据，例如为了将一个索引的内容重新索引到具有不同配置的新索引中

POST /ad/phone/_search?scroll=1m
{
  "query": {
    "match_all": {}
  },
  "size": 1,
  "from": 0
}

返回值包含一个 "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAAQFlV6T3VqY2NaVDBLRG5uZXdiZ0hFYUEAAAAAAAAAERZVek91amNjWlQwS0RubmV3YmdIRWFBAAAAAAAAABIWVXpPdWpjY1pUMEtEbm5ld2JnSEVhQQAAAAAAAAATFlV6T3VqY2NaVDBLRG5uZXdiZ0hFYUEAAAAAAAAAFBZVek91amNjWlQwS0RubmV3YmdIRWFB"

下次查询的时候使用_scroll_id就可以查询下一页的文档

POST /_search/scroll 
{
    "scroll" : "1m", 
    "scroll_id" : "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAAYFlV6T3VqY2NaVDBLRG5uZXdiZ0hFYUEAAAAAAAAAGRZVek91amNjWlQwS0RubmV3YmdIRWFBAAAAAAAAABYWVXpPdWpjY1pUMEtEbm5ld2JnSEVhQQAAAAAAAAAXFlV6T3VqY2NaVDBLRG5uZXdiZ0hFYUEAAAAAAAAAFRZVek91amNjWlQwS0RubmV3YmdIRWFB" 
}

通配符查询

{
    'query':{
        'wildcard':{
            'title':'cr?me'
        }
    }
}

正则表达式查询

{
    'query':{
        'regex':{
            'title':{
                'value':'cr.m[ae]',
                'boost':10.0
            }
        }
    }
}

前缀查询

{
    'query':{
        'match_phrase_prefix':{
            'title':{
                'query':'crime punish',
                'slop':1
            }
        }
    }
}

issues

ES集群节点宕机导致shard unassigned解决方案

在springboot项目中使用需要制定es版本

<!-- 需要在pom.xml中制定es版本 -->
<properties>
    <elasticsearch.version>7.6.1</elasticsearch.version>
</properties>

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

vim /etc/security/limits.conf

# 添加如下配置，* 代表所有用户。也可指定某个用户
*               soft    nofile          65536
*               hard    nofile          65536

# 执行如下命令生效
sysctl -p

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

vim /etc/security/limits.conf

# 添加如下配置，* 代表所有用户，也可配置为指定某个用户
*               soft    nproc           4096
*               hard    nproc           4096

# 执行如下命令生效
sysctl -p

max virtual memory areas vm.max_map_count [65530] is too low

# 编辑配置文件
vi /etc/sysctl.conf 
# 添加配置
vm.max_map_count=655360
# 让配置生效
sysctl -p

at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes]…

# 编辑配置文件
vim config/elasticsearch.yml
# 修改
cluster.initial_master_nodes: ["node-1"]

system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk

  • 原因：
    这是在因为Centos6不支持SecComp，而ES5.2.0默认bootstrap.system_call_filter为true进行检测，所以导致检测失败，失败后直接导致ES不能启动。

  • 解决：
    在elasticsearch.yml中配置bootstrap.system_call_filter为false，注意要在Memory下面:

  • 查看 issues

    https://github.com/elastic/elasticsearch/issues/22899

bootstrap.memory_lock: false
bootstrap.system_call_filter: false
fastji
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Elasticsearch 权威指南（中文版）带书签文字版
11-10
**Elasticsearch 权威指南**是一本深入探讨Elasticsearch技术细节的书籍，中文版的发布使得更多中国用户能够无障碍地学习和掌握这一强大的搜索引擎。本书覆盖了Elasticsearch的各个方面，包括基础概念、安装配置、...
Elasticsearch权威指南-中文.pdf
03-01
中文版的《Elasticsearch权威指南》为读者提供了全面深入的ES学习资料。 本书主要涵盖以下几个方面： 1. **基础概念与架构** - **搜索引擎原理**：介绍信息检索的基本概念，如倒排索引、TF-IDF等。 - **Elastic...
elasticsearch权威指南中文版 pdf和Elasticsearch顶尖高手系列-高手进阶篇资源分享
热门推荐
sskai163的博客
11-28 2万+
elasticsearch权威指南中文版 链接: https://pan.baidu.com/s/1ckBXkGB0UPUEnacHk_QR2g 提取码: yytn 这个之前看网页版的把我尴尬症都看出来了，太慢了，还是看pdf舒服 Elasticsearch顶尖高手系列-高手进阶篇 链接: https://pan.baidu.com/s/1oikDusfJDPhgdAf3vvi_yg 提取码: g...
elasticsearch权威指南-中文
CiCi岛的专栏
04-10 1418
网站 更多书籍点击进入>> CiCi岛 下载 电子版仅供预览及学习交流使用，下载后请24小时内删除，支持正版，喜欢的请购买正版书籍 电子书下载(皮皮云盘-点击“普通下载”) 购买正版 封页 编辑推荐 本书着重介绍关于Elastic Stack的基本知识，带领读者深入了解Elastic Stack的实际应用，通过对数据搜索、日志挖掘与结果可视化展示等相关功能的介绍和实战，引导读者掌...
彩印图文版《Elasticsearch实战》文档，阿里内部共享，堪称精品
m0_72327953的博客
09-16 549
1.1 文档内容1.2 面向人员1.3 笔记优势1.4 学习路径。
Elasticsearch 完整指南
duoshehuan6005的博客
08-24 164
JSON知识基本的终端技能是加分项。
Elasticsearch权威指南中文社区和简单语法操作
纸上得来终觉浅，绝知此事要躬行
09-10 2066
目录 Elasticsearch: 权威指南 Elasticsearch：中文社区 Elasticsearch简单操作 Index索引 Document文档 自定义match查询(实现任意全文搜索) bool查询（OR AND NOT） Range查询 term 查询被用于精确值匹配 文档插入的JavaScript实例 Elasticsearch: 权威指南 https:/...
elasticSearch的基本使用加项目实战(Java爬取数据+elasticSearch)
weixin_51123481的博客
05-07 1708
一.es的安装 2.1、Es安装 为了避免出现不必要的一些问题， 我们这里选择 7.3.1版本 1. 安装es 下载 https://www.elastic.co/downloads/past-releases/elasticsearch-7-3-1 2. 安装 ：安装很简单，只需要解压即可。解压后进入 bin 目录，运行里面的 elasticsearch.bat ，即 可运行 Es 3. 访问：启动 Es 服务后，访问 localhost:9200 即可看到如下界面： 2、安装head 可视
Elasticsearch简介与实战
2401_85112052的博客
06-18 527
（1）全面：本书作者团队阵容强大，既有架构师、培训师，又有面试官，分别从自身经验出发讲解工作中遇到的痛点。（2） 实用：本书将相关知识的系统整合，符合现在Java的主流应用，拒绝全面不实用；本书知识点主要围绕技术升级和面试技巧展开，让你在升级专业知识的同时更能顺利通过面试。（3） 丰富：本书附带Java Core常用知识点的视频和面试题，并且内容会不断更新。Java是编程世界备受欢迎的语言，虽然Java技术在运用中已趋成熟，但招聘市场的Java开发人才却仍然供不应求。
ElasticSearch实战系列四: ElasticSearch理论知识介绍
虚无境的博客
12-24 445
前言 在前几篇关于ElasticSearch的文章中，简单的讲了下有关ElasticSearch的一些使用，在将这些使用方法的时候又总是不得不讲下一些理论知识，虽然本人是一个实战派，不太喜欢将这些理论知识，因为这块可以查看官方文档，那里会写得很详细。但是在使用了ElasticSearch 但是越写越发现还是得写一篇有关ElasticSearch有关的理论知识文章的，这样有利于在后续的文章中。 在上...
Elasticsearch 简介和实战
TurboSnail
04-15 837
文章目录关于 ElasticsearchElasticsearch 安装Kibana 安装基本概念全文搜索（full-text search）集群、节点（cluster & node）索引（index）类型（mapping type）文档（document）映射、字段（mapping & field）快速入门 最近项目要用到全文搜索，需要有中文、拼音检索以及混合搜索以及数据聚合功能...
elk实战指南，权威指南 elk-stack-guide-cn.pdf
01-12
elk 权威指南 elasticsearch logstash kibana elk实战指南，权威指南 elk-stack-guide-cn.pdf
Git协作
weixin_51147313的博客
07-06 715
在处理不同任务的时候开不同的分支，把不同的任务区别开多个不同的分支可以合并成一个分支，各个分支互不影响，除非拉取新的更改为每个任务创建分支是个值得采用的做法，可以更好的追溯变更。git status用于查看工作目录和暂存区的当前状态，是了解当前工作进度和状态的最直接的工具。git log用于查看提交历史，帮助你了解项目的版本历史和过去的开发活动。这两个命令在日常的 Git 使用中非常关键，为开发者提供了关于项目状态和历史的重要信息。
RAG实践：ES混合搜索BM25+kNN(cosine)
天然玩家的博客
07-07 1006
本系列分为两大部分：**实践**和**理论**。 **先讲**实践，**应对快速开发迭代**，可快速上手实践； **再讲**理论，**应对优化**，如归一化。
洛谷 P3008 [USACO11JAN] Roads and Planes G
sblsf的博客
07-07 302
有一张n点m1​m2​边的无向图，其中m1​条为无向边，另外m2​条为有向边， 无向边的边权可以为负。求s到其他每个点的最短路。
【Git 学习笔记】第二章 Git 的配置（上）
PeacefulWinter的博客
07-05 886
本篇为《Git Version Control Cookbook》第二版 Ch2.1~2.4 小节的学习笔记+实操代码。主要介绍了 Git 的配置范围、配置项的检索与查看、配置模板的定制，以及目录模板的配置与使用。
Elasticsearch 多索引/多类型搜索
最新发布
Dxy1239310216的博客
07-10 439
Elasticsearch的多索引搜索功能为跨多个数据集进行联合查询提供了极大的便利。通过灵活使用索引名、通配符和组合查询等技巧，可以构建出复杂而强大的搜索查询。然而，随着Elasticsearch版本的更新和演进，一些旧的功能（如类型）可能会被废弃或移除，因此在设计和实现多索引/多类型搜索时，需要关注Elasticsearch的最新动态和最佳实践。
什么时候考虑将mysql数据迁移到ES？
huhu123444的博客
07-06 702
在模糊的影响中，ES查询效率高，尤其是最近组内在推慢sql治理，看到有些单张表已经存在索引数量近10个，表中字段确实比较多，一种治理方式是宽表拆分多个表，降低每个表查询的字段，每个表需要创建和维护索引数量也会降低。也在考虑是不是可以将数据同步到ES，部分查询场景走ES，宽表拆分导致数据比较分散，更新和查询起来更麻烦，使用ES数据完整性可以保证，相同数据使用不同的存储介质进行存储，更新和维护相比来说更简单。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值