调整 Elasticsearch 索引副本数是优化存储成本和读取性能的关键手段。对于热数据或高并发读取场景，适当增加副本数可以利用副本分担查询负载，提升读取吞吐量和可用性；而对于冷数据或存储敏感场景，减少副本数甚至设置为零能显著节省磁盘空间。建议结合索引生命周期管理（ILM），在新数据写入时保持较高副本数以保证性能和容灾，随着数据变老逐渐减少副本数。同时需监控磁盘水印阈值，避免因磁盘过满导致分片分配停止。通过动态调整副本策略，可在存储成本与查询性能之间找到最佳平衡点，确保集群稳定高效运行。

如何优化 Elasticsearch 的磁盘空间和使用

如果磁盘空间不足，Elasticsearch 将会停止分配分片到节点。这最终会导致无法向集群写入数据，甚至有丢失应用数据的风险。相反，如果磁盘空间过多，则意味着您为不必要的资源付出了额外的费用。在 Elasticsearch 集群中，有多种“水印”阈值用于帮助您监控可用磁盘空间。当某个节点的磁盘逐渐填满时，首先会达到“低磁盘水印”阈值。接着，会达到“高磁盘水印阈值”,最后是“磁盘洪水阶段”。一旦超过这个阈值，集群将会阻止在该节点上拥有分片 (无论是主分片还是副本分片) 的所有索引进行写操作。尽管如此，读取 (搜索) 操作仍然是可行的。如何预防和处理磁盘过满 (过度使用) 的情况 当 Elasticsearch 磁盘过满时，可以采取以下方法进行处理：删除旧数据：通常情况下，数据不应被无限期保存。为防止磁盘过满，您应确保当数据达到一定年龄时，能够可靠地归档和删除。可以使用 ILM 来实现这一点。增加存储容量：如果无法删除数据，可以通过增加数据节点或提升磁盘容量来保留所有数据，而不影响性能。需要增加存储容量时，您应考虑是否仅仅需要增加存储容量，还是同时需要按比例增加 RAM 和 CPU 资源 如何为 Elasticsearch 集群增加存储容量 增加数据节点数量：请确保新节点的大小与现有节点相同，并且使用相同的 Elasticsearch 版本。增加现有节点的大小：在云环境中，通常可以轻松增加现有节点的磁盘大小和 RAM/CPU。仅增加磁盘大小：在云环境中，通常可以较容易地增加磁盘大小。快照与恢复：如果愿意在需要时通过自动化流程从备份中检索旧数据，可以对旧索引进行快照，删除它们，并在需要时从快照中临时恢复数据。减少每个分片的副本：另一种减少数据的方法是减少每个分片的副本数量。为了高可用性，通常希望每个分片至少有一个副本，但当数据变老时，可能可以不使用副本。这通常适用于数据是持久的，或者您有备份可在需要时恢复。创建警报：为防止磁盘将来再次填满，您应根据磁盘使用情况创建警报，以便在磁盘开始填满时通知您。

【干货】Elasticsearch 的索引性能优化 (3)

