话题 (es) 已与当前话题合并
elasticsearch

elasticsearch

Elasticsearch使用TransportClient索引数据时,服务器报错。java.io.IOException: 远程主机强迫关闭了一个现有的连接

Elasticsearchjasonluelastic 回复了问题 • 5 人关注 • 5 个回复 • 4719 次浏览 • 17 小时前 • 来自相关话题

Kibana3 中pie的Queries选项的select在Kibana5怎么实现?

回复

KibanaEric_L 回复了问题 • 1 人关注 • 3 个回复 • 39 次浏览 • 22 小时前 • 来自相关话题

用bulk 批量删除时,有些已经删除了再删除的时候会报错

Elasticsearchlaoyang360 回复了问题 • 2 人关注 • 1 个回复 • 59 次浏览 • 1 天前 • 来自相关话题

刨根问底 | Elasticsearch 5.X集群多节点角色配置深入详解

Elasticsearchlaoyang360 发表了文章 • 2 个评论 • 48 次浏览 • 1 天前 • 来自相关话题

http://mp.weixin.qq.com/s/fqy-UVGDDg35uSOEqDbaiA

关于elasticsearch查询优化问题

Elasticsearchnapoay 回复了问题 • 3 人关注 • 2 个回复 • 105 次浏览 • 1 天前 • 来自相关话题

elasticsearch-jdbc插件的自动更新脚本运行一段时间就会报错

Elasticsearchelastictech 回复了问题 • 3 人关注 • 5 个回复 • 92 次浏览 • 1 天前 • 来自相关话题

logstash配置out自定义模板到ES失败

回复

Elasticsearcha6676726 发起了问题 • 1 人关注 • 0 个回复 • 36 次浏览 • 1 天前 • 来自相关话题

ELK使用时:报错远程主机强迫关闭了一个现有的连接。

Elasticsearchkennywu76 回复了问题 • 2 人关注 • 1 个回复 • 42 次浏览 • 2 天前 • 来自相关话题

Elasticsearch5 java 设置mappings

Elasticsearchkennywu76 回复了问题 • 2 人关注 • 1 个回复 • 94 次浏览 • 2 天前 • 来自相关话题

es windows服务启动时的权限问题

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 73 次浏览 • 2 天前 • 来自相关话题

Elasticsearch使用TransportClient索引数据时,服务器报错。java.io.IOException: 远程主机强迫关闭了一个现有的连接

回复

Elasticsearchjasonluelastic 回复了问题 • 5 人关注 • 5 个回复 • 4719 次浏览 • 17 小时前 • 来自相关话题

Kibana3 中pie的Queries选项的select在Kibana5怎么实现?

回复

KibanaEric_L 回复了问题 • 1 人关注 • 3 个回复 • 39 次浏览 • 22 小时前 • 来自相关话题

用bulk 批量删除时,有些已经删除了再删除的时候会报错

回复

Elasticsearchlaoyang360 回复了问题 • 2 人关注 • 1 个回复 • 59 次浏览 • 1 天前 • 来自相关话题

关于elasticsearch查询优化问题

回复

Elasticsearchnapoay 回复了问题 • 3 人关注 • 2 个回复 • 105 次浏览 • 1 天前 • 来自相关话题

elasticsearch-jdbc插件的自动更新脚本运行一段时间就会报错

回复

Elasticsearchelastictech 回复了问题 • 3 人关注 • 5 个回复 • 92 次浏览 • 1 天前 • 来自相关话题

logstash配置out自定义模板到ES失败

回复

Elasticsearcha6676726 发起了问题 • 1 人关注 • 0 个回复 • 36 次浏览 • 1 天前 • 来自相关话题

ELK使用时:报错远程主机强迫关闭了一个现有的连接。

回复

Elasticsearchkennywu76 回复了问题 • 2 人关注 • 1 个回复 • 42 次浏览 • 2 天前 • 来自相关话题

Elasticsearch5 java 设置mappings

回复

Elasticsearchkennywu76 回复了问题 • 2 人关注 • 1 个回复 • 94 次浏览 • 2 天前 • 来自相关话题

es windows服务启动时的权限问题

回复

Elasticsearchmedcl 回复了问题 • 2 人关注 • 1 个回复 • 73 次浏览 • 2 天前 • 来自相关话题

es中字段如何匹配空字符串

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 122 次浏览 • 2 天前 • 来自相关话题

刨根问底 | Elasticsearch 5.X集群多节点角色配置深入详解

Elasticsearchlaoyang360 发表了文章 • 2 个评论 • 48 次浏览 • 1 天前 • 来自相关话题

http://mp.weixin.qq.com/s/fqy-UVGDDg35uSOEqDbaiA

一个仿Linux 控制台的ES的_cat的插件

开源项目psfu 发表了文章 • 3 个评论 • 98 次浏览 • 4 天前 • 来自相关话题

简化_cat使用,可以直接输入 cat 命令 ,可以滚动查看历史结果支持字体放大缩小支持命令历史记录(通过上下方向键来切换 )支持鼠标划取的复制粘贴(暂不复制到剪贴板)安装后在 http://127.0.0.1:9200/_console  使用,也可本地使用:直接访问html文件
 
GIT 地址
 
欢迎加 576037940 这个群讨论哈
  查看全部
