正文
- 命名规范
索引命名格式为index_name-yyyy.mm.dd或者index_name-yy.mm，不得使用其它随意的命名格式。
-
一个索引不得使用多个type(6.x已经废除多type支持)。
-
查询尽量定位到具体的索引，而不是使用通配符*查询所有打开的索引。
-
业务开发中，我们有时候需要返回分页查询数据，建议使用from+size分页实现。
-
如果需要返回全量数据，建议使用scroll api实现。
-
避免使用大文件
索引大文档将使用数倍于原始文档大小的内存，全文搜索和高亮显示也变得更占据内存、更耗时， 因为它们的成本直接取决于原始文档的大小。 所以需要将大的索引适当根据一定的维度拆分成一些小的索引。
- 避免文档的稀疏性
Lucene背后的数据结构，也是Elasticsearch依赖的索引和存储数据，最适合密集数据。 应该避免将具有完全不同结构的文档放入同一索引中以避免稀疏性。 将这些文档放入不同的索引通常会更好，您还可以考虑为这些较小的索引提供较少的分片，因为它们总体上包含的文档较少。
- 规范化文档结构
所有文档对同一数据具有相同的字段名称。如果索引中的所有文档都有一个时间戳字段，但有些文档称之为timestamp， 而其他文档称之为creation_date，这些字段应尽量做到统一。
-
程序中应避免使用聚合操作
-
平时使用kibana查询，要错开业务高峰，同时应避免聚合操作。如一定需要聚合，需要在22:00执行类似的操作。
-
插入应尽可能使用bulk提交方式。
每条数据经过一次完整的http post请求和Elasticsearch indexing是一种极大的性能浪费， 为此Elasticsearch设计了批量提交的方式bulk。 同时需要确保一次bulk数据不超过http.max_content_length大小。
- 未完待续