Elasticsearch索引建议

背景：
最近在做日志收集，用到Elasticsearch作为存储层，因为日志量比较大，一天近2T，所以每时每刻都会有大量的插入操作。又由于是给开发人员查日志使用，所以查询的量比较小。
受限于存储空间，目前仅保留7天的日志，多数为一个业务模块一个索引，按天切分索引。

• 程序上怎么使用Elasticsear索引文档更有效率[1]

  • 官方推荐使用bulk批量操作，并且使用一组线程去执行，以便达到更好的效率。使用bulk的时候，尽量不要让一次建立索引到量太小，会非常浪费资源。bulk索引1条文档可能需要23ms，但是bulk索引1000条文档可能只需要200ms。
  • bulk太快可能会收到Elasticsearch插入拒绝，这个时候可以稍微等一下再重试。尽量让一次bulk中的所有索引操作集中在几个分片中[2]。
  • 出现插入拒绝时候，检查一下bulk_queue参数。有可能不是插入太快，而是队列太小。默认队列大小200，可以根据自己的情况适当调大。我们的生产环境中，最大调过30000。
  • 索引文档时尽量使用Elasticsearch的自增id，避免索引时候Elasticsearch去检查id冲突。
  • 适当增大刷新间隔(refresh interval)。Elasticsearch默认的刷新间隔为1s，大量插入时候，可以增大至30s。

• 关于索引和类型的取舍，建立多个索引还是一个索引下多个类型

  • 如果一个模块的日志量比较小，那么按天切割会产生很多比较小的索引，进而产生很小的分片，这对Elasticsearch是一种资源浪费。所以这种情况下可以选择用type来作为日期分类。（有经验的同事还建议不使用type而直接加一个日期字段作为区分）
  • 如果一个模块的日质量合适，那么按天切割是个不错的选择，此时一个索引里面只有一种类型。
  • 如果一个模块日质量很大，甚至可以按照更细粒度的切分索引，例如按照4个小时一切分。

• 一个索引建立多少个分片，多少个副本

  • Elasticsearch默认每个索引5个分片，每个分片1个副本。在这种情况下，一个索引最少有10个分片。副本在查询的时候可以加速，但是索引文档时候会慢一点
  • 通常说来，对于可以预见的大索引，分片数最少要等于集群的节点数，这样保证每个节点有一个分片，Elasticsearch处理时候能把数据分散到各个节点。由于业务扩张，Elasticsearch集群也不总是一直不变，所以初期设置分片数时候建议是节点数的1.5~3倍。

上面说的日志量大小并没有很明确的限定，需要根据Elasticsearch部署的机器配置，Elasticsearch启动时候配置的参数来决定。通常来说，按照一个分片10G~20G是合适的，即使给Elasticsearch分配了最大的30-32G的JVM heap，最大的分片也不要超过30G[3]。

• 分片太多会有什么问题

  • 第一个问题是可能导致Elasticsearch打开文件句柄数不够，无法新建索引。整个集群的健康状态会变黄甚至变红
  • 分片太多会导致Elasticsearch要管理的mapping数据变大，引起性能下降

• Elasticsearch和Lucene怎么看待类型(Tpye)和映射(mapping)[4]

  • Elasticsearch中的类型对Lucene不可见，类型只是Elasticsearch中的概念。实现时存储在元数据(metadata)的_type字段中。type就Lucene看来和普通字段没有区别。
  • Elasticsearch中的映射对Lucene不可见，映射只是Elasticsearch中的概念，用于把我们的复杂json展开铺平，转换成Lucene接受的数据模式。
  • 同一个索引中的多种type最好具有相似的mapping，避免Lucene中大量的空闲字段，这种情况最终会导致性能问题。
  • 如果同一个索引中存在多种type，并且不同type具有相同的字段名，那么这个字段的类型和分词必须相同。

• 先了解Elasticsearch中数据类型[6]，合理安排索引中的字段

  • Elasticsearch中有多种数据类型，但受限于实现语言是Java，所以对于long类型只支持到63位有符号数，如果是C/C++系语言的uint64的值，建议都转化成字符串存储。避免小数值被存为数字，大数值是字符串
  • 对于不确定的字段最好不要设置默认值。Elasticsearch中一个索引的一个字段只能有一种数据类型，如果不确定这个字段是什么类型盲目设置默认值，可能导致后续插入时数据类型不匹配而插入失败
  • 对于json数据类型要做限制。由于Elasticsearch会把json中字段全部拉平，如果json中的字段很多或者相差很大，会造成mapping超大，引起性能下降

最后还得时刻注意用_cat来检查Elasticsearch的状态[6]

参考链接：
[1]https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html
[2]http://stackoverflow.com/questions/20683440/elasticsearch-gives-error-about-queue-size
[3]https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
[4]https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html
[5]https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html
[6]https://www.elastic.co/guide/en/elasticsearch/reference/current/cat.html