ES的运维与管理

故障诊断分析思路

• 从故障的具体现象和具体信息出发，逻辑性的向上推理可能的因素，并逐步排除，渐渐缩小问题范围，直到定位问题
• 根据故障信息和经验直接猜测故障原因，这种凭空设想在面对简单问题时能比较快速定位；但面对错综复杂、多种因素混合的问题时，更多的需要理性推导。尽管如此，"假设故障原因"仍然很重要，在推导问题过程中，以及不可重现的问题时，需要联想到其相关的都有哪些因素
• 在逐步缩小问题范围、验证想法的过程中，验证方法可能有多种选择。最好选能证明问题，同时是最简单的方式

故障分析方式

定位慢查询

• 使用Profile API定位慢查询，通过Profile API可以检查查询执行时间和其它详细信息

分析未分配的分片

• 使用Explain API分析未分配的分片（Unassigned Shards），由于某些原因（节点离线、分片数量设置错误等），某些分片可能会处于未分配状态（Unassigned），导致集群健康处于Yellow或Red状态，这是一种比较常见的错误信息，使用Explain API可以很容易分析当前的分片分配情况

• Explain API主要解决的问题包括

  • 对于未分配的分片，给出为什么没有分配的具体原因
  • 对于已分配的分片，给出为什么将分片分配给特定节点的理由

• 常见场景

  • 诊断未分配的主分片
  • 诊断未分配的副分片
  • 诊断已分配的分片

节点CPU使用率高

• 使用hot_threads API，推荐使用hot_threads API获取繁忙线程的堆栈
• 使用top + jstack
  • top获取线程级CPU占用率，再根据线程ID，配合jstack定位CPU占用率再特定比例之上的线程堆栈
  • 该方式由于两个命令的执行在时间上（对进程采样的时间点）存在误差，所以定位出的堆栈存在一定概率的偏差

节点内存使用率高

• 使用jmap导出堆进行分析
  • 使用jmap导出一个堆出来，加载到MAT中进行分析，可以精确定位书籍结构占用内存的大小，以及被哪些对象引用，这是定位此类问题最直接的方式
  • jmap导出的堆可能非常大，操作比较花时间，也可以简单看以下ES中几个占用内存比较大的数据结构
• bulk队列可以通过_cat API查看bulk队列中当前的使用量。如果队列设置很大，则在写入压力大时就会导致比较高的内存占用
• Netty缓冲在一些特别的情况下Netty的内存池也可能会占用比较高的内存
• indexing buffer索引写入缓冲用于存储索引好的文档数据，当缓冲满时，生成一个新的Lucene分段。在一个节点上，全部分片共享indexing buffer。缓冲默认大小为堆内存10%，加大该缓冲需要考虑到对GC的压力
• 超大数据集的聚合
  • 协调节点对检索结果进行汇总和聚合，当聚合涉及的数据量很大时，协调节点需要拉取非常多的内容，大范围的聚合是导致节点OOM的常见原因之一
• 分段内存
  • 一个Lucene分段就是一个完整的倒排索引，倒排索引由单词词典和倒排列表组成
  • 每个分段都会占用一定的内存空间
  • 可以通过get {host}/_cat/nodes?v&h=segments.memory进行查看某个节点上所有分段占用的内存总量
• Fielddata cache
  • 在text类型字段上进行聚合和排序时会用到Fielddata，默认是关闭的，如果开启Fielddata，则其大小默认没有上限
  • 可以通过indices.fielddata.cache.size设置一个百分比来控制其堆内存上线
  • 通过get {host}/_cat/nodes?v&h=fielddata.memory_size来查看使用情况
• Shard request cache
  • 分片级别请求缓存。每个分片独立的缓存查询结果
  • 该缓冲是默认开启的，默认为堆大小的1%，可以通过indices.requests.cache.size选项来调整
• Node Query Cache
  • 节点查询缓存由节点上的所有分片共享，也是一个LRU缓存，用于缓存查询结果，只缓存在过滤器上下文中使用的查询
  • 默认开启，大小为堆的10%，可以通过indices.queries.cache.size选项来配置大小

Slow Logs

• 简述
  • 慢查询日志，ES只将执行慢的请求记录日志，"慢"的程度可以自己定义
  • 写入慢或者查询慢的原因可能会有多种因素，慢日志对我们诊断这些问题非常有用