00-console.png

  • 简化_cat使用,可以直接输入 cat 命令 ,可以滚动查看历史结果
  • 支持字体放大缩小
  • 支持命令历史记录(通过上下方向键来切换 )
  • 支持鼠标划取的复制粘贴(暂不复制到剪贴板)
  • 安装后在 http://127.0.0.1:9200/_console  使用,也可本地使用:直接访问html文件

 
GIT 地址
 
欢迎加 576037940 这个群讨论哈
 

【翻译】Elasticsearch索引性能优化(2)

Elasticsearchnodexy 发表了文章 • 0 个评论 • 133 次浏览 • 5 天前 • 来自相关话题

本文翻译自QBox官方博客的“Elasticsearch索引性能优化”系列文章中的第二篇,版权归原作者 Adam Vanderbush所有。该系列文章共有三篇,其中第一篇已有同行翻译,参考链接http://www.zcfy.cc/article/how ... .html   后续还会有第三篇的推送,敬请关注。

 
作者:Adam Vanderbush
译者:杨振涛@vivo
 
本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。

Elasticsearch是准实时的,这表示当索引一个文档后,需要等待下一次刷新后就可以搜索到该文档了。

刷新是一个开销较大的操作,这就是为什么默认要设置一个特定的间隔,而不是每索引一个文档就刷新一次。如果想索引大批量的文档,并不需要立刻就搜索到新的索引信息,为了优化索引性能甚至搜索性能,可以临时降低刷新的频率,直到索引操作完成。

一个索引库的分片由多个段组成。Lucene的核心数据结构中,一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建,随后会在后台合并到一起,以保证资源的高效使用;每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并,一旦处理不当,可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。

本文将继续关注Elasticsearch的索引性能调优,重点聚焦在集群和索引级别的各种索引配置项设置。

 
1 关注refresh_interval参数

这个间隔通过参数index.refresh_interval设置,既可以在Elasticsearch配置文件里全局设置,也可以针对每一个索引库单独设置。如果同时设置,索引库设置会覆盖全局配置。默认值是1s,因此最新索引的文档最多不超过1s后即可搜索到。

因为刷新是非常昂贵的操作,提升索引吞吐量的方式之一就是增大refresh_interval;更少的刷新意味着更低的负载,并且更多的资源可以向索引线程倾斜。因此,根据搜索需求,可以考虑设置刷新间隔为大于1秒的值;甚至可以考虑在某些时候,比如执行批量索引时,临时关闭索引库的刷新操作,执行结束后再手动打开。

更新设置API可以在批量索引时动态改变索引以便更加高效,然后再修改为更加实时的索引状态。在批量索引开始前,设置:$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果要做一次较大的批量导入,可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后,整个文档会被发送到副本节点,并重复索引过程;这意味着每个副本都会执行分析、索引及可能的合并操作。反之,如果索引时设置0副本,完成后再打开副本支持,恢复过程实质上只是一个网络字节流传输的过程,这比重复索引过程要高效得多了。curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
"index" : {
"number_of_replicas" : 0
}
}'
然后一旦批量索引完成,即可更新设置(比如恢复成默认设置):curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'
并且可以强制触发一次合并:curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'
刷新API支持显式地刷新一个或多个索引库,以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如,内置引擎要求显式调用刷新,而默认地刷新是周期性执行的。curl -XPOST 'localhost:9200/my_index/_refresh'

 2 段与合并

段合并是一个计算开销较大的操作,而且会消耗大量的磁盘I/O。由于合并操作比较耗时,尤其是较大的段,所以一般设定为后台执行;这也没什么太大问题,因为大段的合并相对还是比较少的。

但也有时候,合并速率会低于生产速率;一旦如此,Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题,否则在合并前可能会生成数百个段。

Elasticsearch在这里默认是比较保守的:不希望搜索性能受到后台合并操作的挤兑;但有时(尤其是使用SSD,或写日志的场景)节流限制会过低。

默认的20 MB/s对于传统机械磁盘是一个挺不错的设置;如果使用SSD,可能要考虑加大该设置到100–200 MB/s。curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'
如果正在做批量导入,且根本不介意搜索,就可以彻底关闭合并限流;这样索引操作就会根据磁盘的速率尽可能快地执行:curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'
设置限流类型为none就可以完全关闭合并限流;等批量导入完成后再恢复该配置项为merge。curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "merge"
}
}'
注意:上面的设置只适用于Elasticsearch 1.X版本,Elasticsearch 2.X移除了索引级别的速率限制(indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec),下沉到Lucene的ConcurrentMergeScheduler,以自动管理限流。

合并调度器(ConcurrentMergeScheduler)在需要时会控制合并操作的执行。合并操作运行在独立的线程池中,一旦达到最大线程数,更多的合并请求将会阻塞等待,直到有可用的合并线程。

合并调度器支持下列动态设置: 
index.merge.scheduler.max_thread_count

最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2)),对于固态硬盘(SSD)工作得很好;如果使用传统机械硬盘,则降低到1。

机械介质在并发I/O方面有较大的时间开销,因此需要减少线程数,以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘,所以设置为1表示支持3个线程。

如果使用机械硬盘而不是SSD,就要在elasticsearch配置文件中加入以下配置: 
index.merge.scheduler.max_thread_count: 1

