elasticSearch-优化篇

查询优化

建议
索引设计角度：

• 避免一个索引有过多的分片
• 控制单个分片的大小：search 20GB， log 40GB
• force merge 只读索引，较少segment数量
• 尽可能 Denormalize(反规范化) 数据，从而获取最佳的性能
  • 不使用嵌套类型对象，使用 Nested 类型的数据。查询速度会慢几倍
  • 不使用父子关系类型对象，使用 Parent / Child 关系。查询速度会慢几百倍
    查询语句角度
• 尽量将数据先行计算，然后将数据保存在es中，避免查询时使用脚本计算
• 尽量使用Filter Context， 利用缓存机制，减少不必要的算分
• 结合profile，explain API 查询慢查询原因，持续优化数据模型
• 避免使用通配符(*)开头的查询，如wildCard模糊查询。有什么方案可以替代模糊查询呢？

写入优化

建议

• 降低IO操作
  • 降低IO频率，如增大refresh频率的间隔时间
• 降低CPU和存储的开销
  • 减少不必要的分词，dov_value/fielddata, 文档的字段尽量保证相同的顺序，可以提高文 档的压缩率
• 尽可能做到写入和分片的负载均衡，实现水平扩展
• 关闭无关的功能
  • 只需要聚合不需要搜索， Index 设置成 false
  • 不需要算分， Norms设置成false
  • 关闭_source, 减少IO操作，适合指标型数据
  • 不要对字符串使用默认的 dynamic mapping。字段 数量过多，会对性能产生比较大的影响
  • Index_options 控制在创建倒排索引时，哪些内容 会被添加到倒排索引中。优化这些设置，一定程度 可以节约 CPU
• 暂时性的牺牲可靠性和实时性来提高数据写入速度
  • 牺牲可靠性：副本分片数设置成0，写入完毕再调整回去；修改transLog的配置
    • Index.translog.durability:默认是 request，每个请求都落盘。设置成 async，异步写入
    • Index.translog.sync_interval 设置为 60s，每分钟执行一次
    • Index.translog.flush_threshod_size: 默认 512 mb，可以适当调大。 当 translog 超过该值，会触发 flush
  • 牺牲搜索实时性：增加refresh Interval的时间
    * Refresh Interval：增大refresh_interval
    * 增大静态配置参数 indices.memory.index_buffer_size，默认10%会触发refresh
    

索引设计最佳

配置
分片大小：Elasticsearch官方建议一个分片的大小应该在20到40 GB左右
分片数量：分配多个分片和副本是分布式搜索功能设计的精髓，在针对索引中的文档进行搜索时提供高可用性和快速访问。主分片和副本分片之间的主要区别在于，只有主分片才能接受索引请求。副本和主分片都可以为查询请求提供服务。如果想要提高集群的写入性能的话，可以适当提高分片数量，但是要控制副本的数量。如果想要提高集群查询的qps可以提高副本的数量。

数据动态持续写入场景
如何查询分散到不同的基于时间索引的所有文档？答案是别名。可以将多个索引放入别名中，并且对该别名进行搜索会使查询就像在单个索引上一样。

Index Sorting
在Elasticsearch中创建新索引时，可以配置每个分片中的分段的排序方式。 默认情况下，Lucene不会应用任何排序。 index.sort.* 定义应使用哪些字段对每个Segment内的文档进行排序。
因为写入时已经制定了排序的顺序，那么如果在查询时使用的已经排序的字段进行分页查询，那么速度会很快，但是不会统计总数。
https://blog.csdn.net/qq_27529917/article/details/108938201

分片层面优化配置

• 在优化分片时，分片的大小、节点中有多少分片是主要考虑因素。副本分片对于扩展搜索吞吐量很重要，如果硬件条件允许，则可以小心增加副本分片的数量。
• 容量规划的一个很好的启动点是分配分片，“《深入理解Elasticsearch》强调：最理想的分片数量应该依赖于节点的数量。”其数量是节点数量的1.5到3倍。（保持一个怀疑态度）
  Elasticsearch整体层面配置
  配置Elasticsearch集群时，最主要的考虑因素之一是确保至少有一半的可用内存进入文件系统缓存，以便Elasticsearch可以将索引的hot regions保留在物理内存中。

在设计集群时还应考虑物理可用堆空间。 Elasticsearch建议基于可用堆空间的分片分配最多应为20个分片/ GB，这是一个很好的经验法则。

例如，具有30 GB堆的节点最多应有600个分片，以保持集群的良好状态。

动态设置