• ES记录的慢日志类型
  • 慢搜索日志
    • 用来记录哪些查询比较慢，"慢"的程度由程序自己定义，每个节点可以设置不同的阈值
    • 搜索由两个阶段组成，即查询和取回，慢搜索日志记录了每个阶段所花费的时间，以及整个查询内容本身
    • 慢搜索日志的常用配置项
  • 慢索引日志
    • 用来记录哪些索引操作比较慢，其记录了哪些索引操作耗时比较长，阈值同样可以设置
    • 索引内容可能非常大，因此默认记录源文档内容的前1000行。可以设置为捕获整个文档，或者不记录原始文档本身
    • 慢索引日志常见配置项

故障分析工具

I/O信息

• iostat
  • iostat是用来分析I/O状态的常用工具，其输出结果是以/proc/diskstats为基础计算的
  • 当I/O产生性能问题时，该工具不足以定位故障
  • 无法关联到进程
  • 关注的指标
    • iops，由r/s（每秒读写次数）和w/s（每秒写次数）组成
    • await，平均I/O等待时间，包括硬件处理I/O的时间和在队列中等待时间
    • %util，设备的繁忙比，是设备执行的I/O时间与经过的时间百分比
• blktrace
  • 通过该工具可以分析I/O请求的各个环节
• pidstat
  • 可以动态给出每个进程的读写速度
• iotop
  • 可以动态给出每个进程的读写速度
  • 在统计信息中给出全部磁盘的读写速度，以及每个进程的读写速度
• systemtap
  • 可以查看特定磁盘上特定进程的I/O情况

内存分析

• top、free、vmstat
  • 这些工具可以帮助我们查看基础的内存信息，包括物理内存总量、剩余空间、cache量等
• sar -B
  • 该命令可以展示内存分页的统计信息，通过该命令可以观察系统回收内存效率如何
• sar -W
  • 该命令可以在开启了交换分区的系统上，查看页面交换的信息

CPU信息

• vmstat
  • 输出用户级（us）和内核级（sys）的CPU占用百分比，以及采样周期内的上下文切换次数，block in、block out次数等信息
• mpstat
  • 获取用户级（us）和内核级（sys）的CPU占用百分比，还可以输出采样周期内的软中断（soft）、硬中断（irq）占用时间的百分比
• strace -c
  • 可以统计系统调用次数和执行时间
• strace
  • 该命令可以指定跟踪哪些类型的系统调用，例如：文件级、进程相关、网络相关等
  • 也可以跟踪特定的系统调用，例如：open、close
  • 命令执行后需要手工按"Ctrl + C"组合键退出
• Perf
  • 是linux用户主要的性能分析工具，如分析CPU、实时显示系统最耗时的内核函数及进程、记录函数级别的统计信息
  • 例如
    • perf top
    • perf record
    • perf report

网络连接和流量

• sar
  • 用来查看网卡流量的最常用方式，它以字节为单位输出网络传入和传出流量
• netstat
  • 该命令是观察网络连接的常用工具，但是不适合处理海量网络连接
  • 例如
    • netstat -anp，该命令可以列出连接的详细信息，并且可以将连接、监听的端口对应到进程
    • netstat -s，提供了各个协议下的统计信息，例如：活跃连接数、重传次数、reset信息等
• ss
  • 与netstat功能类似，但适合处理海量连接
  • 例如
    • ss -anp
• ifconfig
  • 用来查看IP地址，还提供了RX/TX errors、dropped、overruns等信息 osysdig
• sysdig
  • 可以分析系统级和进程级许多方面的状况
  • 例如：系统调用、网络统计、文件I/O等

运维管理

集群层

集群规模规划

• 评估初始集群大小
  • 数据总量，每天的增量
  • 查询类型和搜索并发，QPS
  • SLA级别
• 初始集群的注意事项
  • 节点总数不应该太多，一般来说，最大集群规模最好控制在100个节点左右。在上千个节点集群规模下，节点间的连接数和通信量会倍增，主节点管理压力比较大
  • 单个分片最好不要超过50GB，最大集群分片总数控制在几十万的级别。太多分片同样增加了主节点的管理负担，而且集群重启恢复时间会很长
  • 建议集群配置较好的硬件，搜索对CPU、内存、磁盘的性能要求很高，要达到较低延迟就需要较好的硬件资源
  • 使用不同的配置的服务器混合部署，会导致速度可能会取决于最慢的那个节点，产生长尾效应

