es。。。。

slipknotM_

已于 2023-08-11 10:37:14 修改

阅读量164

点赞数

文章标签： elasticsearch 大数据搜索引擎

于 2023-03-28 17:51:30 首次发布

本文链接：https://blog.csdn.net/slipknotM_/article/details/129819945

版权

text：

会分词，然后进行索引

支持模糊、精确查询

不支持聚合

分词器默认standard ，对于中文来说就是按字分词

支持fields属性，可以在fields中添加keyword子类型，以实现精确检索

keyword：

不进行分词，直接索引

支持模糊、精确查询

支持聚合

支持按字数建立索引，以便节约索引空间

请添加图片描述

接近实时（NRT）ES写入的数据会先写到一个内存bufferr中去(在buffer里的时候数据是搜索不到的)，然后每隔默认是一秒会刷到os cache系统缓存。

分片不能修改，副本可以

FST(Finite State Transducers)的压缩技术

Frame Of Reference 增量编码压缩，将大数变小数，按字节存储

联合索引用跳表skiplist

Elasticsearch 的 master 选举流程？

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）
和Unicast（单播模块包含-一个主机列表以控制哪些节点需要ping通）这两部分。
对所有可以成为master的节点（node master: true）根据nodeId字典排序，每次选举每个节点都把自
己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，
那这个节点就是master。否则重新选举一直到满足上述条件。
master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

Elasticsearch 集群脑裂问题？
“脑裂”问题可能的成因：

网络问题：集群间的网络延迟导致一些节点访问不到master, 认为master 挂掉了从而选举出新的master,并对master上的分片和副本标红，分配新的主分片。
节点负载：主节点的角色既为master又为data,访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
内存回收：data 节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

脑裂问题解决方案：

减少误判：discovery.zen ping_ timeout 节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。
选举触发：discovery.zen.minimum. _master_ nodes:1，该参數是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个數大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为(n / 2) +1, n为主节点个数（即有资格成为主节点的节点个数）。
角色分离：即master节点与data节点分离，限制角色
主节点配置为：node master: true，node data: false
从节点配置为：node master: false，node data: true

读取数据

客户端发送任何一个请求到任意一个 node，成为 coordinate node

coordinate node 对 document 进行路由，将请求 rr 轮训转发到对应的 node，在 primary shard 以及所有的 replica 中随机选择一个，让读请求负载均衡，

接受请求的 node，返回 document 给 coordinate note

coordinate node 返回给客户端

搜索过程

客户端发送一个请求给 coordinate node

协调节点将搜索的请求转发给所有的 shard 对应的 primary shard 或 replica shard

query phase：每一个 shard 将自己搜索的结果（其实也就是一些唯一标识），返回给协调节点，有协调节点进行数据的合并，排序，分页等操作，产出最后的结果

fetch phase ，接着由协调节点，根据唯一标识去各个节点进行拉去数据，最总返回给客户端

注意事项

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的

同样的道理，对于 String 类型的字段，不需要 analysis 的也需要明确定义出来，因为默认也是会 analysis 的

选择有规律的 ID 很重要，随机性太大的 ID(比如 java 的 UUID)不利于查询

上面看到的压缩算法，都是对 Posting list 里的大量 ID 进行压缩的，那如果 ID 是顺序的，或者是有公共前缀等具有一定规律性的 ID，压缩比会比较高；

拒绝大聚合

拒绝模糊查询

拒绝深度分野 ES 获取数据时，每次默认最多获取 10000 条，获取更多需要分页，但存在深度分页问题，一定不要使用 from/Size 方式，建议使用 scroll 或者 searchAfter 方式。scroll 会把上一次查询结果缓存一定时间（通过配置 scroll=1m 实现)，所以在使用 scroll 时一定要保证 search 结果集不要太大。

拒绝多层嵌套，不要超过 2 层，避免内存泄漏

拒绝 top》100 的潮汛 top 查询是在聚合的基础上再进行排序，如果 top 太大，cpu 的计算量和耗费的内存都会导致查询瓶颈