1. 使用自动生成的id（auto-generated ids）
索引具有显式id的文档时，Elasticsearch需要检查具有相同id的文档是否已经存在于相同的分片中，这是昂贵的操作，并且随着索引增长而变得更加昂贵。 通过使用自动生成的ID，Elasticsearch可以跳过这个检查，这使索引更快。
2. 加大 indexing buffer size
如果你的节点只做大量的索引，确保index.memory.index_buffer_size足够大，每个分区最多可以提供512 MB的索引缓冲区，而且索引的性能通常不会提高。 Elasticsearch采用该设置（java堆的一个百分比或绝对字节大小），并将其用作所有活动分片的共享缓冲区。 非常活跃的碎片自然会使用这个缓冲区，而不是执行轻量级索引的碎片。
默认值是10％，通常很多：例如，如果你给JVM 10GB的内存，它会给索引缓冲区1GB，这足以承载两个索引很重的分片。
3. 避免 join操作。具体是指
nested 会使得查询慢 好几倍；
parent-child关系 更是使得查询慢几百倍；
如果 无需join 能解决问题，则查询速度会快很多。
4. Mappings（能用 keyword 最好了）
数字类型的数据，并不意味着一定非得使用numeric类型的字段。
一般来说，存储标识符的 字段（书号ISBN、或来自数据库的 标识一条记录的 数字），使用keyword更好（integer，long 不好哦）
5. 预热 filesystem cache
机器重启时，filesystem cache就被清空。OS将index的热点区域（hot regions of the index）加载进filesystem cache是需要花费一段时间的。
设置 index.store.preload 可以告知OS 这些文件需要提早加载进入内存。
6. 不要 返回大的结果集
es 设计来作为搜索引擎，它非常擅长返回匹配 query 的 top n 文档。但，如“返回满足某个query的 所有文档”等数据库领域的工作，并不是 es 最擅长的领域。如果你确实需要返回所有文档，你可以使用 Scroll API。
7. 避免 大的 doc。即，单个 doc 小了 会更好
考虑到http.max_context_length默认==100MB，es拒绝索引操作100MB的文档。当然你可以提高这个限制，但，Lucene本身也有限制的，其为2GB
即使不考虑上面的限制，大的doc 会给 network/memory/disk带来更大的压力；
a.任何搜索请求，都需要获取 _id 字段，由于filesystem cache工作方式。即使它不请求 _source字段，获取大doc _id 字段消耗更大；
b.索引大doc时消耗内存会是 doc本身大小 的好几倍；
c.大doc的 proximity search, highlighting 也更加昂贵。它们的消耗直接取决于doc本身的大小；
8. 避免 稀疏
a.不相关数据 不要 放入同一个索引
b.一般化文档结构（Normalize document structures）
c.避免类型（Avoid mapping type）
同一个index，最好就一个mapping type。
在同一个index下面，使用不同的mapping type来存储数据，听起来不错，但，其实不好。given that(考虑到)每一个mapping type会把数据存入 同一个index，因此，多个不同mapping type，各个的field又互不相同，这同样带来了稀疏性 问题。
d.在 稀疏 字段上，禁用 norms & doc_values 属性。