单节点还是多节点部署

• 部署ES节点时的选择（主机内存大于64GB、拥有多个数据盘，不做raid的情况）
  • 部署单个节点，JVM内存配置不超过32GB，配置全部数据盘，这种部署模式的确定是多余的物理内存只能被cache使用，而且只要存在一个坏盘，节点重启会无法启动
  • 部署单个节点，JVM内存配置超过32GB，配置全部数据盘，接受指针压缩失效和更长时间的GC等负面影响
  • 有多少个数据盘就部署多少个节点，每个节点配置单个数据路径。优点是可以统一配置，缺点是节点数较多，集群管理负担大，只适用于集群规模较小的场景
  • 使用内存大小除以64GB来确认部署的节点数，每个节点配置一部分数据盘，优点是利用率最高，缺点是部署复杂
• 补充
  • ES不建议为JVM配置超过32GB的内存，超过32GB时，Java内存指针压缩失效，浪费一些内存，降低CPU性能，GC压力也较大。因此推荐设置31GB，即-Xmx31g -Xms31g，最大堆和最小堆保持一致，防止程序在运行时动态改变堆大小
  • 官方建议是采用方案4，如果是为了管理和维护方便，也可以使用方案1和3

移除节点流程

• 由于坏盘、维护等故障需要下线一个节点时
• 需要将节点的数据迁移，通过分配过滤器实现，put _cluster/settings
• 执行命令后，分片开始迁移，可以通过_cat/shard来查看该节点的分片是否迁移完毕
• 当节点维护完毕，重新上线之后，需要排除设置，以便后续的分片可以分配到节点上

独立部署主节点

• 将主节点和数据节点分离部署最大好处是Master切换过程可以迅速完成，有机会跳过gateway和分片重新分配的过程（持有最新的集群状态）

节点层

• 控制线程池的队列大小
  • 不要为bulk和search分配过大的队列，队列并非越大越好，队列缓存的数据越多，GC压力越大，默认的队列大小基本够用，即使在压测场景中，默认队列大小也足以支持
• 为系统cache保留一半物理内存
  • 搜索操作很多依赖对系统cache的命中，标准的建议是把50%的可用内存作为ES的堆内存，为Lucene保留剩下的50%，用作系统cache

系统层

关闭swap

• 在服务系统上，无论物理内存多么小，都应该关闭交换分区
• 当服务程序在交换分区上缓慢运行时，容易产生更多不可预期的错误
• 在安装操作系统的时候直接关闭交换分区，或者通过swapoff命令来关闭

配置Linux OOM Killer

• 此处讨论的是Linux操作系统的OOM
• 当系统产生OOM的时候，可用通过在用户态调节一些进程参数来让某些进程不容易被OOM Killer"杀掉"
• 可用设置进程的oom_score_adj参数（越小越不容易被杀）

优化内核参数

调节内核参数的两种方式

• 临时设置，系统重启后失效。通过sysctl -w 来设置，命令执行后该参数立即生效
• 永久设置，将参数写入配置文件/etc/sysctl.conf，然后执行sysctl -p使其生效

可调节的参数