当然也可以为单个索引库设置:curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
为所有已创建的索引库设置:curl -XPUT 'localhost:9200/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'


 3 事务日志的清理

在节点挂掉时事务日志可以防止数据丢失,设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒,或者在每个索引、删除、更新或批量请求(不管先后顺序)完成时,会提交到磁盘一次。

对Lucene的变更仅会在一次Lucene提交后持久化到磁盘,Lucene提交是比较重量级的操作,索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时,一次提交后或另一次提交前的变更将会丢失。

为防止这些数据丢失,每个分片有一个事务日志,或者与之关联的预写日志。任何索引或删除操作,在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后,就可以从事务日志回放最近的事务来恢复分片。

Elasticsearch的flush操作,本质上是执行了一次Lucene提交并启动了一个新的事务日志;这些都是在后台自动完成的,目的是确保事务日志不会变得过大,否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用,虽然很少需要手动触发。

与刷新(refresh)一个索引分片相比,真正昂贵的操作是flush其事务日志(这涉及到Lucene提交)。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐,延迟flush最终实际执行时显然会消耗更长的时间。

下列可动态更新的配置控制着内存缓存刷新到磁盘的频率:

index.translog.flush_threshold_size - 一旦事务日志达到这个值,就会发生一次flush;默认值为512mb。

index.translog.flush_threshold_ops - 在多少操作后执行flush,默认无限制。

index.translog.flush_threshold_period - 触发一次flush前的等待时间,不管日志大小,默认值为30分钟。

index.translog.interval - 检查是否需要flush的时间间隔,随机在该时间到2倍之间取值,默认为5秒。

可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB,这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段,就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。

当然,这需要一定数量的可用堆内存,用于额外的缓存空间,所以调整此类配置时请注意这一点。


 4 索引缓冲区的容量规划

索引缓冲区用于存储新的索引文档,如果满了,缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。

下列配置项是静态的,并且必须在集群的每个数据节点上都配置:

indices.memory.index_buffer_size - 可设置为百分比或者字节数大小,默认是10%,表示总内存的10%分配给该节点,作为索引缓冲区大小,全局共享。

indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比,那么这项配置用于指定一个绝对下限,默认是48MB。

indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比,那么这项配置用于指定一个绝对上限,默认是无限制。

配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比(剩余堆内存将主要用于检索操作)。如果要索引很多数据,默认的10%可能会太小,有必要调大该值。


5 索引和批量操作的线程池大小

接下来试试在节点级别调大索引和批量操作的线程池大小,看看否带来性能提升。

index - 用于索引和删除操作。线程类型是固定大小的(fixed),默认大小是可用处理器核数,队列大小queue_size是200,该线程池最大为1+可用处理器核数。

bulk - 用于批量操作。线程类型是固定大小的,默认大小是可用处理器核数,队列大小是50,线程池最大为1+可用处理器核数。

单个分片与独立的Lucene是一个层次,因此同时执行索引的并发线程数是有上限的,在Lucene中默认是8,而在ES中可以通过index.index_concurrency配置项来设置。

在为该参数设置默认值时应当多想一想,特别是对于往一个索引库索引数据时,一个节点只有一个分片的情况。

由于索引/批量线程池可以保护和控制并发,所以大部分时候都可以考虑调大默认值;尤其是对于节点上没有其他分片的情况(评估是否值得),可以考虑调大该值。


关于译者

杨振涛

vivo互联网搜索引擎团队负责人,开发经理。10年数据和软件领域经验,先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化,尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者,TED Translator,InfoQ中文社区编辑。

 
 
未经授权,禁止转载。
 
英文原文地址:https://qbox.io/blog/maximize- ... art-2  查看全部


本文翻译自QBox官方博客的“Elasticsearch索引性能优化”系列文章中的第二篇,版权归原作者 Adam Vanderbush所有。该系列文章共有三篇,其中第一篇已有同行翻译,参考链接http://www.zcfy.cc/article/how ... .html   后续还会有第三篇的推送,敬请关注。


 
作者:Adam Vanderbush
译者:杨振涛@vivo
 
本系列文章重点关注如何最大化地提升elasticsearch的索引吞吐量和降低监控与管理负荷。

Elasticsearch是准实时的,这表示当索引一个文档后,需要等待下一次刷新后就可以搜索到该文档了。

刷新是一个开销较大的操作,这就是为什么默认要设置一个特定的间隔,而不是每索引一个文档就刷新一次。如果想索引大批量的文档,并不需要立刻就搜索到新的索引信息,为了优化索引性能甚至搜索性能,可以临时降低刷新的频率,直到索引操作完成。

一个索引库的分片由多个段组成。Lucene的核心数据结构中,一个段本质上是索引库的一个变更集。这些段是在每次刷新时所创建,随后会在后台合并到一起,以保证资源的高效使用;每个段都会消耗文件句柄、内存和CPU。工作在该场景背后的Lucene负责段的合并,一旦处理不当,可能会消耗昂贵的计算资源并导致Elasticsearch自动降级索引请求到一个单一线程上。

本文将继续关注Elasticsearch的索引性能调优,重点聚焦在集群和索引级别的各种索引配置项设置。

 
1 关注refresh_interval参数

