网站开发模块就业前景,呼和浩特网站seo优化方案,iis7搭建aspx网站,跨境电商开店要多少钱Easticsearch性能优化之索引优化 一、合理的索引设计二、合理的分片和副本三、合理的索引设置 对于性能优化#xff0c;Elasticsearch#xff08;以下简称ES#xff09;的索引优化是提高性能的关键因素之一。合理的设计索引#xff0c;合理的分片和副本以及合理的缓存设置等… Easticsearch性能优化之索引优化 一、合理的索引设计二、合理的分片和副本三、合理的索引设置 对于性能优化Elasticsearch以下简称ES的索引优化是提高性能的关键因素之一。合理的设计索引合理的分片和副本以及合理的缓存设置等都有利于提升ES的索引性能和查询效率。
一、合理的索引设计
合理的索引设计是确保 ES 高效运行的关键因素之一。以下是一些设计ES索引时应考虑的最佳实践
1. 理解数据和查询需求 数据特性了解数据的类型文本、数字、地理位置等、大小和复杂性。 查询模式明确你的查询需求包括查询的频率、类型全文搜索、精确匹配、范围查询等以及期望的响应时间。 2. 索引结构优化 合理使用字段类型根据数据的性质选择合适的字段类型如text、keyword、date等。 控制索引映射通过显式定义索引映射来控制字段的索引方式和格式化。 避免过度索引不要索引那些永远不会被搜索的字段可以在映射中将其设置为false。 3. 利用别名和索引模板 索引别名使用索引别名可以更灵活地管理索引如无缝切换索引或实现索引的滚动升级。 索引模板利用索引模板可以自动应用预定义的设置和映射到新创建的索引简化管理工作。 4. 考虑数据生命周期管理 使用ILMIndex Lifecycle ManagementElasticsearch提供了索引生命周期管理功能允许你基于索引的大小或年龄自动执行优化、滚动升级和删除操作。 二、合理的分片和副本
合理设置Elasticsearch中的分片和副本是确保高效性能和数据可靠性的关键。它是一个需要根据具体情况不断调整和优化的过程没有一成不变的规则。理解自己的数据特性和业务需求做出选择这里提供一些指导原则和建议
1. 分片 (Shards) 分片是Elasticsearch进行数据分布和并行处理的基本单位一个索引可以被分成多个分片。合理设置分片数量对于优化存储、查询性能和扩展性至关重要。 分片大小理想的分片大小通常在几GB到几十GB之间。太大的分片会增加恢复时间和降低某些操作的速度而太小的分片则可能浪费资源并增加集群的管理开销这会严重影响搜索性能。 默认分片数Elasticsearch 7.x版本以后默认创建的索引有1个主分片。主分片的设置需要结合集群节点规模、全部数据量和日增数据等维度综合考量才给出的值一般建议设置为数据节点的1~3倍。 预估数据量在确定分片数量时考虑预期的数据增长。可以通过预估总数据量除以理想的分片大小来计算理想的分片数量。 扩展性分片一旦被创建其数量就不能更改除非重新索引。如果预计数据量会显著增长应该规划额外的分片以便未来扩展。 2. 副本 (Replicas) 副本是分片的拷贝用于提供数据冗余、提高查询吞吐量和提升系统的容错能力。 副本数量至少设置一个副本是一个好习惯这样即使失去一个节点也不会丢失数据。更多的副本可以提高读取性能但会占用更多的硬盘空间和资源。Elasticsearch 7.x版本以后默认创建的索引有1个副分片。对于一般的非高可用场景一个副本基本足够。 读写比例如果读请求远多于写请求增加副本数量可以提高读取性能因为查询可以在多个副本上并行执行。 资源和性能权衡增加副本会提高查询性能但同时也会增加索引和更新操作的开销因为所有的写操作都必须在所有副本上执行。增加副本前要考虑磁盘存储空间的容量上限和磁盘警戒水位线其本质还是以空间换时间。 动态调整副本数量可以根据需要动态调整不会影响现有数据的完整性或可用性。 3. 实践建议 使用Index Templates通过索引模板自动应用分片和副本的设置以确保新索引遵循最佳实践。 监控和调整利用Elasticsearch提供的监控工具如Elasticsearch自身的监控API和Kibana定期检查分片和副本的状态并根据需要进行调整。 测试和评估在生产环境部署前通过测试来评估不同分片和副本配置下的性能表现找到最适合自己数据和查询特性的设置。 三、合理的索引设置
1. 合理调整堆内存的索引缓冲区大小 堆内存中索引缓冲区用于存储新索引的文档。填满后缓冲区中的文档将最终写入磁盘上的某个段。索引缓冲的设置可以控制多少内存分配给索引进程。这是一个全局配置会应用于一个节点上所有不同的分片上。 index_buffer_size的默认值为堆内存的10%如下 indices.memory.index_buffer_size: 10% 比如给JVM提供31G的内存它将为索引缓冲区提供3.1G的内存一般情况下足以容纳大量的数据和写入操作。如果数据量着实非常大则建议调大该默认值比如调整为对内存的20%。但是必须在集群中的每个数据节点上进行配置。缓冲区越大意味着能缓存的数据量越大相同时间内写入磁盘的频次低、磁盘IO小间接提升写入性能。 indices.memory.min_index_buffer_size: 48mb 如果设置的是百分比还可以设置 min_index_buffer_size 默认 48mb和 max_index_buffer_size默认没有上限。
2. 合理的调整刷新频率 为了提高索引性能Elasticsearch 在写入数据的时候采用延迟写入的策略即数据先写到内存中当超过默认1秒index.refresh_interval会进行一次写入操作就是将内存中 segment 数据刷新到磁盘中此时我们才能将数据搜索出来所以这就是为什么 Elasticsearch 提供的是近实时搜索功能而不是实时搜索功能。
如果我们的系统对数据延迟要求不高的话我们可以通过延长 refresh 时间间隔可以有效地减少 segment 合并压力提高索引速度。比如在做全链路跟踪的过程中我们就将 index.refresh_interval 设置为30s减少 refresh 次数。再如在进行全量索引时可以将 refresh 次数临时关闭即 index.refresh_interval 设置为-1数据导入成功后再打开到正常模式比如30s。命令如下
# 写入前
PUT test
{settings:{refresh_interval:-1}
}
#写入后
{settings:{refresh_interval:30}
}3. 修改 translog 相关的设置 一是控制数据从内存到硬盘的操作频率以减少硬盘 IO。可将 sync_interval 的时间设置大一些。默认为5s。 index.translog.sync_interval: 5s 也可以控制 tranlog 数据块的大小达到 threshold 大小时才会 flush 到 lucene 索引文件。默认为512m。 index.translog.flush_threshold_size: 512mb 4. 优先使用系统自动生成的ID方式 文档ID即_id 字段的生成有两种方式系统自动生成ID和外部控制自增ID。不过如果使用外部控制自增IDES会先尝试读取原来文档的版本号以判断是否需要更新。也就是说使用外部控制自增ID比系统自动生成ID要多进行一次读取磁盘操作。所以非特殊场景推荐使用系统自动生成ID的方式。
5. 注意 _all 字段及 _source 字段的使用 _all 字段及 _source 字段的使用应该注意场景和需要_all 字段包含了所有的索引字段方便做全文检索如果无此需求可以禁用_source 存储了原始的 document 内容如果没有获取原始文档数据的需求可通过设置 includes、excludes 属性来定义放入 _source 的字段。
6. 合理的配置使用 index 属性 合理的配置使用 index 属性analyzed 和 not_analyzed根据业务需求来控制字段是否分词或不分词。只有 groupby 需求的字段配置时就设置成 not_analyzed以提高查询或聚类的效率。
7. 合理使用分析器 分词器决定分词粒度对于中文分常用的IK分词可细分为粗粒度分词ik_smart和细粒度分词ik_max_word。从存储角度来看基于ik_max_word分词的索引会比基于ik_smart分词的索引占据空间。而更细粒度的自定义分词Ngram会占用大量资源并且可能减慢索引速度并显著增加索引大小。所以要结合**检索指标(召回率和精准率)**以及写入场景进行选型。
8. 合理设置映射 实战业务场景中不推荐使用默认映射一定要手动设置映射。比如默认字符串类型为text8.x后默认为text和keyword的组合类型就不见得使用所有业务场景要结合自己的业务场景进行设置正文文本内容一般不需要设置keyword类型(因为不需要排序和聚合操作)。再比如在互联网公司采集数据并存储的场景中正文文本内容需要进行全文检索但HTML样式的文本一般会留给前端展示用不需要索引因此映射设置要果断将index设置为false。
9. 批量提交 当有大量数据提交的时候建议采用批量提交Bulk 操作此外使用 bulk 请求时每个请求不超过几十M因为太大会导致内存使用过大。 比如在做 ELK 过程中Logstash indexer 提交数据到 Elasticsearch 中batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。 像 Logstash 中提交文档大小超过 20MBLogstash 会将一个批量请求切分为多个批量请求。 如果在提交过程中遇到 EsRejectedExecutionException 异常的话则说明集群的索引性能已经达到极限了。这种情况要么提高服务器集群的资源要么根据业务规则减少数据收集速度比如只收集 Warn、Error 级别以上的日志。
