您好,登录后才能下订单哦!
从2014年到现在接触ES(Elasticsearch)已经两年多了,感触良多尤其ES的开盒即用特性完全区别于之前接触复杂的hadoop和solor。ES不需要你对它了解就能很快入门,而且ES的实时搜索,自动拓展,自愈功能深深吸引我。最近很多朋友也开始使用向我问了很多常见问题,我在这总结了一些使用中踩过的坑希望大家对ES有更多的了解。
简介
Elasticsearch是基于Lucene开发的一个准实时搜索服务,搜索延时在秒级。ES存储主要通过自身解析json数据,然后json里面的key映射为Lucene里面的字段,使用lucene进行搜索和索引。ES不仅支持普通的全文搜索和按词搜索,还支持模糊匹配,近义词搜索,聚合,排序,geo等特性。ES的开源特性也使得它社区活跃,版本迭代更新迅速,现在主要分为2.0和5.0两个大版本,建议大家使用最新的5.0版本会更容易升级和获取一些更高级的特性。
下面是一些上线或者线上使用Elasticsearch需要了解的特性
es主要依赖于硬盘和内存,所以对CPU要求不高,一般8核就行,如果并发比较多可以适当增加。
硬盘决定你es写入读取数据速度,磁盘建议用15k的机械硬盘,并配置为raid0,如果集群节点<5个,请使用raid5,这样保证一个硬盘故障不会影响服务。虽然es本身可以通过分片去保证数据的冗余,但是es每个节点大量数据爬行还是对较小的集群有一定影响。(土豪直接上SSD,需要正确配置I/O调度程序,阵列卡建议>h710,否则就像ssd跑车上安装一个拖拉机引擎)
1. ES的内存使用分为两部分ES缓存和Lucene通过内核缓存加速一些数据。
2 . 如果服务器内存 `nG > 64G`,ES的内存尽量设置低于32G,建议最大31G. 因为es使用“内存指针压缩”技术,一旦内存内存大于32G这项技术将失效,内存有效使用只有原来的60%~70%。你不必为内存浪费而担心,因为lucene会通过系统把一些聚合和排序的数据缓存起来方便你快速查询使用。
3 .如果服务器内存 `nG < 64G`,建议给ES分配 内存 (n-2)/2G. 首先2G是给系统预留,然后es和lucene
4 . 如果你想继续你的实时查询,尽量不要使用swap(交换分区),建议关闭系统swap使用
建议千兆光纤,高速网络可以保证集群节点故障后快速恢复,以及添加节点后快速再平衡。
尽量不要跨机房,除非需要灾备,或者有足够的带宽,否则你将迎来es节点数据同步的无限等待。
因为所有es节点需要实时同步‘索引列表’,‘文档类型’,‘字段名’等信息,所以在节点数固定的情况下索引,字段名等不要太多否则会给es的master节点造成压力。
简单举例:我要保存用户提交字段和信息,各个字段名因为是动态生成,理论上是无上限的,但是es的master要实时的同步这些字段信息到每个节点,如果现在只有100个字段还好,要是有1000个字段就会产生问题,如果有2000个字段就严重到无法使用了,当然索引的数量也是同样的意义,
es的每个索引默认总计10个分片,5个主分片,每个主分片对应一个副分片。
1 . 当然很多情况下这个无法满足你实际需求,例如你的集群有8个节点,计划单个索引超过100亿条数据,为了让这个索引查询速度快一点,你可以增加索引分片数量:1.增加主副分片对数,增加副分片的数量。这样不仅加速搜索还增加了数据的冗余。
2 . 一些只读的索引可以使用‘optimize的API’进行把每个索引合并为一个单独数据段,这样可以节省资源加速操作,但是需要注意这样会消耗一定IO,如果当前节点请求繁忙,不要进行此类操作。
3 . 在使用索引的时候尽量使用索引别名,在以后索引重建或者索引名变更时避免宕机维护。
1. 并发请求不要一次太多,否则超过es内部队列长度将失败。
2. 如果一次一定要提交太多任务写入尽量添加失败判断,一旦失败等待3~5秒重试操作,否则数据将丢失。
3.文档尽量一次写入不要更改和删除,因为es的更改和删除只是给旧数据做了一个标签,查询的时候依然会查询匹配,只是不在结果中计算。
故障处理
如果有ES集群单节点掉出集群不要慌张ES有自愈的能力,你只需要保证集群稳定,磁盘充足即可自动修复。
如果集群突然大多节点掉出集群,且出现分片丢失,那你需要考虑分片丢失是否能够接受,如果不能你可以通过同时停止全部节点,并启动全部节点进入时间门来尝试恢复全部数据。
正常情况下少数节点掉出集群,导致一些只读的分片丢失,可以把这些掉出的节点重新加入回集群即可恢复分片。
http://nginxs.blog.51cto.com/
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。