1.使用块查询
块查询一般来说比单文档查询表现出更好的性能。为了获取快查询最佳新能，你可以在单节点地单分片上运行一个基准，第一次100个文档，第二次200个文档，然后400个，以此类推。每次基准运行的数量都是两倍于前一次的数量。当索引速度达到峰值的时候你就知道你的数据索引最佳的块文档数量。如果峰值存在于两个数量上，最好还是以最少的数量去索引。块查询数量越大也就意味着在进行同步查询的时候对内存压力也就越大。建议大家每次发送请求时不要超过几十兆尽管有时更大的请求表现地更好。
2.使用多线程发送数据到es中
使用单个线程不可能将es集群的索引性能最大化。为了充分利用es集群的资源，你应该使用多线程或进程发送数据。除了最大化集群的资源使用，这也会帮助减少非同步的成本。
注意TOO_MANY_REQUESTS(429)返回码（在java客户端中报EsRejectedExecutionException错误），这是告诉你es目前无法跟上你的索引速率。当这种情况发生时，你应该在下次发送请求之前先暂停下。理想情况下，它会自动恢复。
跟确定最佳bulk请求数量类似，只有通过测试才能知道最佳的调用者数量是多少。这可以通过增加调用者数量来测试并在I/O或CPU饱和的情况下得到结果
3.提高刷新间隔
默认情况下，index.refresh_interval是1s，意味着es会每秒创建一个新的分片，但是你可以通过增加这个值（例如30s）来增大在每个刷新间隔中创建更多的分片并能够减少未来合并的压力
4.在进行初始加载的时候禁用索引刷新和索引复制
如果你要一次性进行大量的数据加载操作，你应该通过设置index.refresh_interval为-1并设置index.number_of_replicas为0.这会让你的索引暂时处于危险之中，因为丢失任何分片都会使数据丢失，但是同时也会导致索引更快因为文档只会被索引一次。一旦初始化加载结束，应该把上面两个参数设置为原来的值
5.禁用交换机制
确保操作系统不会因为禁用交换机制来交换java进程
6.给文件系统缓存留有足够的内存空间
文件系统的缓存会被使用到因为需要缓冲I/O操作。你应当确保运行es的机器还有一般的内存留给文件系统用作缓存
7.使用自动生成的ids
当索引一个有具体id的文档时，es需要检查同一分片中是否存在匹配到该id的文档，这会花费很多时间并且在id越大的时候成本越高。通过使用自动生成的id，es会调过这些检查，这将会使得索引变得更加快速
8.使用更快的硬件
如果索引速度被I/O制约，你需要提供为文件系统缓存提供更多的内存或者升级更快的硬件设备了。一般固态比机械硬盘性能更好。始终使用本地文件系统，远程文件系统像NFS以及SMB都应该避免。对例如亚马逊的EBS(elastic block storage)也要留意，es在虚拟存储上表现更好，由于更快以及易于安装使得它变得越来越受欢迎。但是不幸的是相比于本地存储虚拟存储还是有一些差距。如果你要使用EBS请注意要使用提供的IOPS否则会被限流
通过配置RAID为一个空数组，可以让索引分配在多个SSD上，但是要注意它会增加故障风向因为任意一个SSD故障都会导致索引损坏。然而这通常是一个正确的做法：优化单个分片以获得最大性能，并且在不同的节点上添加副本分片以提高可用性。你也可以使用snapshot和restore备份索引来获得进一步的保险
9.索引缓冲区大小
如果你的节点只做高负荷的索引，确保indices.memory.index_buffer_size大到足以为每个分片提供最多512MB的索引缓冲区进行大量索引(超过512MB索引性能也不会得到显著的提升)。es会采用这个配置(java堆的百分比或者绝对值)，然后使用它在所有活跃的分片中作为公用缓冲区。非常活跃的分片自然会使用更多的缓冲区空间而那些轻量级查询的分片用得更少。
默认10%足够了，例如：如果你给JVM10G的内存，它会给索引缓存区1G，这将对于两个高负荷分片提供足够的内存空间。
10.禁用_field_names
_field_names字段会带来额外的索引开销，所以如果你不用运行esists查询就可以禁用它