elasticsearch 索引性能优化的关键因素有哪些？在 elasticsearch 中，如何调整分片数量来优化索引性能？关注 vivo 互联网技术，获取更多技术干货 作者:adam vanderbush 译者：小辉 本文是 elasticsearch 索引优化系列的第三篇，此前已发布第一篇和 第二篇 .本系列教程主要目的是通过对 elasticsearch 配置进行调优来提升索引性能，并降低监控和管理压力。本文翻译自 qbox 官方博客，版权归原作者 adam vanderbush 所有。elasticsearch 推荐使用分片和备份机制以扩展并增加索引的高可用性。副本数稍微多一点有好处，但分片数过多则会影响性能。通常很难判断是否包含了过多的分片，因为这取决于分片大小和如何被使用。如果有大量的分片，但是使用频次很低可能性能并不会太差，相反即使只有两个分片但是如果使用非常频繁则性能会很糟糕。监控节点以确保有多余的空闲资源来处理突发状况。横向扩展应该做到以下部分。首先应该为下个阶段的扩展预留足够的资源。一旦进入下一阶段，就有足够的时间去考虑需要做出哪些改变以达到之后的阶段。也可以从发送到 elasticsearch 的请求中获取很多优化的方式，比如需要为每个文档发送一个单独的请求吗？或者可以缓存多文档以便于利用 bulk api 通过单个请求对多个文档进行索引吗？我们之前主要关注索引的性能比如更新，刷新，段合并和自动限流。本文将会列举一些关于分片，副本，请求，客户端以及存储方面的策略来提高 elasticsearch 的吞吐量。1 扩展 elasticsearch 集群 elasticsearch 自带扩展特性。它无论是在个人电脑还是包含数百节点的集群上都可以运行良好，并且这种经验是可复制的。从一个小集群逐渐扩容到大集群几乎是完全自动的，并且很容易做到，从一个大集群到更大的集群可能需要一点计划和设计，但仍然是相对容易的。elasticsearch 的默认设置已经足够适用很多场景，但是如果想获得更好的性能，就需要考虑数据如何在系统中流转。它可能是时间序列数据 (比如日志

关于 ElasticSearch 性能调优几件必须知道的事

ElasticSearch 是现在技术前沿的大数据引擎，常见的组合有 ES+Logstash+Kibana 作为一套成熟的日志系统，其中 Logstash 是 ETL 工具，Kibana 是数据分析展示平台。ES 让人惊艳的是他强大的搜索相关能力和灾备策略，ES 开放了一些接口供开发者研发自己的插件，ES 结合中文分词的插件会给 ES 的搜索和分析起到很大的推动作用。ElasticSearch 是使用开源全文检索库 ApacheLucene 进行索引和搜索的，说架构必须和 Lucene 的一些东西打交道。Apache Lucene 将写入索引的所有信息组织成一种倒排索引 (Inverted Index) 的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且 Lucene 索引之中还存储了很多其他的信息，如词向量等等，每个 Lucene 都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由 Lucene 的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗 I/O 的，且与之同时会有些不再使用的信息被清理掉。在 Lucene 中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器 (Analyzer) 来执行，分析其由分词器 (Tokenizer),过滤器 (Filter) 和字符映射器 (Character Mapper) 组成，其各个功能显而易见。除此之外，Lucene 有自己的一套完整的查询语言来帮助我们进行搜索和读写。回到 ElasticSearch,ES 的架构遵循的设计理念有以下几个特征：1. 合理的默认配置：只需修改节点中的 Yaml 配置文件，就可以迅捷配置。这和 Spring4 中对配置的简化有相似的地方。2. 分布式工作模式:ES 强大的 Zen 发现机制不仅支持组广播也支持点单播，且有“知一点即知天下”之妙。3. 对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量”远离“,可以避免单点故障。且 Master 节点和 Data 节点几乎完全等价。4. 易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。5. 不对索引中的数据结构增加任何限制:ES 支持在一个索引之中存在多种数据类型。6. 准实时：搜索和版本同步，由于 ES 是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明 ES 表现优秀。分片策略 选择合适的分片数和副本数。ES 的分片分为两种，主分片 (Primary Shard) 和副本 (Replicas)。

Elasticsearch 搜索引擎性能调优看懂这一篇就够了

2.优化存储设备 在现代服务器上，相对于 CPU 和内存，磁盘是限制服务器性能的最大瓶颈，并且 Elasticsearch 是一种密集使用磁盘的应用，特别是在段合并的时候对磁盘要求较高，所以磁盘速度提升之后，集群的整体性能会大幅提高。这里对磁盘的选择提供以下几点建议。(1) 条件允许的话，强烈建议使用固态硬盘 (Solid State Disk)。SSD 相比于机械磁盘具有超高的读写速度和稳定性。(2) 使用 RAID0。RAID0 可以提升磁盘写入的速度，因为我们集群中的副本分片已经提供数据备份的功能，所以没有必要再使用镜像或者奇偶校验的 RAID。(3) 在 Elasticsearch 的服务器上挂载多块硬盘。并且在 Elasticsearch 的配置文件 elasticsearch.yml 中设置多个存储路径，例如:path.data: /path/to/data1,/path/to/data2。这样可以在多块硬盘上同时进行读写操作。(4) 不要使用类似于 NFS(Network File System) 的远程存储设备，因为这些设备的延迟对性能的影响是很大的。3.合理使用段合并 Lucene 是以段的形式存储数据的，每当有新的数据写入索引时，就会自动创建一个新的段，所以在一个索引文件中包含了多个段。随着数据量的不断增加，段的数量会越来越多，需要消耗的文件句柄数及 CPU 就越多，查询时的负担就越重。Lucene 后台会定期进行段合并，但是段合并的计算量庞大，会消耗大量的 I/O,所以 Elasticsearch 默认采用较保守的策略，如下所述。(1) 当段合并的速度落后于索引写入的速度时，为了避免出现堆积的段数量爆发，Elasticsearch 会把写索引的线程数量减少到 1,并打印出"now throttling indexing"这样的 INFO 级别的“警告”信息。

FAQ

减少副本数会对数据安全性产生什么影响？

减少副本数会降低数据的高可用性。副本主要用于容灾，如果主分片损坏且无副本，数据可能丢失。但在有外部备份或数据可重建的场景下，旧数据可减少副本以节省空间。

增加副本数是否能提升写入性能？

不能。增加副本数会增加写入开销，因为数据需要同步到所有副本。它主要提升读取性能和可用性，但会消耗更多存储和网络资源。

如何动态调整索引的副本数？

可以通过 Elasticsearch 的动态设置 API 调整。使用 PUT /_settings 接口修改 index.number_of_replicas 参数，无需重建索引即可生效，适合根据数据热度动态优化。