【摩拜招聘】ES高级工程师
工作职责：
开发、维护ES，支持各种场景需求
开发、维护fluentd/flume/kafka等大数据产品
业务推动，解决大数据、高并发下的产品需求
跟进研究业界前沿技术，推动产品技术升级
职位要求：
1. 编程能力扎实，熟悉Java/C++/go中的一种，具有良好的数据结构、算法、操作系统等计算机基本知识；
2. 熟悉ElasticSearch/Lucene开源系统，有实际开发经验者优先；
3. 具有敏捷开发、完整产品生命周期开发者优先；
4. 学习能力强，善于独立思考，思维活跃，对技术有强烈激情；
欢迎投递简历：zhengchangshuai@mobike.com
薪资20K～50K
公司属于高速成长的独角兽，非常国际化的一家公司，具体感兴趣的请发简历到邮箱
工作职责：
开发、维护ES，支持各种场景需求
开发、维护fluentd/flume/kafka等大数据产品
业务推动，解决大数据、高并发下的产品需求
跟进研究业界前沿技术，推动产品技术升级
职位要求：
1. 编程能力扎实，熟悉Java/C++/go中的一种，具有良好的数据结构、算法、操作系统等计算机基本知识；
2. 熟悉ElasticSearch/Lucene开源系统，有实际开发经验者优先；
3. 具有敏捷开发、完整产品生命周期开发者优先；
4. 学习能力强，善于独立思考，思维活跃，对技术有强烈激情；
欢迎投递简历：zhengchangshuai@mobike.com
薪资20K～50K
公司属于高速成长的独角兽，非常国际化的一家公司，具体感兴趣的请发简历到邮箱 收起阅读 »
社区日报 第54期 (2017-09-21)
2.还在为设置es的分片数量纠结？一篇文章教你全部 http://t.cn/R0vFh2G
3.基于elasticsearch nested object的关联分析 http://t.cn/R0vFMG9
编辑：金桥
归档：https://elasticsearch.cn/article/287
订阅：https://tinyletter.com/elastic-daily
2.还在为设置es的分片数量纠结？一篇文章教你全部 http://t.cn/R0vFh2G
3.基于elasticsearch nested object的关联分析 http://t.cn/R0vFMG9
编辑：金桥
归档：https://elasticsearch.cn/article/287
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
nginx和kibana/es集成
1、记录kibana的每个请求日志
2、kibana通过nginx连到es，可以实现负载均衡的请求es。
集成方法比较简单，在任意一台机器上安装nginx，nginx里配置es相关信息，kibana配置文件中的elasticsearch.url改成nginx相应的ip和监听端口即可。
nginx配置文件的主要内容如下：
upstream elasticsearch {
server 10.10.10.1:9200;
server 10.10.10.2:9200;
server 10.10.10.3:9200;
keepalive 10;
}
server {
listen 8888;
server_name hostname;
location / {
proxy_pass http://elasticsearch;
access_log_bypass_if ($request = 'HEAD / HTTP/1.1');
access_log_bypass_if ($request = 'GET /_nodes?filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip HTTP/1.1');
access_log_bypass_if ($request = 'GET /_nodes/_local?filter_path=nodes.*.settings.tribe HTTP/1.1');
access_log_bypass_if ($request_body = '{\"docs\":[{\"_index\":\".kibana\",\"_type\":\"config\",\"_id\":\"5.5.1\"}]}');
access_log_bypass_if ($request = 'GET /_cluster/health/.kibana?timeout=5s HTTP/1.1');
access_log_bypass_if ($request = 'POST /.kibana/config/_search HTTP/1.1');
access_log_bypass_if ($request = 'GET /_cluster/settings?include_defaults=true&filter_path=**.script.engine.*.inline HTTP/1.1');
access_log_bypass_if ($request = 'GET /_aliases HTTP/1.1');
access_log_bypass_if ($request = 'GET /_mapping HTTP/1.1');
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
upstream定义了es有哪些节点。另外，nginx加了日志过滤模块ngx_log_if，用来过滤kibana和es之间的心跳请求日志，这个模块可以在github上下载
1、记录kibana的每个请求日志
2、kibana通过nginx连到es，可以实现负载均衡的请求es。
集成方法比较简单，在任意一台机器上安装nginx，nginx里配置es相关信息，kibana配置文件中的elasticsearch.url改成nginx相应的ip和监听端口即可。
nginx配置文件的主要内容如下：
upstream elasticsearch {
server 10.10.10.1:9200;
server 10.10.10.2:9200;
server 10.10.10.3:9200;
keepalive 10;
}
server {
listen 8888;
server_name hostname;
location / {
proxy_pass http://elasticsearch;
access_log_bypass_if ($request = 'HEAD / HTTP/1.1');
access_log_bypass_if ($request = 'GET /_nodes?filter_path=nodes.*.version%2Cnodes.*.http.publish_address%2Cnodes.*.ip HTTP/1.1');
access_log_bypass_if ($request = 'GET /_nodes/_local?filter_path=nodes.*.settings.tribe HTTP/1.1');
access_log_bypass_if ($request_body = '{\"docs\":[{\"_index\":\".kibana\",\"_type\":\"config\",\"_id\":\"5.5.1\"}]}');
access_log_bypass_if ($request = 'GET /_cluster/health/.kibana?timeout=5s HTTP/1.1');
access_log_bypass_if ($request = 'POST /.kibana/config/_search HTTP/1.1');
access_log_bypass_if ($request = 'GET /_cluster/settings?include_defaults=true&filter_path=**.script.engine.*.inline HTTP/1.1');
access_log_bypass_if ($request = 'GET /_aliases HTTP/1.1');
access_log_bypass_if ($request = 'GET /_mapping HTTP/1.1');
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
upstream定义了es有哪些节点。另外，nginx加了日志过滤模块ngx_log_if，用来过滤kibana和es之间的心跳请求日志，这个模块可以在github上下载 收起阅读 »
elasticsearch index、create和update的源码分析
社区里面有人问了如下一个问题：
执行 bulk 索引文档的时候，用 index 或者 create 类型并且自定义 doc id 的情况下，是否会像 update 一样每次都要去 get 一遍原始文档？ 比如下面的这条命令：
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }问题出现的原因是他们在 bulk 测试的时候遇到了写性能的问题，而正巧社区里面前几天有这么一个类似的帖子，说的是 es 5.x 版本里面做 update 操作的性能问题。虽然和这个问题不完全一致，但都涉及到 es 索引数据的部分。
侯捷老师说：“源码面前，了无秘密”，那我们就来简单看下 es 这部分的相关代码，以便回答开篇提出的问题。
准备工作
我是用 IntelliJ IDEA 来阅读 elasticsearch 源码的，操作也简单。操作步骤如下：
1.下载 es 源码，由于 es 的commit信息比较多，可以增加 --depth=1 只下载最近的commit，减少下载时间。
git clone https://github.com/elastic/elasticsearch.git --depth=1
2.安装 gradle，确保版本在 3.3 及以上，然后在源码目录下执行以下命令准备导入 IntelliJ IDEA 需要的文件
gradle idea
3.下载安装 IntelliJ IDEA，确保版本为 2017.2 及以上版本。安装完成后，将 elasticsearch 以 gradle 形式导入即可。
大家可以参考 elasticsearch 文档说明 和 elasticsearch 文档说明 这两篇文章，细节我这里就不赘述了。
另外我是分析的 5.5.0 分支，大家记得 checkout，防止行数对应不起来。另外由于 es 代码结构有些复杂，先不在这篇文章里面梳理整个流程了，直接说核心代码。
Index/Create 源码分析
es index 和 create 最终都会调用 org/elasticsearch/index/engine/InternalEngine.java 中下面的方法：
457 public IndexResult index(Index index) throws IOException
注意这里的 index 中包含有要写入的 doc, 简单画下该方法的执行流程图，代码这里就不贴了，刚兴趣的自己去看。
请结合上面的流程图来看相应的代码，整个逻辑应该还是很清晰的，接下来我们看 planIndexingAsPrimary 的逻辑。
558 private IndexingStrategy planIndexingAsPrimary(Index index) throws IOException {
这个方法最终返回一个 IndexingStrategy，即一个索引的策略，总共有如下几个策略：
- optimizedAppendOnly
- skipDueToVersionConflict
- processNormally
- overrideExistingAsIfNotThere
- skipAsStale
不同的策略对应了不同的处理逻辑，前面3个是常用的，我们来看下流程图。
这里的第一步判断 是否是自定义 doc id?这一步就是 es 对于日志类非自定义 doc id的优化，感兴趣的可以自己去看下代码，简单讲就是在非自定义 id 的情况下，直接将文档 add ，否则需要 update，而 update 比 add 成本高很多。
而第二个判断 检查版本号是否冲突？ 涉及到是如何根据文档版本号来确认文档可写入，代码都在index.versionType().isVersionConflictForWrites方法里，逻辑也比较简单，不展开讲了，感兴趣的自己去看吧。
上面的流程图也比较清晰地列出了策略选择的逻辑，除去 optimizedAppendOnly 策略，其他都需要根据待写入文档的版本号来做出决策。接下来我们就看下获取文档版本号的方法。
389 private VersionValue resolveDocVersion(final Operation op) throws IOException {
该方法逻辑比较简单，主要分为2步：
- 尝试从 versionMap 中读取待写入文档的 version，也即从内存中读取。versionMap 会暂存还没有 commit 到磁盘的文档版本信息。
- 如果第 1 步中没有读到，则从 index 中读取，也即从文件中读取。
看到这里，开篇问题便有了答案。es 在 index 或者 create 的时候并不会 get 整个文档，而是只会获取文档的版本号做对比，而这个开销不会很大。
Update 源码分析
es update 的核心代码在 org/elasticsearch/action/update/UpdateHelper.java 中，具体方法如下：
public Result prepare(UpdateRequest request, IndexShard indexShard, LongSupplier nowInMillis) {
final GetResult getResult = indexShard.getService().get(request.type(), request.id(),
new String[]{RoutingFieldMapper.NAME, ParentFieldMapper.NAME, TTLFieldMapper.NAME, TimestampFieldMapper.NAME},
true, request.version(), request.versionType(), FetchSourceContext.FETCH_SOURCE);
return prepare(indexShard.shardId(), request, getResult, nowInMillis);
}代码逻辑很清晰，分两步走：
- 获取待更新文档的数据
- 执行更新文档的操作
第 1 步最终会调用 InternalEngine 中的 get 方法，如下：
350 public GetResult get(Get get, Function<String, Searcher> searcherFactory, LongConsumer onRefresh) throws EngineException {
这里就接上开篇提到的社区问题中的源码分析了。代码就不展开讲了，感兴趣的自己去看吧。
update 操作需要先获取原始文档的原因也很简单，因为这里是允许用户做部分更新的，而 es 底层每次更新时要求必须是完整的文档（因为 lucene 的更新实际是删除老文档，新增新文档），如果不拿到原始数据的话，就不能组装出更新后的完整文档了。
因此，比较看重效率的业务，最好还是不要用 update 这种操作，直接用上面的 index 会更好一些。
总结
本文通过源码分析的方式解决了开篇提到的问题，答案简单总结在下面。
es 在 index 和 create 操作的时候，如果没有自定义 doc id，那么会使用 append 优化模式，否则会获取待写入文档的版本号，进行版本检查后再决定是否写入lucene。所以这里不会去做一个 get 操作，即获取完整的文档信息。
最后，记住侯捷老师的话：
源码面前，了无秘密！
查看更好的排版
社区里面有人问了如下一个问题：
执行 bulk 索引文档的时候，用 index 或者 create 类型并且自定义 doc id 的情况下，是否会像 update 一样每次都要去 get 一遍原始文档？ 比如下面的这条命令：
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }问题出现的原因是他们在 bulk 测试的时候遇到了写性能的问题，而正巧社区里面前几天有这么一个类似的帖子，说的是 es 5.x 版本里面做 update 操作的性能问题。虽然和这个问题不完全一致，但都涉及到 es 索引数据的部分。
侯捷老师说：“源码面前，了无秘密”，那我们就来简单看下 es 这部分的相关代码，以便回答开篇提出的问题。
准备工作
我是用 IntelliJ IDEA 来阅读 elasticsearch 源码的，操作也简单。操作步骤如下：
1.下载 es 源码，由于 es 的commit信息比较多，可以增加 --depth=1 只下载最近的commit，减少下载时间。
git clone https://github.com/elastic/elasticsearch.git --depth=1
2.安装 gradle，确保版本在 3.3 及以上，然后在源码目录下执行以下命令准备导入 IntelliJ IDEA 需要的文件
gradle idea
3.下载安装 IntelliJ IDEA，确保版本为 2017.2 及以上版本。安装完成后，将 elasticsearch 以 gradle 形式导入即可。
大家可以参考 elasticsearch 文档说明 和 elasticsearch 文档说明 这两篇文章，细节我这里就不赘述了。
另外我是分析的 5.5.0 分支，大家记得 checkout，防止行数对应不起来。另外由于 es 代码结构有些复杂，先不在这篇文章里面梳理整个流程了，直接说核心代码。
Index/Create 源码分析
es index 和 create 最终都会调用 org/elasticsearch/index/engine/InternalEngine.java 中下面的方法：
457 public IndexResult index(Index index) throws IOException
注意这里的 index 中包含有要写入的 doc, 简单画下该方法的执行流程图，代码这里就不贴了，刚兴趣的自己去看。
请结合上面的流程图来看相应的代码，整个逻辑应该还是很清晰的，接下来我们看 planIndexingAsPrimary 的逻辑。
558 private IndexingStrategy planIndexingAsPrimary(Index index) throws IOException {
这个方法最终返回一个 IndexingStrategy，即一个索引的策略，总共有如下几个策略：
- optimizedAppendOnly
- skipDueToVersionConflict
- processNormally
- overrideExistingAsIfNotThere
- skipAsStale
不同的策略对应了不同的处理逻辑，前面3个是常用的，我们来看下流程图。
这里的第一步判断 是否是自定义 doc id?这一步就是 es 对于日志类非自定义 doc id的优化，感兴趣的可以自己去看下代码，简单讲就是在非自定义 id 的情况下，直接将文档 add ，否则需要 update，而 update 比 add 成本高很多。
而第二个判断 检查版本号是否冲突？ 涉及到是如何根据文档版本号来确认文档可写入，代码都在index.versionType().isVersionConflictForWrites方法里，逻辑也比较简单，不展开讲了，感兴趣的自己去看吧。
上面的流程图也比较清晰地列出了策略选择的逻辑，除去 optimizedAppendOnly 策略，其他都需要根据待写入文档的版本号来做出决策。接下来我们就看下获取文档版本号的方法。
389 private VersionValue resolveDocVersion(final Operation op) throws IOException {
该方法逻辑比较简单，主要分为2步：
- 尝试从 versionMap 中读取待写入文档的 version，也即从内存中读取。versionMap 会暂存还没有 commit 到磁盘的文档版本信息。
- 如果第 1 步中没有读到，则从 index 中读取，也即从文件中读取。
看到这里，开篇问题便有了答案。es 在 index 或者 create 的时候并不会 get 整个文档，而是只会获取文档的版本号做对比，而这个开销不会很大。
Update 源码分析
es update 的核心代码在 org/elasticsearch/action/update/UpdateHelper.java 中，具体方法如下：
public Result prepare(UpdateRequest request, IndexShard indexShard, LongSupplier nowInMillis) {
final GetResult getResult = indexShard.getService().get(request.type(), request.id(),
new String[]{RoutingFieldMapper.NAME, ParentFieldMapper.NAME, TTLFieldMapper.NAME, TimestampFieldMapper.NAME},
true, request.version(), request.versionType(), FetchSourceContext.FETCH_SOURCE);
return prepare(indexShard.shardId(), request, getResult, nowInMillis);
}代码逻辑很清晰，分两步走：
- 获取待更新文档的数据
- 执行更新文档的操作
第 1 步最终会调用 InternalEngine 中的 get 方法，如下：
350 public GetResult get(Get get, Function<String, Searcher> searcherFactory, LongConsumer onRefresh) throws EngineException {
这里就接上开篇提到的社区问题中的源码分析了。代码就不展开讲了，感兴趣的自己去看吧。
update 操作需要先获取原始文档的原因也很简单，因为这里是允许用户做部分更新的，而 es 底层每次更新时要求必须是完整的文档（因为 lucene 的更新实际是删除老文档，新增新文档），如果不拿到原始数据的话，就不能组装出更新后的完整文档了。
因此，比较看重效率的业务，最好还是不要用 update 这种操作，直接用上面的 index 会更好一些。
总结
本文通过源码分析的方式解决了开篇提到的问题，答案简单总结在下面。
es 在 index 和 create 操作的时候，如果没有自定义 doc id，那么会使用 append 优化模式，否则会获取待写入文档的版本号，进行版本检查后再决定是否写入lucene。所以这里不会去做一个 get 操作，即获取完整的文档信息。
最后，记住侯捷老师的话：
源码面前，了无秘密！
查看更好的排版
收起阅读 »
社区日报 第53期 (2017-09-20)
http://t.cn/R0vpOVu
2. 基于Kibana的时序实践
http://t.cn/RCVj5Wm
3. 基于Vue的Elasticsearch可视化工具 比head更好用（github）
http://t.cn/Ro5WST3
编辑：江水
归档：https://elasticsearch.cn/article/284
订阅：https://tinyletter.com/elastic-daily
http://t.cn/R0vpOVu
2. 基于Kibana的时序实践
http://t.cn/RCVj5Wm
3. 基于Vue的Elasticsearch可视化工具 比head更好用（github）
http://t.cn/Ro5WST3
编辑：江水
归档：https://elasticsearch.cn/article/284
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
社区日报 第52期 (2017-09-19)
2.看Logz如何构建一个完美的Kibana可视化系统。http://t.cn/Rpr21iH
3.易宝支付日志中心平台从0到1的搭建，值得借鉴。http://t.cn/Rpgse8D
编辑：叮咚光军
归档：https://elasticsearch.cn/article/283
订阅：https://tinyletter.com/elastic-daily
2.看Logz如何构建一个完美的Kibana可视化系统。http://t.cn/Rpr21iH
3.易宝支付日志中心平台从0到1的搭建，值得借鉴。http://t.cn/Rpgse8D
编辑：叮咚光军
归档：https://elasticsearch.cn/article/283
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
Elasticsearch大文件检索性能提升20倍实践（干货）
Elasticsearch大文件检索性能提升20倍实践（干货）
感谢群内各位大神的帮助！现将遇到问题、问题排查、问题定位、优化处理分享给大家。
欢迎拍砖！
Elasticsearch大文件检索性能提升20倍实践（干货）
感谢群内各位大神的帮助！现将遇到问题、问题排查、问题定位、优化处理分享给大家。
欢迎拍砖！ 收起阅读 »
社区日报 第51期 (2017-09-18)
http://t.cn/RpBZ8d7
2. 来看看国外最流行的协作工具slack是如何运用elk来做安全分析的。
http://t.cn/RpB26BH
3. 在 Kibana 中使用脚本字段（需梯子）。
http://t.cn/RpBLhDb
编辑：cyberdak
归档：https://www.elasticsearch.cn/article/281
订阅：https://tinyletter.com/elastic-daily
http://t.cn/RpBZ8d7
2. 来看看国外最流行的协作工具slack是如何运用elk来做安全分析的。
http://t.cn/RpB26BH
3. 在 Kibana 中使用脚本字段（需梯子）。
http://t.cn/RpBLhDb
编辑：cyberdak
归档：https://www.elasticsearch.cn/article/281
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
社区日报 第50期 (2017-09-17)
http://t.cn/RpmnT8C
2. 使用Elasticsearch和grafana分析github项目。
http://t.cn/R9xXkZE
3. 第二届GrafanaCon谈话视频整理。
http://t.cn/RpmmMk3
编辑：至尊宝
归档：https://www.elasticsearch.cn/article/280
订阅：https://tinyletter.com/elastic-daily
http://t.cn/RpmnT8C
2. 使用Elasticsearch和grafana分析github项目。
http://t.cn/R9xXkZE
3. 第二届GrafanaCon谈话视频整理。
http://t.cn/RpmmMk3
编辑：至尊宝
归档：https://www.elasticsearch.cn/article/280
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
社区日报 第49期 (2017-09-16)
http://t.cn/RpYDk2c
2. 手把手教你在Azure搭建ELK
http://t.cn/RpYsAG8
3. 你知道es可以执行包含多个词的同义词的词组查询吗？
http://t.cn/RpTvc5Z
编辑：bsll
归档：https://www.elasticsearch.cn/article/279
订阅：https://tinyletter.com/elastic-daily
http://t.cn/RpYDk2c
2. 手把手教你在Azure搭建ELK
http://t.cn/RpYsAG8
3. 你知道es可以执行包含多个词的同义词的词组查询吗？
http://t.cn/RpTvc5Z
编辑：bsll
归档：https://www.elasticsearch.cn/article/279
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
为何要避免往ES里写入稀疏数据
https://www.elastic.co/guide/e ... rsity
Avoid sparsityedit
The data-structures behind Lucene, which Elasticsearch relies on in order to index and store data, work best with dense data, ie. when all documents have the same fields. This is especially true for fields that have norms enabled (which is the case for text fields by default) or doc values enabled (which is the case for numerics, date, ip and keyword by default).
The reason is that Lucene internally identifies documents with so-called doc ids, which are integers between 0 and the total number of documents in the index. These doc ids are used for communication between the internal APIs of Lucene: for instance searching on a term with a matchquery produces an iterator of doc ids, and these doc ids are then used to retrieve the value of the norm in order to compute a score for these documents. The way this norm lookup is implemented currently is by reserving one byte for each document. The norm value for a given doc id can then be retrieved by reading the byte at index doc_id. While this is very efficient and helps Lucene quickly have access to the norm values of every document, this has the drawback that documents that do not have a value will also require one byte of storage.
In practice, this means that if an index has M documents, norms will require M bytes of storage per field, even for fields that only appear in a small fraction of the documents of the index. Although slightly more complex with doc values due to the fact that doc values have multiple ways that they can be encoded depending on the type of field and on the actual data that the field stores, the problem is very similar. In case you wonder: fielddata, which was used in Elasticsearch pre-2.0 before being replaced with doc values, also suffered from this issue, except that the impact was only on the memory footprint since fielddata was not explicitly materialized on disk.
Note that even though the most notable impact of sparsity is on storage requirements, it also has an impact on indexing speed and search speed since these bytes for documents that do not have a field still need to be written at index time and skipped over at search time.
It is totally fine to have a minority of sparse fields in an index. But beware that if sparsity becomes the rule rather than the exception, then the index will not be as efficient as it could be.
This section mostly focused on norms and doc values because those are the two features that are most affected by sparsity. Sparsity also affect the efficiency of the inverted index (used to index text/keyword fields) and dimensional points (used to index geo_point and numerics) but to a lesser extent.
Here are some recommendations that can help avoid sparsity:
https://www.elastic.co/blog/index-vs-type
Fields that exist in one type will also consume resources for documents of types where this field does not exist. This is a general issue with Lucene indices: they don’t like sparsity. Sparse postings lists can’t be compressed efficiently because of high deltas between consecutive matches. And the issue is even worse with doc values: for speed reasons, doc values often reserve a fixed amount of disk space for every document, so that values can be addressed efficiently. This means that if Lucene establishes that it needs one byte to store all value of a given numeric field, it will also consume one byte for documents that don’t have a value for this field. Future versions of Elasticsearch will have improvements in this area but I would still advise you to model your data in a way that will limit sparsity as much as possible.
https://www.elastic.co/blog/sp ... ucene
[url=https://issues.apache.org/jira/browse/LUCENE-6863]https://issues.apache.org/jira/browse/LUCENE-6863[/url]
https://www.elastic.co/blog/el ... eased
https://www.elastic.co/guide/e ... rsity
Avoid sparsityedit
The data-structures behind Lucene, which Elasticsearch relies on in order to index and store data, work best with dense data, ie. when all documents have the same fields. This is especially true for fields that have norms enabled (which is the case for text fields by default) or doc values enabled (which is the case for numerics, date, ip and keyword by default).
The reason is that Lucene internally identifies documents with so-called doc ids, which are integers between 0 and the total number of documents in the index. These doc ids are used for communication between the internal APIs of Lucene: for instance searching on a term with a matchquery produces an iterator of doc ids, and these doc ids are then used to retrieve the value of the norm in order to compute a score for these documents. The way this norm lookup is implemented currently is by reserving one byte for each document. The norm value for a given doc id can then be retrieved by reading the byte at index doc_id. While this is very efficient and helps Lucene quickly have access to the norm values of every document, this has the drawback that documents that do not have a value will also require one byte of storage.
In practice, this means that if an index has M documents, norms will require M bytes of storage per field, even for fields that only appear in a small fraction of the documents of the index. Although slightly more complex with doc values due to the fact that doc values have multiple ways that they can be encoded depending on the type of field and on the actual data that the field stores, the problem is very similar. In case you wonder: fielddata, which was used in Elasticsearch pre-2.0 before being replaced with doc values, also suffered from this issue, except that the impact was only on the memory footprint since fielddata was not explicitly materialized on disk.
Note that even though the most notable impact of sparsity is on storage requirements, it also has an impact on indexing speed and search speed since these bytes for documents that do not have a field still need to be written at index time and skipped over at search time.
It is totally fine to have a minority of sparse fields in an index. But beware that if sparsity becomes the rule rather than the exception, then the index will not be as efficient as it could be.
This section mostly focused on norms and doc values because those are the two features that are most affected by sparsity. Sparsity also affect the efficiency of the inverted index (used to index text/keyword fields) and dimensional points (used to index geo_point and numerics) but to a lesser extent.
Here are some recommendations that can help avoid sparsity:
https://www.elastic.co/blog/index-vs-type
Fields that exist in one type will also consume resources for documents of types where this field does not exist. This is a general issue with Lucene indices: they don’t like sparsity. Sparse postings lists can’t be compressed efficiently because of high deltas between consecutive matches. And the issue is even worse with doc values: for speed reasons, doc values often reserve a fixed amount of disk space for every document, so that values can be addressed efficiently. This means that if Lucene establishes that it needs one byte to store all value of a given numeric field, it will also consume one byte for documents that don’t have a value for this field. Future versions of Elasticsearch will have improvements in this area but I would still advise you to model your data in a way that will limit sparsity as much as possible.
https://www.elastic.co/blog/sp ... ucene
[url=https://issues.apache.org/jira/browse/LUCENE-6863]https://issues.apache.org/jira/browse/LUCENE-6863[/url]
https://www.elastic.co/blog/el ... eased
社区日报 第48期 (2017-09-15)
http://t.cn/RpOCVsz
2.twitter数据导入Elasticsearch的三种方式。
http://t.cn/RpOC6An
3.CSV数据导入Elasticsearch及可视化方案。
http://t.cn/RCGeeJK
编辑：laoyang360
归档：https://www.elasticsearch.cn/article/276
订阅：https://tinyletter.com/elastic-daily
http://t.cn/RpOCVsz
2.twitter数据导入Elasticsearch的三种方式。
http://t.cn/RpOC6An
3.CSV数据导入Elasticsearch及可视化方案。
http://t.cn/RCGeeJK
编辑：laoyang360
归档：https://www.elasticsearch.cn/article/276
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
Elasticsearch 压测方案之 esrally 简介
由于 Elasticsearch（后文简称es） 的简单易用及其在大数据处理方面的良好性能，越来越多的公司选用 es 作为自己的业务解决方案。然而在引入新的解决方案前，不免要做一番调研和测试，本文便是介绍官方的一个 es 压测工具 esrally，希望能为大家带来帮助。
为什么要压测？
关于压测，我们先来看下百度百科上的一个定义。
压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。
从定义不难看出压测的目的，是要测出一个系统的极限，提早发现隐患，早作打算。那么对于 es 来讲，我认为压测一般有以下几个目的：
- 验证 es 的性能，尽管网上把 es 的性能夸上天了，还是自己跑一下才放心。
- 针对 es 的某些配置做试验性测试，比如关闭索引的 _all 特性，是否能提高写性能，具体能提高多少。
- 对比 es 新版本和旧版本的性能差异。众所周知，es 的版本升级非常快，用着 2.x 的同学们还没来得及升级 5.x ，眼看 6.x 都要发布了。此时，你到底要不要升级呢？答案虽然是肯定的，但是你怎么说服你的 leader 呢？很简单：压测新版本，和旧版本做对比，用表格、图表指明新版本在写性能、读性能方面的改善等等，搞定。
- 对 es 集群做容量规划。俗话说“人无远虑，必有近忧”，容量规划就是“远虑”。简单讲就是你线上的 es 集群一共需要多少节点？每个节点的配置如何？这个集群的写性能极限是多少？读性能呢？如果你回答不了这些问题，那就说明你没有做过容量规划，只是两眼一抹黑，说干就干，上了再说，好在有惊无险，没有碰到性能问题。至于什么时候会遇到问题，你也说不准，感觉是个概率和人品问题……对面的老板已经黑脸了…… 对于这个问题我们在最后再来详细讨论。
如何进行压测？
现在我们知道压测的目的了，接下来该如何进行压测呢？一般有以下几个方案：
- 自己写代码。无需多言，想怎么写怎么写，难点在于如果确保测试代码的专业性。这里有一些开源项目，留给大家自己探索：esperf 和 elasticsearch-stress-test
- http压测工具。es 对外暴露了 Restful API，因此所有的针对 http 协议的压测工具都可以用来测试 es，比如 JMeter、httpload等等。
- elastic 官方工具 esrally。
各个压测方案各有优劣，大家可以根据自己的需求和工具熟悉度来选择自己的压测工具。接下来我们就来具体了解下 esrally。
入门
简介
esrally 是 elastic 官方开源的一款基于 python3 实现的针对 es 的压测工具，源码地址为https://github.com/elastic/rally，相关博客介绍在这里。esrally主要功能如下：
- 自动创建、压测和销毁 es 集群
- 可分 es 版本管理压测数据和方案
- 完善的压测数据展示，支持不同压测之间的数据对比分析，也可以将数据存储到指定的es中进行二次分析
- 支持收集 JVM 详细信息，比如内存、GC等数据来定位性能问题
elastic 官方也是基于 esrally 进行 es 的性能测试，并将结果实时发布到 https://elasticsearch-benchmarks.elastic.co/ ，大家可以从该网站上直接查看 es 的性能。官方使用两台服务器进行压测，一台运行 esrally ，一台运行 es，服务器的配置如下：
CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
RAM: 32 GB
SSD: Crucial MX200
OS: Linux Kernel version 4.8.0-53
JVM: Oracle JDK 1.8.0_131-b11
网站顶部的 Geonames、Geopoint、Percolator等都是针对不同的数据集做的压测，比如下面这些图展示了 logging 日志类数据的压测结果。
快速入门
esrally 的文档在这里，这里简单说下安装与运行。
esrally 对于软件环境的要求如下：
- Python 3.4+ 和 pip3
- JDK 8
- git 1.9+
安装方法为：
pip3 install esrally
Tips:
可以使用国内的pip源，比如豆瓣或者阿里的，这样安装会快很多。
安装完毕后执行如下的配置命令，确认一些数据存放的路径即可。
esrally configure
接下来就可以开跑了，比如下面这条命令是针对 es 5.0.0 版本进行压力测试。
esrally --distribution-version=5.0.0
运行结束后，会得到如下的结果。
对于第一次见到压测结果的同学来说可能有些晕，这么多数据，该怎么看？！别急，一步步来！
Tips:
由于 esrally 的测试数据存储在国外 aws 上，导致下载很慢甚至会超时失败，从而导致整个压测无法进行。后面我会把这些测试数据的压缩包放到国内，大家可以下载后直接放到 esrally 的数据文件夹下面，保证压测的正常进行。另外由于数据量过大，压测的时间一般会很久，可能在1个小时左右，所以大家要有耐心哦~
如果你只是想体验下，可以加上 --test-mode 的参数，此时只会下载1000条文档进行测试。
相关术语
rally 是汽车拉力赛的意思，也就是说 esrally 是将压测比作了汽车拉力赛，因此其中的很多术语都是从汽车拉力赛中借鉴来的。
track
track 是赛道的意思，在这里是指压测用的数据和测试策略，详细文档在这里。esrally 自带的track都在 github 上，地址在这里 https://github.com/elastic/rally-tracks。在该 repository 中，有很多测试数据，比如 geonames geopoint logging nested 等，每个数据文件夹中的 README.md 中有详细的数据介绍，而 track.json 便是压测策略的定义文件。
我们来看下 loggins/track.json 文件
{% import "rally.helpers" as rally with context %}
{
"short-description": "Logging benchmark",
"description": "This benchmark indexes HTTP server log data from the 1998 world cup.",
"data-url": "http://benchmarks.elasticsearc ... ot%3B,
"indices": [
{
"name": "logs-181998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-181998.json.bz2",
"document-count": 2708746,
"compressed-bytes": 13815456,
"uncompressed-bytes": 363512754
}
]
},
{
"name": "logs-191998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-191998.json.bz2",
"document-count": 9697882,
"compressed-bytes": 49439633,
"uncompressed-bytes": 1301732149
}
]
}
],
"operations": [
{{ rally.collect(parts="operations/*.json") }}
],
"challenges": [
{{ rally.collect(parts="challenges/*.json") }}
]
}- description 和 short-description: track 的描述文字
- data-url: 一个url地址，指明测试数据的下载根路径，与下方 indices 中的 documents 结合，可得到数据的下载地址。
- indices: 指定该track可以操作的索引，包括创建、更新、删除等操作。详细信息可以参见这里。
- operations: 指定具体的操作，比如 index 索引数据的操作、force-merge 强制合并segment的操作、search 搜索的操作等等。具体例子可以看下面的示例。详细信息可以参见这里。
- challenges: 通过组合 operations 定义一系列 task ，再组合成一个压测的流程，请参照下方的 例子。详细信息可以参见这里。
operations/default.json 中的一个定义如下：
{
"name": "index-append",
"operation-type": "index",
"bulk-size": 5000
}
challenges/default.json 中的一个定义如下：
{
"name": "append-no-conflicts",
"description": "",
"default": true,
"index-settings": {
"index.number_of_replicas": 0
},
"schedule": [
{
"operation": "index-append",
"warmup-time-period": 240,
"clients": 8
},
{
"operation": "force-merge",
"clients": 1
},
{
"operation": "index-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "node-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "default",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 10
},
{
"operation": "term",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 60
},
{
"operation": "range",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 2
},
{
"operation": "hourly_agg",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 0.2
},
{
"operation": "scroll",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 10
}
]
}通过下面的命令可以查看当前 esrally 可用使用的track。
esrally list tracks
esrally 的 track 数据位于 rally 目录(mac默认是 ~/.rally)中 benchmarks/tracks/ 下面。
car
car 是赛车的意思，这里是指不同配置的 es 实例。通过下面的命令可以查看 esrally 当前可用的 car。
esrally list cars
Name
----------
16gheap
1gheap
2gheap
4gheap
8gheap
defaults
ea
verbose_iw
cars 的配置位于 rally 目录(mac默认是 ~/.rally)中 benchmarks/teams/default/cars/ 下面。具体配置可以参见 cars 的文档，除了 heap 的配置，所有的 es 配置都可以修改。
race
race 是一次比赛的意思，这里是指某一次压测。要比赛，就要有赛道和赛车，如果不指定赛车，就用 default 配置，如果不指定赛道，则默认使用 geonames track。通过下面的命令来执行一次 race。
esrally race --track=logging --challenge=append-no-conflicts --car="4gheap"
上面的命令便是执行一次压测，并指定使用 logging 的track，运行该 track 中的 append-no-conflicts 的 challenge，指定的 car 为 4gheap 的 es 实例。详情可以查看 race 相关文档。
Tournament
tournament 是锦标赛的意思，是由多个 race 组成的。通过下面的命令可以查看所有的 race。
esrally list races
Recent races:
Race Timestamp Track Challenge Car User Tag
---------------- ------- ------------------- -------- ------------------------------
20160518T122341Z pmc append-no-conflicts defaults intention:reduce_alloc_1234
20160518T112057Z pmc append-no-conflicts defaults intention:baseline_github_1234
20160518T101957Z pmc append-no-conflicts defaults
esrally compare --baseline=20160518T112057Z --contender=20160518T112341Z
详细信息可以参见 tournament 的文档。
Pipeline
Pipeline 在这里是指压测的一个流程，通过下面的命令可以查看已有的pipeline。
esrally list pipeline
Name Description
----------------------- ---------------------------------------------------------------------------------------------
from-sources-complete Builds and provisions Elasticsearch, runs a benchmark and reports results.
from-sources-skip-build Provisions Elasticsearch (skips the build), runs a benchmark and reports results.
from-distribution Downloads an Elasticsearch distribution, provisions it, runs a benchmark and reports results.
benchmark-only Assumes an already running Elasticsearch instance, runs a benchmark and reports results
- from-sources-complete 是从源代码编译 es 后再运行，可以通过 --revision 参数指明要编译的commit hash ，这样就可以针对某一个提交版本就行测试了。
- from-sources-skip-build 如果已经编译好了，使用该 pipeline，可以跳过编译的流程，节省测试时间
- from-distribution 通过 --distribution-version 指定 es 版本，esrally 会从官网直接下载该版本的可执行文件，然后进行测试。
- benchmark-only 此 pipeline 将 es 集群的管理交由用户来处理， esrally 只做压测。如果你想针对已有集群进行测试，那么要将pipeline设定为该模式。
详细信息请参见 pipeline 的文档。
压测流程
esrally 的压测流程主要分为以下三个步骤：
- 根据参数设定自行编译或者下载 es 可执行实例，然后根据 car 的约定，创建并启动 es 集群。如果使用 benchmark-only 的pipeline，则该步骤省略。
- 根据指定 track 去下载数据，然后按照指定的 challenge 进行操作。
- 记录并输出压测结果数据。
压测结果分析
压测结束后，esrally 会将结果输出到终端和结果文件（位于 esrally 目录logs 和 benchmarks/races）中，如下图所示：
在 Metric 一栏，有非常多的指标数据，详细的解释可以参见该文档。一般要关注的数据有：
- throughput 每个操作的吞吐量，比如 index、search等
- latency 每个操作的响应时长数据
- Heap used for x 记录堆栈的使用情况
先搞懂每个 metric 的含义，然后根据自己的需求去确认自己要关注的指标。
每一次压测都会以压测时的时间命名，比如 logs/rally_out_20170822T082858Z.log ，这个日志便是记录的 2017年8月22日 8:28:58开始的压测日志。而在 benchmarks/races/2017-08-22-08-28-58 中记录着最终的结果和 es 的运行日志。
另外对于 benchmark-only 模式的测试，即针对已有集群的压力测试，也可以通过安装 X-Pack Basic 版本进行监控（Monitoring），在压测的过程中就能查看相关指标。
esrally 可以在配置的时候指定将所有的 race 压测结果数据存入一个指定的 es 实例中，配置如下(在 esrally 目录中 rally.ini 文件中)：
[reporting]
datastore.type = elasticsearch
datastore.host = localhost
datastore.port = 9200
datastore.secure = False
datastore.user =
datastore.password =- rally-metrics-* 该索引分指标记录每次 race 的结果，如下图所示为某一次race的所有 metric 数据。
第一列时间是指某一次压测的时间，第二列时间是指标采集的时间，第三列 operation 指具体执行的操作，operation 为空的指标都是总计类的，比如indexing total time 记录的是总索引数据的时间、segments_count 是总段数等等。其他的 operation 都记录了每一个操作的数据。需要注意的是，这里记录的是 operation 的所有采样数据，不是一个最终的汇总数据。上面截图中也可以看出同一个 hour_agg 的operation 有多项名为 service_time 的指标数据，但他们的采集时间是不同的。基于这些数据，我们可以做出某一次 race 中某个指标的可视化图表，比如你想观察本次 race 中 index-log 这个 task 的 throughput 指标数据，便可以通过如下图的方式实现。
- rally-result-* 该索引分指标记录了每次 race 的最终汇总结果，比如下面这条数据。
{
"user-tag": "shardSizeTest:size6",
"distribution-major-version": 5,
"environment": "local",
"car": "external",
"plugins": [
"x-pack"
],
"track": "logging",
"active": true,
"distribution-version": "5.5.2",
"node-count": 1,
"value": {
"50_0": 19.147876358032228,
"90_0": 21.03116340637207,
"99_0": 41.644479789733886,
"100_0": 47.20634460449219
},
"operation": "term",
"challenge": "default-index",
"trial-timestamp": "20170831T063724Z",
"name": "latency"
}rally-races-* 该索引记录了所有 race 的最终结果，即命令行执行的输出结果。
除了es相关指标数据外，esrally 还会同时记录测试的一些环境信息，比如操作系统、JVM等等，你可以方便的查看本次测试的软硬件环境。
实战
终于到了开赛的时候，下面我们采用问答的形式来进行，希望大家看到问题后先自己思考下再看答案。
问题一
提问：如何对比 5.5.0 相比 2.4.6 的性能改进？
回答：
分别针对 5.5.0 和 2.4.6 做一次压测，然后比较两者两者的相关指标即可，这里我们的 track 和 challenge 如下：
track: nyc_taxis
challenge: append-no-conflicts
测试步骤如下：
1.测试 2.4.6 的性能
esrally race --distribution-version=2.4.6 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:2.4.6"
2.测试 5.5.0 的性能
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:5.5.0"
3.对比两次 race 的结果
esrally list races
esrally compare --baseline=[2.4.6 race] --contender=[5.5.0 race]
Tips:
--user-tag 用于为 race 打标签，方便后续查找
如果只是试一下，可以加上 --test-mode ，用测试数据来跑，很快。
问题二
提问：如何测试 _all 关闭后对于写性能的影响？
回答：
针对 5.5.0 版本的 es 做两次测试，第一次开启 _all，第二次关闭 _all，对比两次的结果，由于只测试写性能，所以我们只需要 index 类型的 operation执行。这里我们的 track 和 challenge 如下：
- track: nyc_taxis
- challenge: append-no-conflicts
测试步骤如下：
1.默认 nyc_taxis 的 mapping 设置是将 _all 关闭的，直接测试 _all 关闭时的性能。
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:false" --include-tasks="type:index"
2.修改 nyc_taxis 的 mapping 设置，打开 _all。mapping 文件位于 rally 主目录 benchmarks/tracks/default/nyc_taxis/mappings.json，修改 _all.enabled 为 true。
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:true" --include-tasks="type:index"
3.对比两次 race 的结果
esrally list races
esrally compare --baseline=[enableAll race] --contender=[disableAll race]
下图是我在 --test-mode 模式下运行的对比结果，也可以看出关闭 _all 可以提升写性能。
Tips:
--include-tasks 用于只运行 challenge 中的部分 task
问题三
提问：如何测试已有集群的性能？
回答：
使用 benchmark-only 的 pipeline 即可，这里我们的 track 和 challenge 如下：
- track: nyc_taxis
- challenge: append-no-conflicts
测试步骤如下：
1.执行下方命令即可测试已有集群
esrally race --pipeline=benchmark-only --target-hosts=127.0.0.1:9200 --cluster-health=yellow --track=nyc_taxis --challenge=append-no-conflicts
Tips:
--cluster-health=yellow 默认 esrally 会检查集群状态，非 green 状态会直接退出。添加该参数可以避免该情况
希望这三个问答可以帮助到大家快速掌握 esrally 的用法。
进阶
自定义 car
前面讲解 car 的时候，我们提到 esrally 已经自带了一些可用的 es 配置，但是如果这些还不能满足你的时候，可以通过下面两个方案解决。
1.定制自己的car
car 的配置文件位于 esrally 目录 benchmarks/teams/default/cars，在这里新增一个自己的 car 配置文件就可以了。这里就不赘述了，感兴趣的可以查阅 car 的文档。
2.自己搭建集群
最简单的方式是脱离 esrally 的管理，自行搭建集群，这样想怎么配置就怎么配置了。
自定义 track
虽然 esrally 自带了很多 track，而且这些数据本身也不小，简单列在下面：
Track 压缩数据大小 解压数据大小 文档数
geonames 252 MB 3.3 GB 11396505
geopoint 482 MB 2.3 GB 60844404
logging 1.2 GB 31 GB 247249096
nested 663 MB 3.3 GB 11203029
noaa 947 MB 9 GB 33659481
nyc_taxis 4.5 GB 74 GB 165346692
percolator 103KB 105 MB 2000000
pmc 5.5 GB 22 GB 574199当我们做定向测试的时候，还是希望针对自己的数据进行压测，此时可以自定义 track。操作也很简单，详情可以参考官方文档。这里简单列一下操作步骤。
- 在 上文提到的 data 目录中创建自己的数据目录。
- 准备压测数据文件。 esrally 使用的是一个json文件，其实是一个一个 json object。
- 将准备好的数据文件压缩成 bz2 格式，然后复制到步骤 1 创建的目录中去。
- 新增自定义的track。可以直接复制 geoname 目录，然后修改相关的配置文件，将测试数据与 track 绑定。
- 添加完后，通过 esrally list rack 就可以看到自定义的 track。
分布式压测
esrally 还支持分布式压测，即如果一个节点的 esrally 无法达到要求的并发数、请求数，那么可以将 esrally 分布到多台机器上去同时执行。分布式压测文档在这里，此处用到了 esrally dameon，对应命令是 esrallyd 。简单讲就是 esrally 通过 esrallyd 将多台机器组合成一个集群，然后 esrally 在执行测试任务的时候通过制定 --load-driver-hosts 便可以将测试任务分发到对应的机器上执行。这里便不赘述了，感兴趣的去看前面提到的文档。
最后一个问题
让我们回到开头提到的容量规划的问题吧！
提问：一个 index 的 shard 数该如何确认？
回答：
其实针对这个提问，还可以再问下面两个问题。
- shard 设置过少是否有问题？比如一直都采用默认的 5个分片
- shard 设置过多是否有问题？比如直接设置为100个分片
要回到这两个问题，我们得先知道 shard 的作用。shard 是 es 实现分布式特性的基石，文档在索引进 es 时，es 会根据一个路由算法，将每一个文档分配到对应的 shard 上。每个 shard 实际对应一个 lucene index。那么每个 shard 能存储的文档数是否有上限呢？答案是有！每个shard最多存储 2^31 个文档，即 20亿。这是 lucene 设计决定的。那是不是只要我的文档数没有超过20亿，就可以只用一个或者很少的shard 呢？不尽然。因为随着 shard 体积的增大，其查询效率会下降，而且数据迁移和恢复的成本也会增高。官方建议单个 shard 大小不要超过 50GB，可以参见讨论一和讨论二。
现在回答上面的两个问题。
shard数过小不一定好，如果数据量很大，导致每个 shard 体积过大，会影响查询性能。
shard数过大也不一定好，因为 es 的每次查询是要分发给所有的 shard 来查询，然后再对结果做聚合处理，如果 shard 数过多也会影响查询性能。因此 shard 的数量需要根据自己的情况测出来。
官方文档有一节关于容量规划的章节，建议大家去看一下，链接在这里，其给出的步骤如下：
- 使用生产环境的硬件配置创建单节点集群
- 创建一个只有一个主分片无副本的索引，设置相关的mapping信息
- 将真实的文档导入到步骤 2 的索引中
- 测试实际会用到的查询语句
测试的过程中，关注相关指标数据，比如索引性能、查询性能，如果在某一个点相关性能数据超出了你的预期值，那么此时的 shard size大小便是符合你预期的单个 shard size的大小。接下来通过下面这个简单的计算公式便大致能确定一个 index 需要设定的 shard 数了。
shard数 = index 的数据总大小/单个shard size的极限值
比如你测出单个 shard size 最大为 20 GB，而你预测该索引数据最大量在1年或者2年内不会超过 200GB，那么你的 shard 数就可以设置为10。
接下来要做的事情也很明确，我们要用 esrally 完成上面的压测步骤：
1.自行维护 es 节点的创建和运行，esrally 运行的时候采用 benchmark-only 模式.
2.自定义 track，这里有以下两个重点：
- 生成真实数据。如果你的数据无法生成很多，那么可以在 track 的 schedule 中设置 iterations 参数，即循环进行同一个操作，这样也可以测试大数据量的写性能。
- 定义自己的查询任务。在 track 的 operations 中是可以定义自己的查询语句的，比如下面这个
其中的 body 便是自定义的查询语句，所以你可以通过自己的需求来设定查询语句，以贴近实际使用的情况。{ "name": "hourly_agg", "operation-type": "search", "index": "logs-*", "type": "type", "body": { "size": 0, "aggs": { "by_hour": { "date_histogram": { "field": "@timestamp", "interval": "hour" } } } }}
3.还要记得设置索引的 mapping 与线上一致，比如是否启用 _all 等设置。
4.基于自定义的track来进行压测即可。要注意的是运行 esrally 的机器要和 es 机器分开，防止对 es 性能产生干扰。
Tips:
esrally 默认在每次压测是会删除已有的索引后再重新创建索引，如果你不想这样，可以在每个 index 的配置中设置 auto-managed 为 false，具体文档在这里。
通过这个参数，你就可以单独压测查询性能了，而不用每次都要先经过漫长的导入数据的过程。
总结
esrally 针对 es 的压测设计了一套完备的基于配置文件的测试流程，极大地简化了操作难度，并且提供了可重复验证的方式。对国内用户来讲，我认为最大的难处还是在于 esrally 自带的 track 文件太大，从 国外 aws 下载很慢。好在可以自定义 track，不必完全依赖自带的 track。
其他没啥好说的，esrally 棒棒哒，大家赶紧去试试吧，如果有问题欢迎来讨论！
点击查看更好的排版
由于 Elasticsearch（后文简称es） 的简单易用及其在大数据处理方面的良好性能，越来越多的公司选用 es 作为自己的业务解决方案。然而在引入新的解决方案前，不免要做一番调研和测试，本文便是介绍官方的一个 es 压测工具 esrally，希望能为大家带来帮助。
为什么要压测？
关于压测，我们先来看下百度百科上的一个定义。
压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。
从定义不难看出压测的目的，是要测出一个系统的极限，提早发现隐患，早作打算。那么对于 es 来讲，我认为压测一般有以下几个目的：
- 验证 es 的性能，尽管网上把 es 的性能夸上天了，还是自己跑一下才放心。
- 针对 es 的某些配置做试验性测试，比如关闭索引的 _all 特性，是否能提高写性能，具体能提高多少。
- 对比 es 新版本和旧版本的性能差异。众所周知，es 的版本升级非常快，用着 2.x 的同学们还没来得及升级 5.x ，眼看 6.x 都要发布了。此时，你到底要不要升级呢？答案虽然是肯定的，但是你怎么说服你的 leader 呢？很简单：压测新版本，和旧版本做对比，用表格、图表指明新版本在写性能、读性能方面的改善等等，搞定。
- 对 es 集群做容量规划。俗话说“人无远虑，必有近忧”，容量规划就是“远虑”。简单讲就是你线上的 es 集群一共需要多少节点？每个节点的配置如何？这个集群的写性能极限是多少？读性能呢？如果你回答不了这些问题，那就说明你没有做过容量规划，只是两眼一抹黑，说干就干，上了再说，好在有惊无险，没有碰到性能问题。至于什么时候会遇到问题，你也说不准，感觉是个概率和人品问题……对面的老板已经黑脸了…… 对于这个问题我们在最后再来详细讨论。
如何进行压测？
现在我们知道压测的目的了，接下来该如何进行压测呢？一般有以下几个方案：
- 自己写代码。无需多言，想怎么写怎么写，难点在于如果确保测试代码的专业性。这里有一些开源项目，留给大家自己探索：esperf 和 elasticsearch-stress-test
- http压测工具。es 对外暴露了 Restful API，因此所有的针对 http 协议的压测工具都可以用来测试 es，比如 JMeter、httpload等等。
- elastic 官方工具 esrally。
各个压测方案各有优劣，大家可以根据自己的需求和工具熟悉度来选择自己的压测工具。接下来我们就来具体了解下 esrally。
入门
简介
esrally 是 elastic 官方开源的一款基于 python3 实现的针对 es 的压测工具，源码地址为https://github.com/elastic/rally，相关博客介绍在这里。esrally主要功能如下：
- 自动创建、压测和销毁 es 集群
- 可分 es 版本管理压测数据和方案
- 完善的压测数据展示，支持不同压测之间的数据对比分析，也可以将数据存储到指定的es中进行二次分析
- 支持收集 JVM 详细信息，比如内存、GC等数据来定位性能问题
elastic 官方也是基于 esrally 进行 es 的性能测试，并将结果实时发布到 https://elasticsearch-benchmarks.elastic.co/ ，大家可以从该网站上直接查看 es 的性能。官方使用两台服务器进行压测，一台运行 esrally ，一台运行 es，服务器的配置如下：
CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
RAM: 32 GB
SSD: Crucial MX200
OS: Linux Kernel version 4.8.0-53
JVM: Oracle JDK 1.8.0_131-b11
网站顶部的 Geonames、Geopoint、Percolator等都是针对不同的数据集做的压测，比如下面这些图展示了 logging 日志类数据的压测结果。
快速入门
esrally 的文档在这里，这里简单说下安装与运行。
esrally 对于软件环境的要求如下：
- Python 3.4+ 和 pip3
- JDK 8
- git 1.9+
安装方法为：
pip3 install esrally
Tips:
可以使用国内的pip源，比如豆瓣或者阿里的，这样安装会快很多。
安装完毕后执行如下的配置命令，确认一些数据存放的路径即可。
esrally configure
接下来就可以开跑了，比如下面这条命令是针对 es 5.0.0 版本进行压力测试。
esrally --distribution-version=5.0.0
运行结束后，会得到如下的结果。
对于第一次见到压测结果的同学来说可能有些晕，这么多数据，该怎么看？！别急，一步步来！
Tips:
由于 esrally 的测试数据存储在国外 aws 上，导致下载很慢甚至会超时失败，从而导致整个压测无法进行。后面我会把这些测试数据的压缩包放到国内，大家可以下载后直接放到 esrally 的数据文件夹下面，保证压测的正常进行。另外由于数据量过大，压测的时间一般会很久，可能在1个小时左右，所以大家要有耐心哦~
如果你只是想体验下，可以加上 --test-mode 的参数，此时只会下载1000条文档进行测试。
相关术语
rally 是汽车拉力赛的意思，也就是说 esrally 是将压测比作了汽车拉力赛，因此其中的很多术语都是从汽车拉力赛中借鉴来的。
track
track 是赛道的意思，在这里是指压测用的数据和测试策略，详细文档在这里。esrally 自带的track都在 github 上，地址在这里 https://github.com/elastic/rally-tracks。在该 repository 中，有很多测试数据，比如 geonames geopoint logging nested 等，每个数据文件夹中的 README.md 中有详细的数据介绍，而 track.json 便是压测策略的定义文件。
我们来看下 loggins/track.json 文件
{% import "rally.helpers" as rally with context %}
{
"short-description": "Logging benchmark",
"description": "This benchmark indexes HTTP server log data from the 1998 world cup.",
"data-url": "http://benchmarks.elasticsearc ... ot%3B,
"indices": [
{
"name": "logs-181998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-181998.json.bz2",
"document-count": 2708746,
"compressed-bytes": 13815456,
"uncompressed-bytes": 363512754
}
]
},
{
"name": "logs-191998",
"types": [
{
"name": "type",
"mapping": "mappings.json",
"documents": "documents-191998.json.bz2",
"document-count": 9697882,
"compressed-bytes": 49439633,
"uncompressed-bytes": 1301732149
}
]
}
],
"operations": [
{{ rally.collect(parts="operations/*.json") }}
],
"challenges": [
{{ rally.collect(parts="challenges/*.json") }}
]
}- description 和 short-description: track 的描述文字
- data-url: 一个url地址，指明测试数据的下载根路径，与下方 indices 中的 documents 结合，可得到数据的下载地址。
- indices: 指定该track可以操作的索引，包括创建、更新、删除等操作。详细信息可以参见这里。
- operations: 指定具体的操作，比如 index 索引数据的操作、force-merge 强制合并segment的操作、search 搜索的操作等等。具体例子可以看下面的示例。详细信息可以参见这里。
- challenges: 通过组合 operations 定义一系列 task ，再组合成一个压测的流程，请参照下方的 例子。详细信息可以参见这里。
operations/default.json 中的一个定义如下：
{
"name": "index-append",
"operation-type": "index",
"bulk-size": 5000
}
challenges/default.json 中的一个定义如下：
{
"name": "append-no-conflicts",
"description": "",
"default": true,
"index-settings": {
"index.number_of_replicas": 0
},
"schedule": [
{
"operation": "index-append",
"warmup-time-period": 240,
"clients": 8
},
{
"operation": "force-merge",
"clients": 1
},
{
"operation": "index-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "node-stats",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 50
},
{
"operation": "default",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 10
},
{
"operation": "term",
"clients": 1,
"warmup-iterations": 100,
"iterations": 500,
"target-throughput": 60
},
{
"operation": "range",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 2
},
{
"operation": "hourly_agg",
"clients": 1,
"warmup-iterations": 100,
"iterations": 100,
"target-throughput": 0.2
},
{
"operation": "scroll",
"clients": 1,
"warmup-iterations": 100,
"iterations": 200,
"target-throughput": 10
}
]
}通过下面的命令可以查看当前 esrally 可用使用的track。
esrally list tracks
esrally 的 track 数据位于 rally 目录(mac默认是 ~/.rally)中 benchmarks/tracks/ 下面。
car
car 是赛车的意思，这里是指不同配置的 es 实例。通过下面的命令可以查看 esrally 当前可用的 car。
esrally list cars
Name
----------
16gheap
1gheap
2gheap
4gheap
8gheap
defaults
ea
verbose_iw
cars 的配置位于 rally 目录(mac默认是 ~/.rally)中 benchmarks/teams/default/cars/ 下面。具体配置可以参见 cars 的文档，除了 heap 的配置，所有的 es 配置都可以修改。
race
race 是一次比赛的意思，这里是指某一次压测。要比赛，就要有赛道和赛车，如果不指定赛车，就用 default 配置，如果不指定赛道，则默认使用 geonames track。通过下面的命令来执行一次 race。
esrally race --track=logging --challenge=append-no-conflicts --car="4gheap"
上面的命令便是执行一次压测，并指定使用 logging 的track，运行该 track 中的 append-no-conflicts 的 challenge，指定的 car 为 4gheap 的 es 实例。详情可以查看 race 相关文档。
Tournament
tournament 是锦标赛的意思，是由多个 race 组成的。通过下面的命令可以查看所有的 race。
esrally list races
Recent races:
Race Timestamp Track Challenge Car User Tag
---------------- ------- ------------------- -------- ------------------------------
20160518T122341Z pmc append-no-conflicts defaults intention:reduce_alloc_1234
20160518T112057Z pmc append-no-conflicts defaults intention:baseline_github_1234
20160518T101957Z pmc append-no-conflicts defaults
esrally compare --baseline=20160518T112057Z --contender=20160518T112341Z
详细信息可以参见 tournament 的文档。
Pipeline
Pipeline 在这里是指压测的一个流程，通过下面的命令可以查看已有的pipeline。
esrally list pipeline
Name Description
----------------------- ---------------------------------------------------------------------------------------------
from-sources-complete Builds and provisions Elasticsearch, runs a benchmark and reports results.
from-sources-skip-build Provisions Elasticsearch (skips the build), runs a benchmark and reports results.
from-distribution Downloads an Elasticsearch distribution, provisions it, runs a benchmark and reports results.
benchmark-only Assumes an already running Elasticsearch instance, runs a benchmark and reports results
- from-sources-complete 是从源代码编译 es 后再运行，可以通过 --revision 参数指明要编译的commit hash ，这样就可以针对某一个提交版本就行测试了。
- from-sources-skip-build 如果已经编译好了，使用该 pipeline，可以跳过编译的流程，节省测试时间
- from-distribution 通过 --distribution-version 指定 es 版本，esrally 会从官网直接下载该版本的可执行文件，然后进行测试。
- benchmark-only 此 pipeline 将 es 集群的管理交由用户来处理， esrally 只做压测。如果你想针对已有集群进行测试，那么要将pipeline设定为该模式。
详细信息请参见 pipeline 的文档。
压测流程
esrally 的压测流程主要分为以下三个步骤：
- 根据参数设定自行编译或者下载 es 可执行实例，然后根据 car 的约定，创建并启动 es 集群。如果使用 benchmark-only 的pipeline，则该步骤省略。
- 根据指定 track 去下载数据，然后按照指定的 challenge 进行操作。
- 记录并输出压测结果数据。
压测结果分析
压测结束后，esrally 会将结果输出到终端和结果文件（位于 esrally 目录logs 和 benchmarks/races）中，如下图所示：
在 Metric 一栏，有非常多的指标数据，详细的解释可以参见该文档。一般要关注的数据有：
- throughput 每个操作的吞吐量，比如 index、search等
- latency 每个操作的响应时长数据
- Heap used for x 记录堆栈的使用情况
先搞懂每个 metric 的含义，然后根据自己的需求去确认自己要关注的指标。
每一次压测都会以压测时的时间命名，比如 logs/rally_out_20170822T082858Z.log ，这个日志便是记录的 2017年8月22日 8:28:58开始的压测日志。而在 benchmarks/races/2017-08-22-08-28-58 中记录着最终的结果和 es 的运行日志。
另外对于 benchmark-only 模式的测试，即针对已有集群的压力测试，也可以通过安装 X-Pack Basic 版本进行监控（Monitoring），在压测的过程中就能查看相关指标。
esrally 可以在配置的时候指定将所有的 race 压测结果数据存入一个指定的 es 实例中，配置如下(在 esrally 目录中 rally.ini 文件中)：
[reporting]
datastore.type = elasticsearch
datastore.host = localhost
datastore.port = 9200
datastore.secure = False
datastore.user =
datastore.password =- rally-metrics-* 该索引分指标记录每次 race 的结果，如下图所示为某一次race的所有 metric 数据。
- rally-result-* 该索引分指标记录了每次 race 的最终汇总结果，比如下面这条数据。
{
"user-tag": "shardSizeTest:size6",
"distribution-major-version": 5,
"environment": "local",
"car": "external",
"plugins": [
"x-pack"
],
"track": "logging",
"active": true,
"distribution-version": "5.5.2",
"node-count": 1,
"value": {
"50_0": 19.147876358032228,
"90_0": 21.03116340637207,
"99_0": 41.644479789733886,
"100_0": 47.20634460449219
},
"operation": "term",
"challenge": "default-index",
"trial-timestamp": "20170831T063724Z",
"name": "latency"
}rally-races-* 该索引记录了所有 race 的最终结果，即命令行执行的输出结果。
除了es相关指标数据外，esrally 还会同时记录测试的一些环境信息，比如操作系统、JVM等等，你可以方便的查看本次测试的软硬件环境。
实战
终于到了开赛的时候，下面我们采用问答的形式来进行，希望大家看到问题后先自己思考下再看答案。
问题一
提问：如何对比 5.5.0 相比 2.4.6 的性能改进？
回答：
分别针对 5.5.0 和 2.4.6 做一次压测，然后比较两者两者的相关指标即可，这里我们的 track 和 challenge 如下：
track: nyc_taxis
challenge: append-no-conflicts
测试步骤如下：
1.测试 2.4.6 的性能
esrally race --distribution-version=2.4.6 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:2.4.6"
2.测试 5.5.0 的性能
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="version:5.5.0"
3.对比两次 race 的结果
esrally list races
esrally compare --baseline=[2.4.6 race] --contender=[5.5.0 race]
Tips:
--user-tag 用于为 race 打标签，方便后续查找
如果只是试一下，可以加上 --test-mode ，用测试数据来跑，很快。
问题二
提问：如何测试 _all 关闭后对于写性能的影响？
回答：
针对 5.5.0 版本的 es 做两次测试，第一次开启 _all，第二次关闭 _all，对比两次的结果，由于只测试写性能，所以我们只需要 index 类型的 operation执行。这里我们的 track 和 challenge 如下：
- track: nyc_taxis
- challenge: append-no-conflicts
测试步骤如下：
1.默认 nyc_taxis 的 mapping 设置是将 _all 关闭的，直接测试 _all 关闭时的性能。
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:false" --include-tasks="type:index"
2.修改 nyc_taxis 的 mapping 设置，打开 _all。mapping 文件位于 rally 主目录 benchmarks/tracks/default/nyc_taxis/mappings.json，修改 _all.enabled 为 true。
esrally race --distribution-version=5.5.0 --track=nyc_taxis --challenge=append-no-conflicts --user-tag="enableAll:true" --include-tasks="type:index"
3.对比两次 race 的结果
esrally list races
esrally compare --baseline=[enableAll race] --contender=[disableAll race]
下图是我在 --test-mode 模式下运行的对比结果，也可以看出关闭 _all 可以提升写性能。
Tips:
--include-tasks 用于只运行 challenge 中的部分 task
问题三
提问：如何测试已有集群的性能？
回答：
使用 benchmark-only 的 pipeline 即可，这里我们的 track 和 challenge 如下：
- track: nyc_taxis
- challenge: append-no-conflicts
测试步骤如下：
1.执行下方命令即可测试已有集群
esrally race --pipeline=benchmark-only --target-hosts=127.0.0.1:9200 --cluster-health=yellow --track=nyc_taxis --challenge=append-no-conflicts
Tips:
--cluster-health=yellow 默认 esrally 会检查集群状态，非 green 状态会直接退出。添加该参数可以避免该情况
希望这三个问答可以帮助到大家快速掌握 esrally 的用法。
进阶
自定义 car
前面讲解 car 的时候，我们提到 esrally 已经自带了一些可用的 es 配置，但是如果这些还不能满足你的时候，可以通过下面两个方案解决。
1.定制自己的car
car 的配置文件位于 esrally 目录 benchmarks/teams/default/cars，在这里新增一个自己的 car 配置文件就可以了。这里就不赘述了，感兴趣的可以查阅 car 的文档。
2.自己搭建集群
最简单的方式是脱离 esrally 的管理，自行搭建集群，这样想怎么配置就怎么配置了。
自定义 track
虽然 esrally 自带了很多 track，而且这些数据本身也不小，简单列在下面：
Track 压缩数据大小 解压数据大小 文档数
geonames 252 MB 3.3 GB 11396505
geopoint 482 MB 2.3 GB 60844404
logging 1.2 GB 31 GB 247249096
nested 663 MB 3.3 GB 11203029
noaa 947 MB 9 GB 33659481
nyc_taxis 4.5 GB 74 GB 165346692
percolator 103KB 105 MB 2000000
pmc 5.5 GB 22 GB 574199当我们做定向测试的时候，还是希望针对自己的数据进行压测，此时可以自定义 track。操作也很简单，详情可以参考官方文档。这里简单列一下操作步骤。
- 在 上文提到的 data 目录中创建自己的数据目录。
- 准备压测数据文件。 esrally 使用的是一个json文件，其实是一个一个 json object。
- 将准备好的数据文件压缩成 bz2 格式，然后复制到步骤 1 创建的目录中去。
- 新增自定义的track。可以直接复制 geoname 目录，然后修改相关的配置文件，将测试数据与 track 绑定。
- 添加完后，通过 esrally list rack 就可以看到自定义的 track。
分布式压测
esrally 还支持分布式压测，即如果一个节点的 esrally 无法达到要求的并发数、请求数，那么可以将 esrally 分布到多台机器上去同时执行。分布式压测文档在这里，此处用到了 esrally dameon，对应命令是 esrallyd 。简单讲就是 esrally 通过 esrallyd 将多台机器组合成一个集群，然后 esrally 在执行测试任务的时候通过制定 --load-driver-hosts 便可以将测试任务分发到对应的机器上执行。这里便不赘述了，感兴趣的去看前面提到的文档。
最后一个问题
让我们回到开头提到的容量规划的问题吧！
提问：一个 index 的 shard 数该如何确认？
回答：
其实针对这个提问，还可以再问下面两个问题。
- shard 设置过少是否有问题？比如一直都采用默认的 5个分片
- shard 设置过多是否有问题？比如直接设置为100个分片
要回到这两个问题，我们得先知道 shard 的作用。shard 是 es 实现分布式特性的基石，文档在索引进 es 时，es 会根据一个路由算法，将每一个文档分配到对应的 shard 上。每个 shard 实际对应一个 lucene index。那么每个 shard 能存储的文档数是否有上限呢？答案是有！每个shard最多存储 2^31 个文档，即 20亿。这是 lucene 设计决定的。那是不是只要我的文档数没有超过20亿，就可以只用一个或者很少的shard 呢？不尽然。因为随着 shard 体积的增大，其查询效率会下降，而且数据迁移和恢复的成本也会增高。官方建议单个 shard 大小不要超过 50GB，可以参见讨论一和讨论二。
现在回答上面的两个问题。
shard数过小不一定好，如果数据量很大，导致每个 shard 体积过大，会影响查询性能。
shard数过大也不一定好，因为 es 的每次查询是要分发给所有的 shard 来查询，然后再对结果做聚合处理，如果 shard 数过多也会影响查询性能。因此 shard 的数量需要根据自己的情况测出来。
官方文档有一节关于容量规划的章节，建议大家去看一下，链接在这里，其给出的步骤如下：
- 使用生产环境的硬件配置创建单节点集群
- 创建一个只有一个主分片无副本的索引，设置相关的mapping信息
- 将真实的文档导入到步骤 2 的索引中
- 测试实际会用到的查询语句
测试的过程中，关注相关指标数据，比如索引性能、查询性能，如果在某一个点相关性能数据超出了你的预期值，那么此时的 shard size大小便是符合你预期的单个 shard size的大小。接下来通过下面这个简单的计算公式便大致能确定一个 index 需要设定的 shard 数了。
shard数 = index 的数据总大小/单个shard size的极限值
比如你测出单个 shard size 最大为 20 GB，而你预测该索引数据最大量在1年或者2年内不会超过 200GB，那么你的 shard 数就可以设置为10。
接下来要做的事情也很明确，我们要用 esrally 完成上面的压测步骤：
1.自行维护 es 节点的创建和运行，esrally 运行的时候采用 benchmark-only 模式.
2.自定义 track，这里有以下两个重点：
- 生成真实数据。如果你的数据无法生成很多，那么可以在 track 的 schedule 中设置 iterations 参数，即循环进行同一个操作，这样也可以测试大数据量的写性能。
- 定义自己的查询任务。在 track 的 operations 中是可以定义自己的查询语句的，比如下面这个
其中的 body 便是自定义的查询语句，所以你可以通过自己的需求来设定查询语句，以贴近实际使用的情况。{ "name": "hourly_agg", "operation-type": "search", "index": "logs-*", "type": "type", "body": { "size": 0, "aggs": { "by_hour": { "date_histogram": { "field": "@timestamp", "interval": "hour" } } } }}
3.还要记得设置索引的 mapping 与线上一致，比如是否启用 _all 等设置。
4.基于自定义的track来进行压测即可。要注意的是运行 esrally 的机器要和 es 机器分开，防止对 es 性能产生干扰。
Tips:
esrally 默认在每次压测是会删除已有的索引后再重新创建索引，如果你不想这样，可以在每个 index 的配置中设置 auto-managed 为 false，具体文档在这里。
通过这个参数，你就可以单独压测查询性能了，而不用每次都要先经过漫长的导入数据的过程。
总结
esrally 针对 es 的压测设计了一套完备的基于配置文件的测试流程，极大地简化了操作难度，并且提供了可重复验证的方式。对国内用户来讲，我认为最大的难处还是在于 esrally 自带的 track 文件太大，从 国外 aws 下载很慢。好在可以自定义 track，不必完全依赖自带的 track。
其他没啥好说的，esrally 棒棒哒，大家赶紧去试试吧，如果有问题欢迎来讨论！
点击查看更好的排版
收起阅读 »
社区日报 第47期 (2017-09-14)
http://t.cn/RpWnkWI
2.干货：携程wood叔告诉你，ES 5.x Bulk update重复的文档id为什么性能低下。
https://elasticsearch.cn/article/273
3.详解elasticsearch中的乐观并发控制。
http://t.cn/RpWnrDX
编辑：金桥
归档：https://elasticsearch.cn/article/274
订阅：https://tinyletter.com/elastic-daily
http://t.cn/RpWnkWI
2.干货：携程wood叔告诉你，ES 5.x Bulk update重复的文档id为什么性能低下。
https://elasticsearch.cn/article/273
3.详解elasticsearch中的乐观并发控制。
http://t.cn/RpWnrDX
编辑：金桥
归档：https://elasticsearch.cn/article/274
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