这个间隔通过参数index.refresh_interval设置,既可以在Elasticsearch配置文件里全局设置,也可以针对每一个索引库单独设置。如果同时设置,索引库设置会覆盖全局配置。默认值是1s,因此最新索引的文档最多不超过1s后即可搜索到。

因为刷新是非常昂贵的操作,提升索引吞吐量的方式之一就是增大refresh_interval;更少的刷新意味着更低的负载,并且更多的资源可以向索引线程倾斜。因此,根据搜索需求,可以考虑设置刷新间隔为大于1秒的值;甚至可以考虑在某些时候,比如执行批量索引时,临时关闭索引库的刷新操作,执行结束后再手动打开。

更新设置API可以在批量索引时动态改变索引以便更加高效,然后再修改为更加实时的索引状态。在批量索引开始前,设置:
curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'

如果要做一次较大的批量导入,可以考虑设置index.number_of_replicas: 0来禁止副本。当设置了副本后,整个文档会被发送到副本节点,并重复索引过程;这意味着每个副本都会执行分析、索引及可能的合并操作。反之,如果索引时设置0副本,完成后再打开副本支持,恢复过程实质上只是一个网络字节流传输的过程,这比重复索引过程要高效得多了。
curl -XPUT 'localhost:9200/my_index/_settings' -d ' {
"index" : {
"number_of_replicas" : 0
}
}'

然后一旦批量索引完成,即可更新设置(比如恢复成默认设置):
curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"refresh_interval" : "1s"
}
}'

并且可以强制触发一次合并:
curl -XPOST 'localhost:9200/my_index/_forcemerge?max_num_segments=5'

刷新API支持显式地刷新一个或多个索引库,以便让上次刷新后的所有操作完成并可被搜索感知。实时或近实时能力取决于所使用的索引引擎。比如,内置引擎要求显式调用刷新,而默认地刷新是周期性执行的。
curl -XPOST 'localhost:9200/my_index/_refresh'


 2 段与合并

段合并是一个计算开销较大的操作,而且会消耗大量的磁盘I/O。由于合并操作比较耗时,尤其是较大的段,所以一般设定为后台执行;这也没什么太大问题,因为大段的合并相对还是比较少的。

但也有时候,合并速率会低于生产速率;一旦如此,Elasticsearch将会自动地限流索引请求到一个单一线程。这能阻止段爆发问题,否则在合并前可能会生成数百个段。

Elasticsearch在这里默认是比较保守的:不希望搜索性能受到后台合并操作的挤兑;但有时(尤其是使用SSD,或写日志的场景)节流限制会过低。

默认的20 MB/s对于传统机械磁盘是一个挺不错的设置;如果使用SSD,可能要考虑加大该设置到100–200 MB/s。
curl -XPUT 'localhost:9200/test/_settings' -d '{
"index" : {
"refresh_interval" : "-1"
}
}'

如果正在做批量导入,且根本不介意搜索,就可以彻底关闭合并限流;这样索引操作就会根据磁盘的速率尽可能快地执行:
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "none"
}
}'

设置限流类型为none就可以完全关闭合并限流;等批量导入完成后再恢复该配置项为merge。
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
"transient" : {
"indices.store.throttle.type" : "merge"
}
}'

注意:上面的设置只适用于Elasticsearch 1.X版本,Elasticsearch 2.X移除了索引级别的速率限制(indices.store.throttle.type、 indices.store.throttle.max_bytes_per_sec、index.store.throttle.type、 index.store.throttle.max_bytes_per_sec),下沉到Lucene的ConcurrentMergeScheduler,以自动管理限流。

合并调度器(ConcurrentMergeScheduler)在需要时会控制合并操作的执行。合并操作运行在独立的线程池中,一旦达到最大线程数,更多的合并请求将会阻塞等待,直到有可用的合并线程。

合并调度器支持下列动态设置: 
index.merge.scheduler.max_thread_count

最大线程数默认为 Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors() / 2)),对于固态硬盘(SSD)工作得很好;如果使用传统机械硬盘,则降低到1。

机械介质在并发I/O方面有较大的时间开销,因此需要减少线程数,以便能按索引并发访问磁盘。该设置允许每次有max_thread_count + 2个线程操作磁盘,所以设置为1表示支持3个线程。

如果使用机械硬盘而不是SSD,就要在elasticsearch配置文件中加入以下配置: 
index.merge.scheduler.max_thread_count: 1

当然也可以为单个索引库设置:
curl -XPUT 'localhost:9200/my_index/_settings' -d '{ 
"index.merge.scheduler.max_thread_count" : 1
}'

为所有已创建的索引库设置:
curl -XPUT 'localhost:9200/_settings' -d '{ 
"index.merge.scheduler.max_thread_count" : 1
}'


 3 事务日志的清理

在节点挂掉时事务日志可以防止数据丢失,设计初衷是帮助在flush时原本丢失的分片恢复运行。该日志每5秒,或者在每个索引、删除、更新或批量请求(不管先后顺序)完成时,会提交到磁盘一次。

对Lucene的变更仅会在一次Lucene提交后持久化到磁盘,Lucene提交是比较重量级的操作,索引不能再每个索引或删除操作后就执行。当进程退出或硬件故障时,一次提交后或另一次提交前的变更将会丢失。

