索引buffer大小调整
如果您的节点仅执行大量的索引任务，请确保index．memory．index＿buffer＿size足够大，以使每个分片在进行大量的索引时最多提供512 MB索引缓冲区（此后加大，索引性能通常不会提高）。Elasticsearch接受该设置（占Java堆的百分比或绝对字节大小），并将其用作所有活动分片上的共享缓冲区。非常活跃的分片自然会比执行轻量级索引的分片更多地使用此缓冲区。
默认值为10％，这通常足够了：例如，如果给JVM 10GB的内存，它将为索引缓冲区提供1GB的空间，这足以容纳两个进行大量索引的分片。
indexing buffer在为doc建立索引时使用，当缓冲满时会刷入磁盘，生成一个新的segment，这是除refresh＿interval刷新索引外，另一个生成新segment的机会。每个shard有自己的indexing buffer，下面的这个buffer大小的配置需要除以这个节点上所有shard的数量：indices．memory．index＿buffer＿size默认为整个堆空间的10％。indices．memory．min＿index＿buffer＿size默认为48MB。indices．memory．max＿index＿buffer＿size默认为无限制。在执行大量的索引操作时，indices．memory．index＿buffer＿size的默认设置可能不够，这和可用堆内存、单节点上的shard数量相关，可以考虑适当增大该值。
使用跨集群复制来防止搜索窃取索引写入操作时的资源
在单个集群中，索引和搜索可竞争资源。通过设置两个集群，配置跨集群复制以将数据从一个集群复制到另一个集群，并将所有搜索路由到具有 follower 索引的集群，搜索活动将不再从托管该集群的 leader 索引中窃取资源。
磁盘优化，见后续
搜索优化
为文件系统cache预留足够内存
Elasticsearch严重依赖于文件系统缓存，以加快搜索速度。通常，您应确保至少有一半的可用内存分配给文件系统缓存，以便Elasticsearch可以将索引的热点数据保留在物理内存中。
使用更快的硬件
写入性能对CPU的性能更敏感，而搜索性能在一般情况下更多的是在于I／O能力，使用SSD会比旋转类存储介质好得多。始终使用本地存储，应避免使用NFS或SMB等远程文件系统。还请注意虚拟存储，例如Amazon的Elastic Block Storage。虚拟存储在Elasticsearch上可以很好地工作，并且很有吸引力，因为它安装起来如此之快且简单，但是与专用本地存储相比，它在本质上在持续运行方面还很慢。如果在EBS上建立索引，请确保使用预配置的IOPS，否则操作可能会很快受到限制。如果搜索类型属于计算比较多，则可以考虑使用更快的CPU。
文档模型
为了让搜索时的成本更低，文档应该合理建模。特别是应该避免join操作，嵌套（nested）会使查询慢几倍，父子（parent－child）关系可能使查询慢数百倍，因此，如果可以通过非规范化（denormalizing）文档来回答相同的问题，则可以显著地提高搜索速度。
预索引数据
还可以针对某些查询的模式来优化数据的索引方式。例如，如果所有文档都有一个 price字段，并且大多数查询在一个固定的范围上运行range聚合，那么可以通过将范围“pre－indexing”到索引中并使用terms聚合来加快聚合速度。
curl
－X PUT ＂localhost：9200／index？pretty＂ －H ＇Content－Type：
application／json＇ －d＇｛＂mappings＂： ｛＂properties＂： ｛＂price＿range＂：
｛＂type＂： ＂keyword＂ ｝ ｝ ｝｝＇curl －X PUT
＂localhost：9200／index／＿doc／1？pretty＂ －H ＇Content－Type： application／json＇
－d＇｛＂designation＂： ＂spoon＂，＂price＂： 13，＂price＿range＂： ＂10－100＂｝＇
curl
－X GET ＂localhost：9200／index／＿search？pretty＂ －H ＇Content－Type：
application／json＇ －d＇｛＂aggs＂： ｛＂price＿ranges＂： ｛＂terms＂： ｛＂field＂：
＂price＿range＂ ｝ ｝ ｝｝＇
字段映射
有些字段的内容是数值，但并不意味着其总是应该被映射为数值类型，例如，一些标识符，将它们映射为keyword可能会比integer或long更好。
首页