• 设置历史数据索引为只读状态
• 对只读状态索引，进行段合并
• 使用preference优化缓存利用率：有多个缓存可以帮助提高搜索性能，例如文件系统缓存，请求缓存或查询缓存。
  然而，所有这些缓存都维护在节点级别，这意味着如果您在拥有1个或更多副本且基于默认路由算法集群上连续两次运行相同的请求，这两个请求将转到不同的分片副本上 ，阻止节点级缓存帮助。由于搜索应用程序的用户一个接一个地运行类似的请求是常见的，例如为了检索分析索引的部分较窄子集，使用preference标识当前用户或会话的偏好值可以帮助优化高速缓存的使用。
  增加刷新间隔 refresh_interval
  默认刷新间隔为1秒。这迫使Elasticsearch每秒创建一个分段。实际业务中，应该根据使用情况增加刷新间隔，举例：增加到30秒。
  这样之后，30s产生一个大的段，较每秒刷新大大减少未来的段合并压力。最终会提升写入性能并使搜索查询更加稳定。

禁止动态分配分片
有时，Elasticsearch将重新平衡集群中的分片。此操作可能会降低检索的性能。
在生产模式下，需要时，可以通过cluster.routing.rebalance.enable设置将重新平衡设置为none。
PUT /_cluster/settings
{
“transient” : {
“cluster.routing.allocation.enable” : “none”
}
}
其中典型的应用场景之包括：

1. 集群中临时重启、剔除一个节点；
2. 集群逐个升级节点；当您关闭节点时，分配过程将立即尝试将该节点上的分片复制到集群中的其他节点，从而导致大量浪费的IO. 在关闭节点之前禁用分配可以避免这种情况。

合并多字段提升检索性能
query_string或multi_match查询所针对的字段越多，检索越慢。
提高多个字段的搜索速度的常用技术是在索引时将其值复制到单个字段中。
对于经常查询的某些字段，请使用Elasticsearch的copy-to功能。
例如，汽车的品牌名称，发动机版本，型号名称和颜色字段可以与复制到指令合并。它将改善在这些字段上进行的搜索查询性能。

充分利用近似日期缓存效果
现在使用的日期字段上的查询通常不可缓存，因为匹配的范围一直在变化。
然而，就用户体验而言，切换到近似日期通常是可接受的，并且能更好地使用查询高速缓存带来的益处。
GET index/_search
{
“query”: {
“constant_score”: {
“filter”: {
“range”: {
“my_date”: {
“gte”: “now-1h/m”,
“lte”: “now/m”
}
}
}
}
}
}

设置分片分配到指定节点
实战业务中经常遇到的业务场景问题：如何将分片设置非均衡分配，有新节点配置极高，能否多分片点过去？

某个 shard 分配在哪个节点上，一般来说，是由 ES 自动决定的。以下几种情况会触发分配动作：

● 1）新索引生成
● 2）索引的删除
● 3）新增副本分片
● 4）节点增减引发的数据均衡

ES 提供了一系列参数详细控制这部分逻辑，其中之一是：在异构集群的情为具有更好硬件的节点的分片分配分配权重。
为了分配权重，需要设置cluster.routing.allocation.balance.shard值，默认值为0.45f。
数值越大越倾向于在节点层面均衡分片。

调整熔断内存比例大小
查询本身也会对响应的延迟产生重大影响。为了在查询时不触发熔断并导致Elasticsearch集群处于不稳定状态，
可以根据查询的复杂性将indices.breaker.total.limit设置为适合您的JVM堆大小。此设置的默认值是JVM堆的70％。

特定搜索场景，增加搜索线程池配置
默认情况下，Elasticsearch将主要用例是搜索。在需要增加检索并发性的情况下，可以增加用于搜索设置的线程池，与此同时，可以根据节点上的CPU中的核心数量多少斟酌减少用于索引的线程池。
举例：更改配置文件elasticsearch.yml增加如下内容：
thread_pool.search.queue_size: 500
#queue_size允许控制没有线程执行它们的挂起请求队列的初始大小。
参考文章：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

打开自适应副本选择
应打开自适应副本选择。该请求将被重定向到响应最快的节点。
当存在多个数据副本时，elasticsearch可以使用一组称为自适应副本选择的标准，根据包含每个分片副本的节点的响应时间，服务时间和队列大小来选择数据的最佳副本。
这样可以提高查询吞吐量并减少搜索量大的应用程序的延迟。
这个配置默认是关闭的，实战打开方法：
PUT /_cluster/settings
{
“transient”: {
“cluster.routing.use_adaptive_replica_selection”: true
}
}
问题：当自适应副本选择的开关关闭时，默认的副本选择策略是什么？

通用优化建议

1. norm是索引的评分因子。 如果您不关心评分，例如，如果您从未按分数对文档进行排序，则可以禁用在索引中存储这些评分因子并节省一些空间。
2. 不要返回大结果数据集，控制pageSize的大小，如要查询所有的结果集，请使用scroll API实现。对于全量查询的场景效果会比较好。
3. 避免使用大文件：鉴于默认的http.max_context_length设置为100MB，Elasticsearch将拒绝索引任何大于该文档的文档。您可能决定增加该特定设置，但Lucene仍然有大约2GB的限制。
4. 避免将不相关的数据放在同一个索引

疑问

怎么在保证es在高写入的情况下，不产生查询延时