标签：总结 node doc shard ElasticSearch 原理 数据 id es

ES原理总结

—ES写数据：
ES里写的流程，有四个底层的核心概念：refresh、flush、translog、merge

—ES读数据的过程

查询—GET到某一条数据
（1）可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。
（2）客户端发送请求到任意一个 node，成为 coordinate node 。
（3）coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
（4）接收请求的 node 返回 document 给 coordinate node 。
（5）coordinate node 返回 document 给客户端。

—搜索 全文检索
客户端发送请求到协调节点
协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ，都可以。

query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

–ES在数据量很大的情况下如何提高查询效率

（1）性能优化的杀手锏 – filesystem cache
减少数据量仅仅放要用于搜索的几个关键词即可，尽量写入的数据跟es机器的filesystem cache是差不多的就可以了。

（2）数据预热
把搜索频率比较高的数据定时放到filesystem cache中。

（3）冷热分离
做类似mysql的水平拆分，就是将大量的访问很少，单独写一个索引，然后将很频繁热数据单独写一个索引，频繁热数据全部放到缓存中，冷数据放到磁盘上。

（4）document模型设计
设计es中的数据模型

（5）分页的性能优化

a、不允许深度分页（默认深度分页性能很差）
b、类似于app中的不断一页一页的，不能挑选页跳转，也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据
可以用scroll api

简单介绍下生产环境es集群的架构情况

（1）es生产集群部署了5台数据，每台机器是6核64G的，集群总内存是320G
（2）es集群的日增量数据大概是2000万条数据，每天日增量数据大概是500MB,每月增量数据大概是6亿15G，系统已经几个月，大概数据总量是100G左右。
（3）目前线上大概是有5个索引。每个索引的数据量大概是20G，所以这个数据量之内，每个索引分配的是8个shard,比默认的5个shard多个3个shard。

标签：总结,node,doc,shard,ElasticSearch,原理,数据,id,es
来源： https://blog.csdn.net/mdddaad/article/details/110950987

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