前言
Kenna 是一家网络设备安全管理公司。这家公司通过收集客户公司的网络设备的漏洞数据，进行特征分析和风险识别，帮助其客户识别优先级最高的安全风险，并通知客户快速解决。网络设备及安全漏洞的原始数据存储在MySQL里面，用于分析的数据被抽取并存储在了ES中，如下图：
问题
在2015年，Kenna的ES中集群存储了5亿个documents，其中有每天参与计算处理的document个数为1百万。在那时，这样的处理能力已经是该ES集群所能处理的上限了，已经无法胜任更大的数据规模的处理需求了。经过Kenna的工程师的性能优化，ES集群存储40亿个docment的情况下，每天可以处理超过2亿的docment。下面看看他们是怎么从Index、Search两方面做性能优化的。
Index(写)调优
前面已经提到，需要从MySQL的原始表里面抽取并存储到Index，而MySQL的原始数据也是经常在变化的，所以快速写入ES、以保持ES和MySQL的数据及时同步也是很重要的。Kenna的工程师主要是下面几个方面优化来提高写入的速度：
1.调整索引的刷新间隔
该参数缺省是1s，强制ES每秒创建一个新segment，从而保证新写入的数据近实时的可见、可被搜索到。在Kenna，该参数被调整为30s，降低了刷新的次数，把刷新操作消耗的系统资源释放出来给index操作使用。
PUT /my_index/_settings
{
"index" : {
"refresh_interval": "30s"
}
}
这种方案以牺牲可见性的方式，提高了index操作的性能。
2.批处理
批处理把多个index操作请求合并到一个batch中去处理，和mysql的jdbc的bacth有类似之处。如图：
Kenna的场景中，每批1000个documents是一个性能比较好的size。每批中多少document条数合适，受很多因素影响而不同，如单个document的大小等。ES官网建议通过在单个node、单个shard做性能基准测试来确定这个参数的最优值。
批处理方案帮助Kenna撑过了一年的数据增长。到了后期，ES又出现了index操作的性能问题。在index操作的高峰时段，node的CPU超负荷运转、并出现了一堆429（TOO_MANY_RWQUEST）的错误。
3.Document的路由处理
当对一批中的documents进行index操作时，该批index操作所需的线程的个数由要写入的目的shard的个数决定。看下图：
上图中，有2批documents写入ES, 每批都需要写入4个shard，所以总共需要8个线程。如果能减少shard的个数，那么耗费的线程个数也会减少。例如下图，两批中每批目的shard个数都只有2个，总共线程消耗个数4个，减少一半。
值得注意的是线程数虽然降低了，但是单批的处理耗时可能增加了。和提高刷新间隔方法类似，这有可能会延长数据不见的时间。
Search(读)调优
在存储的Document条数超过10亿条后，我们看看Kenna工程师如何进行搜索调优的。
1.数据分组
很多人拿ES用来存储日志，日志的索引管理方式一般基于日期的，基于天、周、月、年建索引。如下图，基于天建索引：
当搜索单天的数据，只需要查询一个索引的shards就可以。当需要查询多天的数据时，需要查询多个索引的shards。这种方案其实和数据库的分表、分库、分区查询方案相比，思路类似，小数据范围查询而不是大海捞针。
Kenna一开始的方案是建一个index，当数据量增大的时候，就扩容增加index的shard的个数。当shards增大时，要搜索的shards个数也随之显著上升。
基于数据分组的思路，Kenna基于client进行数据分组，每一个client只需依赖自己的index的数据shards进行搜索，而不是所有的数据shards，大大提高了搜索的性能，如下图:
2.使用Filter替代Query
在搜索时候使用Query，需要为Document的相关度打分。使用Filter，没有打分环节处理，做的事情更少，而且filter理论上更快一些。
如果搜索不需要打分，可以直接使用filter查询。如果部分搜索需要打分，建议使用'bool'查询。这种方式可以把打分的查询和不打分的查询混在一起使用，如：
GET /_search
{
"query": {
"bool" : {
"must" : {
"term" : { "user" : "kimchy" }
},
"filter": {
"term" : { "tag" : "tech" }
}
}
}
}
3.ID字段定义为Keywords
一般情况，如果ID字段不会被用作Range 类型搜索字段，都可以定义成keywords类型。这是因为keywords会被优化，以便进行terms查询。Integers等数字类的mapping类型，会被优化来进行range类型搜索。
Kenna在将integers改成Keywords类型之后，搜索性能提升了30%。
4.别让用户的无约束的输入拖累了ES集群的性能
Kenan的工程师通过监控发现所有node的CPU 使用及其负载突然异常飙高。通过对Slow Logs分析发现，用户查询输入的条件中夹带了很多'OR'语句以及通配符“*”开头的字符串，如下图
为了不让用户无约束的查询语句拖累ES集群的查询性能，可以限制用户用来查询的keywords。对于可以用来查询的keyworkds，也可以写成文档来帮助用户更正确的使用。