• TCP相关参数
  • net.ipv4.tcp_syn_retries
    • 内核发送SYN报文的重试次数，超过这个次数后放弃连接。默认值是6，参考值为2
    • 内网环境通信良好，因此可用适度降低此值
  • net.ipv4.tcp_synack_retries
    • 项客户端发送SYN+ACK报文的重试次数，超过这个次数后放弃连接。默认值是5，参考值为2
    • 内网环境通信良好，因此可用适度降低此值
  • net.ipv4.tcp_timestamps
    • 是否开启时间戳，开启后可用更精确的计算RTT，一些其它特性也依赖时间戳字段。默认值是1，参考值是1
  • net.ipv4.tcp_tw_reuse
    • 是否允许将处于TIME_WAIT状态的socket用于新的TCP连接，这对于降低TIME_WAIT数据很有效。默认为0，建议为1
    • 该参数只有在开启tcp_timestamps的情况下才会生效
  • net.ipv4.tcp_tw_recycle
    • 是否开启TIME_WAIT套接字的快速回收，这是比tcp_tw_reuse更激进的一种方式，默认值为0，参考值为0
    • 依赖tcp_timestamps选项
    • 建议不要开启tcp_tw_recycle，TIME_WAIT是十分必要的状态，避免关闭中的连接与新连接之间的数据混肴
    • tcp_tw_recycle选项在NAT环境下会导致一些新建连接被拒绝，因为NAT下每个主机存在时差，这体现在套接字中的时间戳字段，服务端会发现某个IP上本应递增的时间戳出现降低的情况，时间戳相对较低的报文将被丢弃
  • net.core.somaxconn
    • 定义了系统中每一个端口上最大的监听队列的长度
    • 默认值为128，参考值为2048
    • ES需要建立许多连接，当集群节点数比较大，集群完全重启时可能会在瞬间建立大量连接，默认的连接队列长度可能不够用，可用适当提高此值
  • net.ipv4.tcp_max_syn_backlog
    • 内核会为服务端的连接建立两个队列，由于ES可能会有较多的连接数，可用适度增加"未完成连接"的队列大小
    • 默认值为128，参考值为8192
  • net.ipv4.tcp_max_tw_buckets
    • 定义系统同时保持TIME_WAIT套接字的最大数量
    • 如果超过这个数，则TIME_WAIT套接字将立即被清除并打印告警信息
    • 默认4096，参考值为180000
  • net.ipv4.tcp_max_orphans
    • 定义最大孤儿套接字（未附加到任何用户文件句柄的套接字）数量
    • 如果孤儿套接字数量超过此值，则这些连接立即"reset"，并显示警告信息
    • 默认值为4096，参考值为262144
    • 可用简单的抵御DOS攻击，但不能通过降低此值来抵御DOS
    • 为了应对高负载，应该提高此值

TCP的接收窗口（RWND）和拥塞窗口（CWND）

• TCP采用两个基本原则决定何时发送以及发送多少数据
  • 流量控制/接收窗口
    • 为了确保接收者可以接收数据
    • 通过在接收方指定接收窗口大小来实现
    • 接收窗口用于接收端告诉发送端，自己还有多大的缓冲区可以接收数据，发送端参考这个值来发送数据，就不会导致客户端处理不过来
    • 接收窗口可以通过内核参数来调整，其理想值是BDP（bandwidth-delay product）
  • 拥塞控制/拥塞窗口
    • 为了管理网络宽带
    • 拥塞控制机制会评估网络能承受的负荷，避免过量数据发送到网络中，拥塞程度会涉及主机、路由器等网络上的所有因素
    • 拥塞控制由发送方实现，发送方会将它传输的数据量限制为CWND和RWND的最小值
    • CWND会随着时间和对端ACK增长，如果检测到网络拥塞，则缩小CWND
    • 拥塞控制主要有4种算法:慢启动、拥塞避免、快速重传和快速恢复

VM相关参数

• 简述
  • 文件的读和写操作都会经过操作系统的cache，读缓存是比较简单的，而写缓存相对复杂
  • 写文件的数据先到系统缓存（page cache），再由系统定期异步地刷入磁盘。这些存储于page cache中尚未刷盘地数据称为脏数据（或脏页，dirty page）。写缓存可以提升I/O速度，但存在数据丢失地风险
  • 一般情况下，系统先执行异步刷盘策略，当脏页数据量过大，会切换到同步刷盘策略
• 从page cache刷到磁盘有以下三种时机
  • 可用物理内存低于特定阈值时，为了给系统腾出空闲内存
  • 脏页驻留时间超过特定阈值时，为了避免脏页无限期驻留内存
  • 被用户的sync()或fsync()触发
• 由系统执行的刷盘有两种写入策略
  • 异步执行刷盘，不阻塞用户I/O
    • vm.dirty_background_ration，当内存中的脏数据超过这个百分比后，会使用异步方式刷盘，默认值为10
    • vm.dirty_background_bytes，当内存中的脏数据超过这个字节数后，会使用异步方式刷盘
  • 同步执行刷盘，用户I/O被阻塞，直到脏页低于某个阈值
    • vm.dirty_ratio，当内存中的脏数据超过这个百分比后，系统使用同步方式刷盘，默认值时30
    • vm.dirty_bytes，当内存中的脏数据超过这个字节数后，会使用同步方式刷盘
• 分析
  • 通过调整脏数据的刷盘阈值来控制
    • vm.dirty_expire_centisecs，定义脏数据过期时间，超过这个时间后，脏数据会被异步刷盘
    • vm.dirty_writeback_centisecs，系统周期性的启动线程来检查是否需要刷盘
  • 查看系统当前脏页数量
    • cat /proc/vmstat | egrep "dirty|writeback"

