标签：os 大批量 数据 cache 写入 shard ElasticSearch 磁盘 优化

ElasticSearch突击训练

ES的构成

index：索引，一个完整数据的基本单位是索引

type：7.0后无type，在index上有细微差别

mapping: 映射，建表语句的字段类型映射

document：文档，一条数据为一个文档

field：文档的每个字段

ES的分布式框架原理

集群模式是什么样的

es的底层是基于lucene的，分布式的核心思想就是在多台机器上启动es进程实列，组成一个es集群，每个实列存在多个shard，每个shard有多个replica shard(副本，与promary shard在不同的实列上)。一个index的数据存在分布式存在多个shard上。

master宕机后怎么办

如master（进程02）宕机之后，会在剩下的机器中重新选举一台作为master，并将挂掉的master上的primary shard 的replica shard 提拔为primary shard。

当宕机的master（进程02）重新启动了，会被现阶段的matser发现，并标识为普通机器，然后调整新加入的primary shard 为replica shard 。

ES写入数据的工作原理是什么？es查询数据的原理

写入数据只能去primary shard 写入，但是可以从replica shard 和 primary shard 读取

分布式下写入操作

1. 客户端发送的请求到达任意一个node，成为coordinate note(协调节点)
2. coordinate note对document进行路由，将请求转发到对应的node（primary shard 对应的节点）
3. primary shard 对应的写完文档后，将数据同步到replica shard
4. coordinate note发现数据全部写完了之后，返回响应给客户端

写入的缓存机制

1. 写入时会先写入到内存buffer与translog（日志）文件中，此时客户端搜索不到

2. 当内存buffer满了，或每隔一段时间（默认1s），es会做refresh操作，将buffer中的数据写入一个新的 segment file中（磁盘上）

   实际上，操作系统中，磁盘存在一个os cache（系统缓存），也就是说写入磁盘之前，会先写入os cache，即 os cache -> segment file,注意：在os cache中已经可以被搜索到了，且refreshe操作，也可以通过调用api来强制刷新

3. 当traanslog越来越大，达到一定的长度之后，就好触发commit操作

   commit：

   1. 首先将所有buffer写入磁盘，清空buffer
   2. 写入一个commit point到磁盘，里面标识着这个commit point对应的所有segment file
   3. 强行将os cache中所有的数据写入磁盘中
   4. 将现有的translog清空，再重启一个新的translog，此时commit操作完成。

   默认30分钟一次commit，但是translog过大，也会触发commit，整个commit过程，叫做flush操作，我们可以手动执行flush操作，也就是将所有的os cache的数据刷到磁盘文件中

4. 如果时删除操作，commit的时候会生成一个.del文件，里面将某个doc标识为deleted状态，搜索的时候会过滤这个doc

5. 如果是更新操作，就是将原来的标识为deleted状态，再写入一条新的数据

6. buffer 每次refresh一次，都会产生一个新的segment file，所以默认情况下是1秒一个segment file，segement file越来越多，此时定期merge

7. 每次merge时候，将多个segment file合并成一个，同事会把标记为deleted的doc物理清除，然后再将新的segment file写入磁盘，这里会写一个commit point，标识所有新的segment file，然后打开segment file供搜索使用，同时删除旧的segment file

translog的作用

translog日志文件，就是再执行commit操作之前，数据要么停留再buffer中，要么停留再os cche中，无论是buffer还是os cache都是内存，一旦机器死了，内存中的数据旧没了，所以写入translog日志中的数据，是为了防止机器宕机了之后数据丢失，es重启之后会自动读取translog日志文件的数据，恢复到内存buffer和os cache中

translog 其实也是先写入os caache的，默认5秒一次刷新到磁盘中，所以默认情况下，可能有5秒的数据停留在buffer或translog 文件的os cache中，若此时机器挂了，会丢失5秒的数据，若设置为实时的，则每次写入操作直接写入磁盘，性能会差很多

写入数据的四种概念

refresh：1s可见，此时数据再os cahce上（先如os cache，再入seagment file）

flush：translog过长或30分钟，强行全部写入磁盘上，产生commit point

