标签：Search Elastic buffer shard file 相关 数据 节点 es
es 怎么解决查询慢的问题？
1、只存关键数据，其他数据存入hbase,查询的时候根据id 查询一批数据，然后根据id的范围去hbase中查询，效率会相当高。
2、因为es有一个file system cache ,第一次查询数据时，其实是去磁盘读，然后刷进缓存的，所以缓存要存热点数据，内存容量有限，，我们可以先预热一下，比如后台有一个刷到缓存的数据进程，，这样每次查询都会去缓存中查询。。
倒排索引？
字典表（内存中 hash表形式存储）
倒排列表 磁盘中以跳表的形式存储（链表+索引的形式）
es 写数据过程：
1、写数据过程
-
客户端通过hash选择一个node发送请求，这个node被称做coordinating node（协调节点），
-
协调节点对docmount进行路由，将请求转发给到对应的primary shard
-
primary shard 处理请求，将数据同步到所有的replica shard
-
此时协调节点，发现primary shard 和所有的replica shard都处理完之后，就反馈给客户端。
2、写数据的底层原理
-
在到达primary shard的时候 ，数据先写入内存buffer ， 此时，在buffer里的数据是不会被搜索到的同时生成一个translog日志文件 ， 将数据写入translog里
-
如果内存buffer空间快man满了，就会将数据refresh到一个新的segment file文件中，而且es里每隔1s就会将buffer里的数据写入到一个新的segment file中，这个segment file就存储最最近1s中buffer写入的数据，如果buffer里面没有数据，就不会执行refresh操作，当建立segment file文件的时候，就同时建立好了倒排索引库。
-
在buffer refresh到segment之前 ，会先进入到一个叫os cache中，只要被执行了refresh操作，就代表这个数据可以被搜索到了。数据被输入os cache中，buffer就会被清空了，所以为什么叫es是准实时的？NRT，near real-time，准实时。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1秒之后才能被看到。还可以通过es的restful api或者java api，手动执行一次refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。
-
就这样新的数据不断进入buffer和translog，不断将buffer数据写入一个又一个新的segment file中去，每次refresh完buffer清空，translog保留。随着这个过程推进，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。translog也是先进入os cache中，然后每隔5s持久化到translog到磁盘中，
-
commit操作，第一步，就是将buffer中现有数据refresh到os cache中去，清空buffer 每隔30分钟flush
-
es也有可能会数据丢失 ，有5s的数据停留在buffer、translog os cache, segment file os cache中，有5s的数据不在磁盘上，如果此时宕机，这5s的数据就会丢失，如果项目要求比较高，不能丢失数据，就可以设置参数，每次写入一条数据写入buffer，同时写入translog磁盘文件中，但这样做会使es的性能降低。
-
如果是删除操作，commit操作的时候就会生成一个.del文件，将这个document标识为deleted状态，在搜索的搜索的时候就不会被搜索到了。
-
如果是更新操作，就是将原来的document标识为deleted状态，然后新写入一条数据
-
buffer每次refresh一次，就会产生一个segment file，所以默认情况下是1秒钟一个segment file，segment file会越来越多，当躲到一定程度的时候，es就会自动触发merge(合并)造作，将所有segment file文件 merge成一个segment file，并同时物理删除掉标识为deleted的doc，
3、es读取过程
-
客户端发送get请求到任意一个node节点，然后这个节点就称为协调节点，
-
协调节点对document进行路由，将请求转发到对应的node，此时会使用随机轮询算法，在primary shard 和replica shard中随机选择一个，让读取请求负载均衡，
-
接收请求的node返回document给协调节点，
-
协调节点，返回document给到客户端
4、 搜索过程
-
客户端发送请求到协调节点，
-
协调节点将请求大宋到所有的shard对应的primary shard或replica shard ；
-
每个shard将自己搜索到的结果返回给协调节点，返回的结果是dou.id或者自己自定义id，然后协调节点对数据进行合并排序操作，最终得到结果。
-
最后协调节点根据id到个shard上拉取实际 的document数据，左后返回给客户端。
es 怎么保证高可用？
index -> type -> mapping -> document -> field
类比Mysql:
index：类比mysql里的一张表
type：类比Hibernate 中多个同类Class同时映射到一个表中的情境，type就是各个Class。index里可以有多个type。
mapping：类比Hibernate的映射。这个type的表结构的定义，定义了这个type中每个字段名称，字段是什么类型的，然后还有这个字段的各种配置
document：类比表中的一条条记录。
field: 类比一条记录的各个字段。
shard
一个索引，这个索引可以拆分成多个shard，每个shard存储部分数据。
这个shard的数据实际是有多个备份，就是说每个shard都有一个primary shard，负责写入数据，但是还有几个replica shard。
primary shard写入数据之后，会将数据同步到其他几个replica shard上去。
Master
es集群多个节点，会自动选举一个节点为master节点。
这个master节点其实就是干一些管理的工作的，比如维护索引元数据拉，负责切换primary shard和replica shard身份 之类的。
要是master节点宕机了，那么会重新选举一个节点为master节点。
如果是非master节点宕机了，那么会由master节点，让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。
急着你要是修复了那个宕机机器，重启了之后，master节点会控制将缺失的replica shard分配过去，同步后续修改的数据之类的，让集群恢复正常
标签：Search,Elastic,buffer,shard,file,相关,数据,节点,es 来源： https://blog.csdn.net/huanglei_hacker/article/details/121418681
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。