禁用透明大页（Transparent Hugepages）

• 简述
  • 透明大页是Linux的一个内核特性，它通过更有效地使用处理器地内存映射硬件来提高性能
  • 禁用透明大页能略微提升程序性能，开启时可能对程序产生负面影响，甚至严重的内存泄露
  • 默认情况下是启用的
  • 目前许多项目都是建议禁用透明大页的，例如:Oracle、MongoDB
• 相关命令
  • 禁用透明大页
    • echo never| sudu tee /sys/kernel/mm/transparent_hugepage/enabled
  • 查看是否开启透明大页
    • cat /sys/kernel/mm/transparent_hugepage/enabled
    • [always] madvise never，always代表开启

索引层

使用全局模板

• 对索引级别的全局设置信息编写到一个模板中，并让这个模板匹配全部索引"*"，这个模板称为全局模板

索引轮转

• 对持续增加的索引，如果不要让这个索引持续增大，可以按照特定规则（时间、地区、分类等）以一定的频率生成索引。同时将索引设置写入模板，让模板匹配这一系列的索引，还可以为索引生成一个别名关联部分索引

避免热索引分片不均匀

• ES的分片策略是尽量保持各个节点数量大致相同
• 新加入集群的节点，没有分片时，此时新创建的索引分片会集中在新节点上，这导致新节点拥有太多热点数据，该节点可能会面临巨大的写入压力
• 通过控制单个节点上存储的该索引的分片总数，使索引分片在节点上分布的更均匀一些

副本数选择

• 硬件配置较好的情况下，将副本数number_of_replicas设置为1即可，这样每个分片存在两个副本
• 如果对搜索请求的吞吐量要求较高，则可以适当增加副本数量，让搜索操作可以利用更多的节点
• 如果在项目初始阶段不知道多少副本数够用，则可以先设置为1，后期再动态调整
• 对副本数的调整只会涉及数据复制和网络传输，不会重建索引，因此代价较小

Force Merge

• 对冷索引执行force merge会有许多好处，可以选择在系统的空闲时段对不再更新的只读索引执行Force Merge
  • 单一的分段比众多分段占用的磁盘空间更小一些
  • 可以大幅减少进程需要打开的文件fd
  • 可以加快搜索过程，因为搜索需要检索全部分段
  • 单个分段加载到内存时也比多个分段更节省内存占用
  • 可以加快索引恢复速度

Shrink Index

• Shrink API允许减少索引地分片数量，结合Force Merge API，可以显著减少索引地分片和Lucene分段数量

Close索引

• 如果有些索引暂时不使用，则不会再有新增数据，也不会有对它的查询操作，但是可能以后会用而不能删除，那么可以把这些索引关闭，在需要时再打开
• 关闭的索引除存储空间外不占用其它资源
• 操作命令
  • post {host}/{index_name}/_close
  • post {host}/{index_name}/_open

延迟分配分片

• 在节点离开集群时，调整节点离线后分片重新分配的延迟时间

小心地使用fielddata

客户端

• 使用REST API而非Java API

  • 由于Java API引起版本兼容性问题，以及微弱到可以忽略地性能提升，Java API将在未来地版本中废弃
  • 客户端最好选择REST API作为客户端，而不是Java API

• 注意429状态码

  • bulk请求放入ES的队列，当队列满时，新请求被拒绝，并给客户端返回429状态码
  • 产生429错误是因为ES来不及处理，一般是由于写入端的并发过大导致的，建议适当降低写入并发
  • 客户端收到429状态码，需要处理bulk请求中部分写入成功、部分写入失败的情况，并对失败的数据进行重试写入，而不是全部数据

• curl的HEAD请求

  • 正确的方式
    • curl -I {host}/twitter/_doc/0
    • 使用-I参数curl会将HTTP方法设置为HEAD，并在接收到服务器返回的HTTP头部信息后关闭TCP连接
  • 错误的方式
    • curl -X HEAD {host}/twitter/_doc/0
    • curl -X HEAD只是将HTTP头部的方法设置为HEAD，还会等待服务器返回body

• 了解你的搜索计划

  • 我们需要直到一个搜索操作可能命中多少分片，它执行的任务复杂性有多大，聚合范围有多大等情况
  • 可以使用Profile API分析会命中哪些分片，每个分片执行的查询时间等细节

