ElasticSearch使用规范

MySQL、Redis这类存储缓存许多开发同学多有很强的最佳实践，但对于ElasticSearch的使用经验相对模式。我个人经验是ElasticSearch非常便于开发(譬如支持dynamic mapping)但它相对脆弱：一方面是开发同学对于其重视程度不够(譬如没有自己制定mapping)、另一方面它本身的一些设计(例如聚合计算都在JVM完成)导致其相对脆弱。

为此我们提供一份关于ElasticSearch的开发规范帮助ElasticSearch使用者减少一些可能碰到的坑

一、容量规划

1. 分片(shard)容量

• 非日志型(搜索型、线上业务型)的shard容量在10~30GB(建议在10G)
• 日志型的shard容量在30~100GB(建议30G)
• 单个shard的文档个数不能超过21亿左右(Integer.MAX_VALUE - 128)

注：一个shard就是一个lucene分片，ES底层基于lucene实现。

2. 索引(index)数量

• 大索引需要拆分：增强性能，风险分散。

反例：一个10T的索引，例如按date查询、name查询

正例：index_name拆成多个index_name_${date}

正例：index_name按hash拆分index_name_{1,2,3,...100..}

. shard个数(number_of_shards)：

参考一

2. refresh频率(refresh_interval)：

ES的定位是准实时搜索引擎，该值默认是1s，表示写入后1秒后可被搜索到，所以这里的值取决于业务对实时性的要求，注意这里并不是越小越好，刷新频率高也意味着对ES的开销也大，通常业务类型在1-5s，日志型在30s-120s，如果集中导入数据可将其设置为-1，ES会自动完成数据刷新(注意完成后更改回来，否则后续会出现搜索不到数据)

（编辑：吉安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!