自动生成id
为具有显式ID的文档建立索引时，Elasticsearch需要检查具有相同ID的文档是否已存在于同一分片中，这是一项昂贵的操作，并且随着索引的增长而变得更加昂贵。通过使用自动生成的ID，Elasticsearch可以跳过此检查，这使索引编制更快。
优化节点间的任务分布，将任务尽量均匀地发到各节点。
为了节点间的任务尽量均衡，数据写入客户端应该把bulk请求轮询发送到各个节点。当使用Java API或REST API的bulk接口发送数据时，客户端将会轮询发送到集群节点，节点列表取决于：· 使用Java API时，当设置client．transport．sniff为true（默认为false）时，列表为所有数据节点，否则节点列表为构建客户端对象时传入的节点列表。· 使用REST API时，列表为构建对象时添加进去的节点。Java API的TransportClient和REST API的RestClient都是线程安全的，如果写入程序自己创建线程池控制并发，则应该使用同一个Client对象。在此建议使用REST API，Java API会在未来的版本中废弃，REST API有良好的版本兼容性好。理论上，Java API在序列化上有性能优势，但是只有在吞吐量非常大时才值得考虑序列化的开销带来的影响，通常搜索并不是高吞吐量的业务。
要观察bulk请求在不同节点间的均衡性，可以通过cat接口观察bulk线程池和队列情况：＿cat／thread＿pool
优化Lucene层建立索引的过程，目的是降低CPU占用率及I／O，例如，禁用＿all字段。
初始加载禁用副本
如果您有大量数据想要一次全部加载到Elasticsearch中，则将index．number＿of＿replicas设置为0可能有益于扩大索引编制。没有副本意味着丢失单个节点可能会导致数据丢失，因此将数据保存在其他位置很重要，以便在出现问题时可以重试此初始负载。初始加载完成后，可以将index．number＿of＿replicas设置回其原始值。
如果在索引设置中配置了index．refresh＿interval，则在初始加载期间将其取消设置，并在初始加载完成后将其设置回其原始值可能会有所帮助。
多线程请求
发送批量请求的单个线程不太可能最大化使用Elasticsearch集群的索引容量。为了使用集群的所有资源，您应该从多个线程或进程发送数据。除了更好地利用集群的资源之外，这还有助于降低每个fsync的成本。
确保注意TOO＿MANY＿REQUESTS（429）响应代码（Java客户端使用EsRejectedExecutionException），这是Elasticsearch告诉您它无法跟上当前索引速率的方式。发生这种情况时，您应该暂停索引，然后再重试，最好使用随机指数避免。
与确定批量请求的大小类似，只有测试才能确定最佳数。可以通过逐渐增加工作程序数量直到集群上的I ／ O或CPU达到饱和来测试这一点。
首页
