admin 管理员组文章数量: 887021
es。。。。
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 的计算量和耗费的内存都会导致查询瓶颈
五、优化
1、减少 Refresh 的次数
Lucene 在新增数据时，采用了延迟写入的策略，默认情况下索引的refresh_interval 为1 秒。
Lucene 将待写入的数据先写到内存中，超过 1 秒（默认）时就会触发一次 Refresh，然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。
如果我们对搜索的实效性要求不高，可以将 Refresh 周期延长，例如 30 秒。
这样还可以有效地减少段刷新次数，但这同时意味着需要消耗更多的 Heap 内存。
2、加大 Flush 设置
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘，当 Translog 的数据量达到 512MB 或者 30 分钟时，会触发一次 Flush。
index.translog.flush_threshold_size 参数的默认值是 512MB，我们进行修改。
增加参数值意味着文件缓存系统中可能需要存储更多的数据，所以我们需要为操作系统的文件缓存系统留下足够的空间。
3、减少副本的数量
ES 为了保证集群的可用性，提供了 Replicas（副本）支持，然而每个副本也会执行分析、索引及可能的合并过程，所以 Replicas 的数量会严重影响写索引的效率。
当写索引时，需要把写入的数据都同步到副本节点，副本节点越多，写索引的效率就越慢。
如果我们需要大批量进行写入操作，可以先禁止Replica复制，设置
index.number_of_replicas: 0 关闭副本。在写入完成后， Replica 修改回正常的状态。
本文标签： ES
版权声明：本文标题：es。。。。 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1687892295h154133.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论