为防止这些数据丢失,每个分片有一个事务日志,或者与之关联的预写日志。任何索引或删除操作,在内置的Lucene索引处理完成后都是写到事务日志中。崩溃发生后,就可以从事务日志回放最近的事务来恢复分片。

Elasticsearch的flush操作,本质上是执行了一次Lucene提交并启动了一个新的事务日志;这些都是在后台自动完成的,目的是确保事务日志不会变得过大,否则恢复数据期间的回放操作可能需要消耗相当长的时间。这个功能同样暴露了一个API供调用,虽然很少需要手动触发。

与刷新(refresh)一个索引分片相比,真正昂贵的操作是flush其事务日志(这涉及到Lucene提交)。Elasticsearch基于许多随时可变的定时器来执行flush。通过延迟flush或者彻底关闭flush可以提升索引吞吐量。不过并没有免费的午餐,延迟flush最终实际执行时显然会消耗更长的时间。

下列可动态更新的配置控制着内存缓存刷新到磁盘的频率:

index.translog.flush_threshold_size - 一旦事务日志达到这个值,就会发生一次flush;默认值为512mb。

index.translog.flush_threshold_ops - 在多少操作后执行flush,默认无限制。

index.translog.flush_threshold_period - 触发一次flush前的等待时间,不管日志大小,默认值为30分钟。

index.translog.interval - 检查是否需要flush的时间间隔,随机在该时间到2倍之间取值,默认为5秒。

可以把index.translog.flush_threshold_size的值从默认值的512MB调大比如到1GB,这样在一次flush发生前就可以在日志中积累更大的段。通过构建更大的段,就可以减少flush的次数以及大段的合并次数。所有这些措施加起来就会减少磁盘I/O并获得更好的索引效率。

当然,这需要一定数量的可用堆内存,用于额外的缓存空间,所以调整此类配置时请注意这一点。


 4 索引缓冲区的容量规划

索引缓冲区用于存储新的索引文档,如果满了,缓冲区的文档就会写到磁盘上的一个段。节点上所有分片的缓冲区都是独立的。

下列配置项是静态的,并且必须在集群的每个数据节点上都配置:

indices.memory.index_buffer_size - 可设置为百分比或者字节数大小,默认是10%,表示总内存的10%分配给该节点,作为索引缓冲区大小,全局共享。

indices.memory.min_index_buffer_size - 如果index_buffer_size设置为百分比,那么这项配置用于指定一个绝对下限,默认是48MB。

indices.memory.max_index_buffer_size - 如果index_buffer_size设置为百分比,那么这项配置用于指定一个绝对上限,默认是无限制。

配置项indices.memory.index_buffer_size定义了可供索引操作使用的堆内存百分比(剩余堆内存将主要用于检索操作)。如果要索引很多数据,默认的10%可能会太小,有必要调大该值。


5 索引和批量操作的线程池大小

接下来试试在节点级别调大索引和批量操作的线程池大小,看看否带来性能提升。

index - 用于索引和删除操作。线程类型是固定大小的(fixed),默认大小是可用处理器核数,队列大小queue_size是200,该线程池最大为1+可用处理器核数。

bulk - 用于批量操作。线程类型是固定大小的,默认大小是可用处理器核数,队列大小是50,线程池最大为1+可用处理器核数。

单个分片与独立的Lucene是一个层次,因此同时执行索引的并发线程数是有上限的,在Lucene中默认是8,而在ES中可以通过index.index_concurrency配置项来设置。

在为该参数设置默认值时应当多想一想,特别是对于往一个索引库索引数据时,一个节点只有一个分片的情况。

由于索引/批量线程池可以保护和控制并发,所以大部分时候都可以考虑调大默认值;尤其是对于节点上没有其他分片的情况(评估是否值得),可以考虑调大该值。


关于译者


杨振涛

vivo互联网搜索引擎团队负责人,开发经理。10年数据和软件领域经验,先后从事基因测序、电商、IM及厂商互联网领域的系统架构设计和实现。专注于实时分布式系统和大数据的存储、检索和可视化,尤其是搜索引擎及深度学习在NLP方向的应用。技术翻译爱好者,TED Translator,InfoQ中文社区编辑。


 
 
未经授权,禁止转载。
 
英文原文地址:https://qbox.io/blog/maximize- ... art-2 

【杉岩招聘】 ES研发工程师招聘

求职招聘qsg0720 发表了文章 • 1 个评论 • 148 次浏览 • 2017-10-13 14:34 • 来自相关话题

岗位职责:

围绕Elasticsearch、Lucene进行优化开发,满足业务系统要求;

优化搜索引擎的性能。


任职要求:

本科以上学历,两年以上开发经验;

熟悉Solr,Elasticsearch等至少一个基于Lucene的开源搜索引擎,研究过Lucene源码优先;

具备处理海量数据的经验者优先;

遇到难题能够持续保持积极,乐观的态度,并最终解决问题;

具有良好的沟通能力和团队合作能力;

有很好的求知欲和创新能力。
 
简历请发送至:  liaoying@szsandstone.com 查看全部
岗位职责:

围绕Elasticsearch、Lucene进行优化开发,满足业务系统要求;

优化搜索引擎的性能。


任职要求:

本科以上学历,两年以上开发经验;

熟悉Solr,Elasticsearch等至少一个基于Lucene的开源搜索引擎,研究过Lucene源码优先;

具备处理海量数据的经验者优先;

遇到难题能够持续保持积极,乐观的态度,并最终解决问题;

具有良好的沟通能力和团队合作能力;

有很好的求知欲和创新能力。
 
简历请发送至:  liaoying@szsandstone.com

一例Query Cache引起的性能问题分析

Elasticsearchkennywu76 发表了文章 • 1 个评论 • 878 次浏览 • 2017-09-29 19:18 • 来自相关话题

【携程旅行网  吴晓刚】

注:本文是针对社区问题 https://elasticsearch.cn/question/2484 的分析和总结。

问题概述:
一个线上集群,执行的Query DSL都是一样的,只是参数不同。 统计数据显示98-99%的查询响应速度都很快,只需要4 -6ms, 但有1%左右的查询响应时间在100ms - 200ms。 集群硬件配置较高,使用的SSD,系统可用内存远高于索引文件大小总和,并且线上已经运行有一段时间,数据应该已经充分预热。

诊断过程及结论:
比较巧的是,问题提出者刚好是我们自家公司的开发者,因此内部联系沟通了下,为问题的快速诊断提供了不少便利。

首先用公司的监控系统排查了一遍集群所有关键数据,未发现任何可能引起查询耗时高的性能瓶颈问题。 因此初步怀疑就是有查询本身比较慢。 幸好公司有应用埋点系统和日志系统,因此很方便的拿到了应用端发出的一些慢查询样例,包括请求体以及耗时。