• 为读写请求设置比较长的超时时间

  • 读写操作都有可能是比较长的操作，为客户端请求设置的超时时间应该尽量长。因为即使客户端断开连接，ES任然会在后台请求处理完；如果超时设置比较短，则在密集请求时会对ES造成非常大的压力

读写

• 避免搜索操作返回巨大的结果集
  • 由于协调节点的合并压力，所有搜索系统都会限制返回的结果集大小
  • 如果确实需要很大的结果集，则应该使用Scroll API
• 避免索引巨大的文档
  • ES会拒绝索引超过http.max_context_length设置的值大小的文档，可以增加这个值，但Lucene任然有2GB的限制
  • 大型文档给网络、内存和磁盘造成了更大的压力，因此可能要重新考虑信息的单位
• 避免使用多个_type
  • _type本来是用于区分存储到同一个索引中的不同格式的数据，但是实际上面对这种情况应该用不同的索引解决，而不是在同一个索引中使用不同的_type
  • 从ES6.0开始，索引只允许存在一个_type，7.0版本后将完全废弃了_type的概念
• 避免使用_all字段
  • 从6.0开始，_all字段默认被禁用，并且不建议使用
  • 此类需求可以通过mapping中的copy_to参数创建自定义的_all字段
• 避免将请求发送到同一个协调节点
  • 无论索引文档还是执行搜索请求，客户端都应该避免将请求发送到固定的某个或少数几个节点
  • 少数几个协调节点作为整个集群对外的读写节点的情况下，它们很可能承受不了那么多的客户端请求
  • 尤其是搜索请求，协调节点的合并及排序会占用比较高的内存和CPU，聚合会占用更多内存，因此会导致给客户端的返回慢，甚至导致节点OOM
  • 合理的将请求轮询发送到集群所有节点
    • 如果使用REST API，则可以在构建客户端的客户端对象时传入全部节点列表
    • 如果在前端或脚本中访问ES集群，则可以部署到LVS，客户端使用虚IP，或者部署到Nginx使用反向代理

控制搜索相关度方式

• 常规方式
• 通过脚本控制评分
  • 例如：编写一个自定义脚本，该脚本返回评分值，该分值与原分值进行加法等运算，从而完全控制了评分算法

磁盘使用量优化措施

• 禁用对你来说不需要的特性
  • 不需要用于过滤的字段，可以不给该字段建立索引
  • text类型的字段会在索引中存储归一因子（normalization factors，norms），以便对文档进行评分，如果只需要在文本字段上进行匹配，而不关心生成的得分，则可以配置ES不将norms写入索引
  • text类型得字段默认情况下也在索引中存储频率和位置。频率用于计算得分，为止用于执行短语(phrase)查询，如果不需要允许短语查询，则可以告诉ES不索引位置
• 禁用doc values
  • 所有支持doc value得字段都默认启用了doc value。如果确定不需要对字段进行排序或聚合，或者从脚本访问字段值，则可以禁用doc value以节省磁盘空间
• 不要使用默认的动态字符串映射
  • 默认的动态字符串映射会把字符串类型的字段同时索引为text和keyword。如果只需要其中之一，则显然是一种浪费。通常，id字段只需要作为keyword类型进行索引，而body字段只需作为text类型进行索引
• 观察分片大小
  • 较大的分片可以更有效地存储数据，为了增加分片大小，可以在创建索引地时候设置较少地主分片数量，或者使用shrink API来修改现有索引地主分片数量
  • 较大地分片也有缺点，例如较长地索引恢复时间
• 禁用_source
  • _source字段存储文档地原始内容。如果不需要访问它，则可以将其禁用
• 使用best_compression
  • _source和设置为store：true地字段占用磁盘空间都比较多。默认情况下，它们都是被压缩存储地。可以通过使用best_compression来执行压缩比更高地算法:DEFLATE。但这会占用更多地CPU资源
• fource Merge
  • 使用_forcemerge API来对分段执行合并操作
• 数值类型长度够用就好
  • 为数值类型选择地字段类型也可能会对磁盘使用空间产生较大地影响，每个数据类型地字节长度是不同的，为业务选择够用的最小数据类型，可以节省磁盘空间
• 使用索引排序来排列类似的文档
  • 默认情况下，文档按照添加到索引中的顺序压缩在一起的。如果启用了索引排序，那么它们将按照排序压缩。对具有相似结构、字段和值的文档进行排序可以提高压缩比