Heka 的参数配置跟Elasticsearch的参数没有关系,Heka只负责按照配置发送数据,所以索引的优化主要在 Elaticsearch端来完成。
下面是Elasticsearch的一些相关概念和知识点:
在Elasticsearch中,文档归属于一种类型(type),而这些类型存在于索引(index)中,我们可以画一些简单的对比图来类比传统关系型数据库:
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices -> Types -> Documents -> Fields
Elasticsearch集群可以包含多个索引(indices)(数据库),每一个索引可以包含多个类型(types)(表),每一个类型包含多个文档(documents)(行),然后每个文档包含多个字段(Fields)(列)。
你可能已经注意到索引(index)这个词在Elasticsearch中有着不同的含义,所以有必要在此做一下区分:
索引(名词) 如上文所述,一个索引(index)就像是传统关系数据库中的数据库,它是相关文档存储的地方,index的复数是indices 或indexes。
索引(动词) 「索引一个文档」表示把一个文档存储到索引(名词)里,以便它可以被检索或者查询。这很像SQL中的INSERT关键字,差别是,如果文档已经存在,新的文档将覆盖旧的文档。
倒排索引 传统数据库为特定列增加一个索引,例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。
参考: http://es.xiaoleilu.com/010_Intro/25_Tutorial_Indexing.html
lucene的存储结构,如下图:
lucene 在存储它的全文索引结构时,是有层次结构的,这涉及到5个层次:索引(Index);段(Segment);文档(Document);域(Field);词(Term)
参考:
http://blog.csdn.net/ghj1976/article/details/5586329
http://hushi55.github.io/2015/07/29/lucene-index-file-format/
有关segment的描述如下:
Lucene中索引总体上是这样进行,索引 现写到内存,触发一定限制条件后写入硬盘,生成一个独立的子索引-lucene中叫Segment。一般来说这些子索引需要合并成一个索引,也就是 optimize(),否则会影响检索速度,而且也可能导致open too many files。
下面内容来自: http://kibana.logstash.es/content/elasticsearch/principle/realtime.html
1、当前索引有 3 个 segment 可用。索引状态如下图:
2、新接收的数据进入内存 buffer。索引状态如下图:
3、内存 buffer 刷到磁盘,生成一个新的 segment,如下图:
4、commit 文件同步更新。索引状态如下图:
大家可能注意到了,前面一段内容,一直写的是"Lucene 索引"。这个区别在于,ES 为了完成分布式系统,对一些名词概念作了变动。索引成为了整个集群级别的命名,而在单个主机上的Lucene 索引,则被命名为分片(shard)。
这一步刷到文件系统缓存的步骤,在 ES 中,是默认设置为 1 秒间隔的,对于大多数应用来说,几乎就相当于是实时可搜索了。ES 也提供了单独的 /_refresh 接口,用户如果对 1 秒间隔还不满意的,可以主动调用该接口来保证搜索可见。
不过对于 ELK 索引日志的场景来说,恰恰相反,我们并不需要如此高的实时性,而是需要更快的写入性能。
在设置前
http://10.30.0.32:9200/nginx-2016.01.19/_settings
返回的数据没有 index.refresh_interval 的设置,这时候使用的是默认设置 1s
{
"nginx-2016.01.19": {
"settings": {
"index": {
"creation_date": "1453281866086",
"number_of_shards": "5",
"number_of_replicas": "1",
"uuid": "VcmLVa7LQOyQB3ctMJ4Z9w",
"version": {
"created": "2010199"
}
}
}
}
}
index.refresh_interval
How often to perform a refresh operation, which makes recent changes to the index visible to search. Defaults to 1s. Can be set to -1 to disable refresh.
设置,如果是导入历史数据的场合,先完全关闭掉是非常合适的。
curl -XPUT 'http://10.30.0.32:9200/nginx-2016.01.19/_settings' -d '
{
"index" : {
"refresh_interval" : -1
}
}'
再次读取参数:
http://10.30.0.32:9200/nginx-2016.01.19/_settings
{
"nginx-2016.01.19": {
"settings": {
"index": {
"creation_date": "1453281866086",
"refresh_interval": "-1",
"number_of_shards": "5",
"number_of_replicas": "1",
"uuid": "VcmLVa7LQOyQB3ctMJ4Z9w",
"version": {
"created": "2010199"
}
}
}
}
}
强制更新
http://10.30.0.32:9200/nginx-2016.01.19/_refresh
修复成默认值
curl -XPUT ' http://10.30.0.32:9200/nginx-2016.01.19/_settings' -d '参考: https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-update-settings.html
优化前,同样的服务器配置, 一天可以导入 80多万行日志,优化完成后, 一天导入了600万行日志, 增加了7-8倍。
参考:
Elasticsearch Refresh Interval vs Indexing Performance
http://blog.sematext.com/2013/07/08/elasticsearch-refresh-interval-vs-indexing-performance/
http://stackoverflow.com/questions/17450084/setting-refresh-interval-in-elasticsearch-to-improve-io-wait
https://groups.google.com/forum/#!msg/elasticsearch/APbMvt9WFK4/vtl80jXo2xoJ