以下是埋点系统里记录的一个耗时150ms的查询 (隐去了敏感信息,去掉了非关键部分):POST /xxxindex/xxxdb/_search?routing=Mxxxxxxx
{
"from": 0,
"size": 100,
"query": {
"bool": {
"filter": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"should": [
{
"match_phrase": {
"ord_orders_uid": {
"query": "Mxxxxxxx",
"slop": 0,
"boost": 1
}
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
},
{
"range": {
"ord_orders_orderdate": {
"from": "1405032032",
"to": "1504014193",
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
},
{
"term": {
"ord_orders_ispackageorder": {
"value": 0,
"boost": 1
}
}
},
{
"bool": {
"must_not": [
{
"exists": {
"field": "ord_hideorder_orderid",
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
} 拿到查询后,自己手动执行了一下,0 hits,耗时1ms。  心里明白,命中了Query Cache,所以才会这么快。 
 
于是用clear api清掉Query Cache,然后再执行几次,有以下发现:
头两次查询耗时38ms左右。 这是因为没有cache,需要访问倒排索引,耗时符合预期。 之所以两次同样耗时,是因为索引有1个复制片,两次查询分别分配到主和副片上。接下来两次查询耗时150ms左右。  这里要打一个大大的问号???之后不管再查询多少次, 耗时全部是1ms,因为又开始命中Cache。
 
至此,大致明白,埋点系统里记录到的高耗时查询,是步骤2的两次操作。 什么操作耗时这么久呢? 根据经验,我判断主要是用于为range filter生成缓存,也就生成生成文档列表的bitmap,然后存放到Query Cache里。 

这个集群版本是5.1.1, 而我记得ES某个5版本开始,去掉了对term filter的cache,理由是term filter速度足够快,缓存term filter往往得不偿失。 查了官方release notes,证实这个改变正好是从5.1.1开始的(#21566),因此上面查询里的term filters被排除掉,注意力集中到了查询里唯一的一个range filter。 

单独执行了一下这个range filter,match的文档是千万数量级的。 询问用户,为何这个range filter会hit这么多文档,得知用户主要就是查询从当前时间开始至过去1年的数据,类似于做了一个now-1y  TO now这样的过滤。至此初步得出结论,因为这个range filter匹配的文档太多了,在Query Cache里为这个filter构建bitmap耗时会有些高,应该就是它带来了那额外的100多个ms。

但是还有一个待解释的问题,这种高耗时查询比例为何这么高? 再仔细想想也就明白了:因为这个集群的搜索并发量还是有点高,300 -400/s的样子,加上时间字段的精度是秒,所以,在某一秒刚开始的时候,头2次查询因为没有cache,耗时可能在38ms左右,之后会有2次查询因为需要缓存range filter,耗时会增加到150-200ms的样子,之后这1秒里剩余的查询都会命中cache,全部是几个ms, 直到下一秒开始, 周而复始。 因为每秒钟都产生2个这样需要构建缓存的查询,耗时较高,对比每秒几百次的查询量,换算成百分比就有点高了。

那么怎么解决这个问题? 对于大量含有从now-xxx TO now这样的range查询,实际上官方的文档有对应的加速技巧介绍:tune-for-search-speed.html#_search_rounded_dates 。也就是说,将查询时间的上下限round到整分钟,或者整小时,让range filter可以缓存得更久,避免出现这种过于频繁重建cache的情况。{
"range": {
"my_date": {
"gte": "now-1y/h",
"lte": "now-1y/h"
}
}
}
在原始Query里,将range filter写成上述形式,手动测试证实可行,range filter有效期延长到1小时,从而每个小时里,只需要为range filter重建2次Cache,至此问题解决。
 
 
总结:
Cache并非建得越多越好,因为Cache的生成和Evict会带来额外的开销。特别是结果集非常大的filter,缓存的代价相对查询本身可能非常高。ES 5.1.1开始取消了Terms filter Cache,因为Terms filter执行非常快,取消缓存多数情况下反而可以提高性能。大量用到Now-xxxd To Now这样的Range filter时,可以借助round date技巧,提高Cache的有效期,减轻频繁重建Cache带来的性能问题。 查看全部
【携程旅行网  吴晓刚】

注:本文是针对社区问题 https://elasticsearch.cn/question/2484 的分析和总结。

问题概述:
一个线上集群,执行的Query DSL都是一样的,只是参数不同。 统计数据显示98-99%的查询响应速度都很快,只需要4 -6ms, 但有1%左右的查询响应时间在100ms - 200ms。 集群硬件配置较高,使用的SSD,系统可用内存远高于索引文件大小总和,并且线上已经运行有一段时间,数据应该已经充分预热。

诊断过程及结论:
比较巧的是,问题提出者刚好是我们自家公司的开发者,因此内部联系沟通了下,为问题的快速诊断提供了不少便利。

首先用公司的监控系统排查了一遍集群所有关键数据,未发现任何可能引起查询耗时高的性能瓶颈问题。 因此初步怀疑就是有查询本身比较慢。 幸好公司有应用埋点系统和日志系统,因此很方便的拿到了应用端发出的一些慢查询样例,包括请求体以及耗时。

以下是埋点系统里记录的一个耗时150ms的查询 (隐去了敏感信息,去掉了非关键部分):
POST /xxxindex/xxxdb/_search?routing=Mxxxxxxx
{
"from": 0,
"size": 100,
"query": {
"bool": {
"filter": [
{
"bool": {
"must": [
{
"bool": {
"must": [
{
"bool": {
"should": [
{
"match_phrase": {
"ord_orders_uid": {
"query": "Mxxxxxxx",
"slop": 0,
"boost": 1
}
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
},
{
"range": {
"ord_orders_orderdate": {
"from": "1405032032",
"to": "1504014193",
"include_lower": true,
"include_upper": true,
"boost": 1
}
}
},
{
"term": {
"ord_orders_ispackageorder": {
"value": 0,
"boost": 1
}
}
},
{
"bool": {
"must_not": [
{
"exists": {
"field": "ord_hideorder_orderid",
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
],
"disable_coord": false,
"adjust_pure_negative": true,
"boost": 1
}
}
}
拿到查询后,自己手动执行了一下,0 hits,耗时1ms。  心里明白,命中了Query Cache,所以才会这么快。 
 
于是用clear api清掉Query Cache,然后再执行几次,有以下发现:
  1. 头两次查询耗时38ms左右。 这是因为没有cache,需要访问倒排索引,耗时符合预期。 之所以两次同样耗时,是因为索引有1个复制片,两次查询分别分配到主和副片上。
  2. 接下来两次查询耗时150ms左右。  这里要打一个大大的问号???
  3. 之后不管再查询多少次, 耗时全部是1ms,因为又开始命中Cache。

 
至此,大致明白,埋点系统里记录到的高耗时查询,是步骤2的两次操作。 什么操作耗时这么久呢? 根据经验,我判断主要是用于为range filter生成缓存,也就生成生成文档列表的bitmap,然后存放到Query Cache里。 

这个集群版本是5.1.1, 而我记得ES某个5版本开始,去掉了对term filter的cache,理由是term filter速度足够快,缓存term filter往往得不偿失。 查了官方release notes,证实这个改变正好是从5.1.1开始的(#21566),因此上面查询里的term filters被排除掉,注意力集中到了查询里唯一的一个range filter。 

单独执行了一下这个range filter,match的文档是千万数量级的。 询问用户,为何这个range filter会hit这么多文档,得知用户主要就是查询从当前时间开始至过去1年的数据,类似于做了一个now-1y  TO now这样的过滤。至此初步得出结论,因为这个range filter匹配的文档太多了,在Query Cache里为这个filter构建bitmap耗时会有些高,应该就是它带来了那额外的100多个ms。

但是还有一个待解释的问题,这种高耗时查询比例为何这么高? 再仔细想想也就明白了:因为这个集群的搜索并发量还是有点高,300 -400/s的样子,加上时间字段的精度是秒,所以,在某一秒刚开始的时候,头2次查询因为没有cache,耗时可能在38ms左右,之后会有2次查询因为需要缓存range filter,耗时会增加到150-200ms的样子,之后这1秒里剩余的查询都会命中cache,全部是几个ms, 直到下一秒开始, 周而复始。 因为每秒钟都产生2个这样需要构建缓存的查询,耗时较高,对比每秒几百次的查询量,换算成百分比就有点高了。

那么怎么解决这个问题? 对于大量含有从now-xxx TO now这样的range查询,实际上官方的文档有对应的加速技巧介绍:tune-for-search-speed.html#_search_rounded_dates 。也就是说,将查询时间的上下限round到整分钟,或者整小时,让range filter可以缓存得更久,避免出现这种过于频繁重建cache的情况。
{
"range": {
"my_date": {
"gte": "now-1y/h",
"lte": "now-1y/h"
}
}
}

在原始Query里,将range filter写成上述形式,手动测试证实可行,range filter有效期延长到1小时,从而每个小时里,只需要为range filter重建2次Cache,至此问题解决。
 
 
总结:
  1. Cache并非建得越多越好,因为Cache的生成和Evict会带来额外的开销。特别是结果集非常大的filter,缓存的代价相对查询本身可能非常高。
  2. ES 5.1.1开始取消了Terms filter Cache,因为Terms filter执行非常快,取消缓存多数情况下反而可以提高性能。
  3. 大量用到Now-xxxd To Now这样的Range filter时,可以借助round date技巧,提高Cache的有效期,减轻频繁重建Cache带来的性能问题。

【摩拜招聘】ES高级工程师

求职招聘eddie 发表了文章 • 0 个评论 • 284 次浏览 • 2017-09-21 18:52 • 来自相关话题

【摩拜-北京】 ES高级工程师
工作职责:
开发、维护ES,支持各种场景需求
开发、维护fluentd/flume/kafka等大数据产品
业务推动,解决大数据、高并发下的产品需求
跟进研究业界前沿技术,推动产品技术升级

职位要求:
1. 编程能力扎实,熟悉Java/C++/go中的一种,具有良好的数据结构、算法、操作系统等计算机基本知识;
2. 熟悉ElasticSearch/Lucene开源系统,有实际开发经验者优先;
3. 具有敏捷开发、完整产品生命周期开发者优先;
4. 学习能力强,善于独立思考,思维活跃,对技术有强烈激情;

欢迎投递简历:zhengchangshuai@mobike.com
薪资20K~50K
公司属于高速成长的独角兽,非常国际化的一家公司,具体感兴趣的请发简历到邮箱 查看全部
【摩拜-北京】 ES高级工程师
工作职责:
开发、维护ES,支持各种场景需求
开发、维护fluentd/flume/kafka等大数据产品
业务推动,解决大数据、高并发下的产品需求
跟进研究业界前沿技术,推动产品技术升级

职位要求:
1. 编程能力扎实,熟悉Java/C++/go中的一种,具有良好的数据结构、算法、操作系统等计算机基本知识;
2. 熟悉ElasticSearch/Lucene开源系统,有实际开发经验者优先;
3. 具有敏捷开发、完整产品生命周期开发者优先;
4. 学习能力强,善于独立思考,思维活跃,对技术有强烈激情;

欢迎投递简历:zhengchangshuai@mobike.com
薪资20K~50K
公司属于高速成长的独角兽,非常国际化的一家公司,具体感兴趣的请发简历到邮箱

nginx和kibana/es集成

Elasticsearch2616770lin 发表了文章 • 0 个评论 • 239 次浏览 • 2017-09-20 15:33 • 来自相关话题

利用elk搞了一个日志平台,随着日志越来越多,使用的人反应kibana上查询比较慢。kibana虽然有日志,但记录的信息不全,无法分析到底是什么样的查询比较慢。因此考虑在kibana和elk之间加一个nginx。主要作用有两个:
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上下载 查看全部
利用elk搞了一个日志平台,随着日志越来越多,使用的人反应kibana上查询比较慢。kibana虽然有日志,但记录的信息不全,无法分析到底是什么样的查询比较慢。因此考虑在kibana和elk之间加一个nginx。主要作用有两个:
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大文件检索性能提升20倍实践(干货)

Elasticsearchlaoyang360 发表了文章 • 0 个评论 • 333 次浏览 • 2017-09-19 08:06 • 来自相关话题

http://mp.weixin.qq.com/s/qOYg4wOK-ShIPYEHXcQK0Q
Elasticsearch大文件检索性能提升20倍实践(干货)

感谢群内各位大神的帮助!现将遇到问题、问题排查、问题定位、优化处理分享给大家。
欢迎拍砖!
http://mp.weixin.qq.com/s/qOYg4wOK-ShIPYEHXcQK0Q
Elasticsearch大文件检索性能提升20倍实践(干货)

感谢群内各位大神的帮助!现将遇到问题、问题排查、问题定位、优化处理分享给大家。
欢迎拍砖!

ES中可否控制字段输出的长度,只返回前300个字节的内容?

Elasticsearchlaoyang360 发表了文章 • 3 个评论 • 223 次浏览 • 2017-09-15 11:56 • 来自相关话题

举例:content字段是一篇正文,很长。我这边只需要前300个字节。
我可以通过_source控制输出content,
有没有办法控制content,只返回前300个字节的内容。

返回完再裁剪,我知道通过程序处理。
想知道有没有参数控制,直接返回给定长度的串内容? 查看全部

举例:content字段是一篇正文,很长。我这边只需要前300个字节。
我可以通过_source控制输出content,
有没有办法控制content,只返回前300个字节的内容。

返回完再裁剪,我知道通过程序处理。
想知道有没有参数控制,直接返回给定长度的串内容?

Elastic日报 第48期 (2017-09-15)

Elastic日报laoyang360 发表了文章 • 0 个评论 • 262 次浏览 • 2017-09-15 06:37 • 来自相关话题

1.基于时间轴的可视化方案选型:kibana or grafana?
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 
  查看全部
1.基于时间轴的可视化方案选型:kibana or grafana?
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