translog：数据直接写入buffer和translog中，translog5秒一次同步到磁盘

merge：segment file过大后，多个合成一个，产生commit point

写入与查询的路由

一条数据的最终存储为一个document， 每个document都是有一个唯一id(可以自己指定字段，否则es自动分配)，路由时根据documentId做hash路由到对应的primary shard上

分布式下读取指定doc

1. 客户端任意请求到一个node，成为coordinate node
2. coordinate node对doc进行路由，将请求转发到对应的node，此时使用round-robin（随机轮询算法）再所有的primary shard 和 replica shard 中做负载均衡访问查询
3. 接收请求的node返回给document给coordinate note
4. 返回给客户端

分布式下全文检索

1. 客户端任意请求到一个node，成为coordinate node
2. 将请求发给每一个shard（primary 或 replica ），再本地的shard做全文检索
3. coordinate node拿到所有的数据，再在本地做一次匹配，返回最匹配的结果

ES在数据很大的情况下（数十亿级别）如何提高查询性能

大数据量下的搜索预热

数据量很大（十几亿）的情况下，第一次很慢，之后的搜索才变快

filesystem cache

写入磁盘的数据先写入os_cache中，这块cache对搜索的影响特别大，客户端请求数据时，在读取磁盘文件时，会先去OS cache中查找数据，如果OS cache中没有数据，再去磁盘中找，如果找到了数据，则缓存到OS cache中，再返回给前端

即：

​ 第一次：客户端请求 --> ES集群 --> ES Shard --> OS Cache --> 磁盘 --> 写入OS Cache --> 返回前端

​ 第二次：客户端请求 --> ES集群 --> ES Shard --> OS Cache --> 返回前端

所以ES的查询性能特别依赖于底层的filesystem cache，这就意味着内存越大，更多的数据能缓存到内存中，对搜索查询的性能提升越大

压测显示：只要走磁盘：查询时间肯定上秒，以至于 5 秒，10秒，但是走fileSystem cache: 几十毫秒级别

优化点

1. 内存至少是数据总大小的一半
2. es中只存少量的数据（只写入需要搜索的数据）
3. 使用es + hbase（海量数据的在线存储，不能做复杂查询，只能支持简单查询，例：id查询） 这种架构，需要搜索的数据写入es，其它展示的数据写入hbase

缓存预热

当数据量还是超过fileSystem cache的一倍，我们可以对数据做预热，就是把热门数据预先写入缓存中，减少去磁盘读取的次数

优化点

1. 后台写个脚本，每隔一段时间去搜索热门的数据，预先吧热门数据刷到内存中

冷热分离

es做水平拆分，将访问不是很频繁的冷数据，单独写一个索引，然后将访问频繁的热数据单独写一个索引，然后对热数据索引做预热，劲量不让冷数据冲刷

document模型设计

设计ES的数据模型，尽量不要走关联查询，即单个索引的mapping中，就包含了所有查询所需要的数据，不要走多索引关联查询

分页优化

ES的分页性能比较差，ES的数据存储是分布式的，所以查询分页的数据必须到每个shard上查询前面所有的数据，在根据条件做分页排序，再拿出来数据，所以，查询的页数越深，越难拿到数据

优化点

1. 不允许深度分页/默认深度分页很差 设计上避免
2. 类似于下拉刷新数据（微博中刷新一页一页的这种情况），可以使用 scroll api（滚动搜索），scroll 会生产数据的快照，分页的时候使用游标，这个性能是非常高的，但是只能适用于微博这种形式（因为微博是一页一页往后面翻，而不是像其他分页那样是跳页操作）

ES生产集群部署架构是什么？每个索引的数据量多大，多少个分片？

目前配置：4C 16G * 3

三个索引：最大的索引400W数据，2.8G，优化后。。。。

后续问题

评分相关（TF/IDF）

deep paging

千万数据的批处理

跨机房多集群同步

搜索结果优化

标签：os,大批量,数据,cache,写入,shard,ElasticSearch,磁盘,优化
来源： https://blog.csdn.net/weixin_46825429/article/details/116357118

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。