gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

分类归档Elasticsearch

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  大数据开发
  • 分类归档: "Elasticsearch"
Elasticsearch, solr 10月 4,2024

Lucene、Elasticsearch和Solr在快速查询中的选择研究

第一章 相关理论

1.1 搜索引擎概述

1.1.1 搜索引擎的基本原理

搜索引擎的核心工作原理涉及一系列复杂的过程,从网页抓取到索引构建,再到查询处理和结果排序。这一流程确保了用户能够高效、准确地获取所需信息。搜索引擎通过爬虫程序自动抓取互联网上的网页内容,这些爬虫遵循特定的算法和规则,不断地遍历和更新网页数据。抓取到的网页数据随后被送入索引构建阶段,此阶段通过分词、建立倒排索引等技术手段,为后续的查询服务奠定基础。当用户输入查询关键词时,搜索引擎依据已建立的索引进行快速匹配,并结合相关性排序算法,将最符合用户需求的搜索结果呈现在用户面前]。

1.1.2 搜索引擎的分类

搜索引擎可根据其工作方式和特点分为多种类型,其中全文搜索引擎、目录搜索引擎和元搜索引擎是主要的三种。全文搜索引擎,如Google和Baidu,通过全面索引网页的文本内容来提供广泛的搜索服务。这类搜索引擎能够深入理解网页内容,并根据用户查询的关键词返回相关结果。目录搜索引擎,如Yahoo,则依赖人工编辑的分类目录来提供搜索结果,这种方式虽然覆盖范围有限,但往往能提供更精准、更专业的信息。而元搜索引擎则整合了多个搜索引擎的资源和服务,通过统一的查询接口为用户提供更全面的搜索结果[。

1.1.3 搜索引擎的发展历程

搜索引擎技术的发展经历了多个阶段,从最初的简单文本搜索到现在基于深度学习的语义搜索,每一步技术革新都为用户带来了更优质的搜索体验。早期的搜索引擎主要依赖关键词匹配和基本的排序算法来提供查询服务。随后,基于超链分析的PageRank算法的出现,极大地提高了搜索结果的准确性和相关性。近年来,随着深度学习技术的不断发展,搜索引擎开始融入语义理解、用户意图识别等高级功能,使得搜索结果更加智能化和个性化。这些技术进步不仅提升了搜索引擎的性能,也推动了整个信息检索领域的持续发展。

1.2 Lucene搜索引擎

1.2.1 Lucene的架构设计

Lucene,作为一款高性能、可扩展的信息检索(IR)库,以其灵活的架构设计和强大的功能吸引了众多开发者的关注。其架构设计采用了模块化思想,将不同功能划分为独立的模块,主要包括索引模块、查询模块和存储模块等。这种设计方式不仅提高了系统的可维护性,还为开发者提供了自定义扩展和优化的空间。索引模块负责构建和维护索引,是Lucene实现快速查询的核心;查询模块则提供了丰富的查询方式,满足用户多样化的查询需求;存储模块则负责数据的持久化存储,确保数据的安全性和可靠性。

在Lucene的架构中,各个模块之间通过明确定义的接口进行交互,降低了模块间的耦合度,提高了系统的整体稳定性。同时,Lucene还提供了丰富的API和文档,方便开发者快速上手并集成到自己的应用中。这些特点使得Lucene成为了众多搜索引擎和信息检索系统的首选方案。

1.2.2 Lucene的索引机制

Lucene的快速查询能力得益于其高效的索引机制。Lucene采用倒排索引技术来构建索引,这是一种将文档中的词汇与包含这些词汇的文档列表相关联的数据结构[。通过倒排索引,Lucene可以迅速定位到包含特定词汇的文档,从而实现快速查询。此外,Lucene还支持增量索引和批量索引,以适应不同规模的数据集。增量索引允许在原有索引的基础上添加新的文档,而无需重新构建整个索引;批量索引则适用于大规模数据的一次性索引构建,提高了索引构建的效率。

在构建倒排索引时,Lucene会对文档进行分词处理,将文档拆分为一个个独立的词汇。为了提高查询的准确性,Lucene还支持对词汇进行各种处理,如去除停用词、词形还原等。这些处理步骤有助于减少索引的大小,提高查询的效率和准确性。

1.2.3 Lucene的查询方式

Lucene提供了丰富的查询方式,以满足用户在不同场景下的查询需求。这些查询方式包括精确查询、短语查询、布尔查询、通配符查询和模糊查询等[。精确查询要求用户输入的查询词与文档中的词汇完全匹配;短语查询则允许用户输入一个短语,Lucene会返回包含该短语的文档;布尔查询允许用户使用布尔运算符(如AND、OR、NOT)来组合多个查询条件;通配符查询支持使用通配符(如*、?)来匹配文档中的词汇;模糊查询则允许用户输入一个近似的查询词,Lucene会返回与该词相似的文档。

这些多样化的查询方式为用户提供了极大的灵活性,使得他们可以根据具体需求选择合适的查询方式。同时,Lucene还提供了查询结果的排序功能,用户可以根据相关性、时间等因素对查询结果进行排序,以获取更符合需求的查询结果。这些特点使得Lucene在信息检索领域具有广泛的应用前景。

1.3 Elasticsearch搜索引擎

1.3.1 Elasticsearch的分布式架构

Elasticsearch是一个基于Lucene构建的分布式搜索引擎,其设计初衷就是为了解决大规模数据的实时搜索问题。它通过分布式架构,能够轻松地在多台服务器上并行处理数据,从而显著提高查询效率。这种架构不仅保证了系统的高可用性,还使得Elasticsearch能够轻松应对数据量的不断增长[。

在Elasticsearch的分布式架构中,数据被分散到多个节点上,每个节点都负责存储和处理一部分数据。这种设计方式不仅提高了数据的处理速度,还增强了系统的容错能力。当一个节点发生故障时,其他节点可以继续提供服务,保证搜索引擎的稳定运行。

1.3.2 Elasticsearch的索引机制

Elasticsearch继承了Lucene的索引机制,即采用倒排索引技术来构建索引。这种索引方式将文档中的词汇与包含这些词汇的文档列表相关联,从而实现了快速查询。在Elasticsearch中,索引被进一步分解为多个分片,每个分片都是一个独立的Lucene索引。这种设计方式使得Elasticsearch能够并行处理多个查询请求,提高了查询吞吐量[。

Elasticsearch还支持多种数据类型和复杂的查询操作。用户可以定义自己的映射规则,将不同类型的数据映射到不同的字段上。同时,Elasticsearch还提供了丰富的查询API,支持全文搜索、精确查询、范围查询等多种查询方式,满足了用户的多样化需求。

1.3.3 Elasticsearch的查询方式

Elasticsearch提供了多种灵活且强大的查询方式。其中,全文搜索是Elasticsearch最为核心的功能之一。它允许用户在整个数据集中进行关键词搜索,并且能够根据相关性对结果进行排序。此外,Elasticsearch还支持精确查询,即根据指定的字段值进行精确匹配;范围查询,即根据指定的范围条件进行筛选;以及布尔查询,即组合多个查询条件进行复杂查询等[。

除了基本的查询方式外,Elasticsearch还支持地理位置查询和正则表达式查询等高级功能。地理位置查询允许用户根据地理位置信息进行搜索,例如查找某个区域内的所有文档。正则表达式查询则允许用户使用正则表达式模式匹配文本内容,从而实现更为复杂的文本搜索需求。

1.3.4 Elasticsearch的扩展性

Elasticsearch具有良好的扩展性,能够在集群环境中轻松扩展以处理更大的数据集。它支持水平扩展和垂直扩展两种方式。水平扩展是指通过增加更多的节点来扩展集群的规模和处理能力;而垂直扩展则是指通过提升单个节点的性能来提高整个集群的处理能力[。

在Elasticsearch中,集群的扩展过程非常简单且灵活。用户只需要按照官方文档提供的步骤进行操作,即可轻松地将新的节点加入到集群中。同时,Elasticsearch还提供了丰富的监控和管理工具,帮助用户实时了解集群的状态和性能情况,以便及时进行调整和优化。

1.4 Solr搜索引擎

1.4.1 Solr的架构设计

Solr,一个基于Lucene构建的开源搜索服务器,以其丰富的搜索功能和管理界面在搜索引擎领域占据了一席之地。其架构设计特别注重可伸缩性和可扩展性,使得Solr能够轻松应对大规模数据集的搜索需求。通过支持分布式索引和查询,Solr能够在多台服务器上并行处理数据,从而显著提高查询效率[。

Solr的架构不仅灵活,而且易于扩展。它允许用户根据实际需求自定义扩展和优化,以满足各种复杂的搜索场景。这种模块化设计使得Solr能够轻松集成到各种应用系统中,提供高效、准确的搜索服务[。

1.4.2 Solr的索引机制

Solr的索引机制与Lucene紧密相关,它采用了倒排索引技术来构建索引。这种技术将文档中的词汇与包含这些词汇的文档列表相关联,从而实现快速、准确的查询。倒排索引的构建过程包括词汇分析、文档编号分配、倒排列表生成等步骤,这些步骤共同保证了Solr的高效查询性能[。

除了基本的倒排索引技术外,Solr还支持实时索引和增量索引。实时索引允许用户将新文档立即添加到索引中,使得新内容能够立即被搜索到。而增量索引则允许用户在现有索引的基础上逐步添加新文档,而无需重新构建整个索引。这些功能使得Solr能够满足用户对实时性的要求,同时保持高效的查询性能[。

1.4.3 Solr的查询方式

Solr提供了多种查询方式,以满足用户的不同需求。其中包括全文搜索、精确查询、范围查询和布尔查询等。全文搜索允许用户在整个文档集中搜索包含特定词汇的文档,而精确查询则要求搜索结果与查询条件完全匹配。范围查询允许用户指定一个范围来搜索符合条件的文档,而布尔查询则允许用户使用逻辑运算符来组合多个查询条件[。

Solr还支持高亮显示和分面搜索等高级功能。高亮显示能够将搜索结果中的关键词以醒目方式显示出来,提高用户的阅读体验。而分面搜索则允许用户根据文档的多个属性进行筛选和排序,从而快速找到符合需求的文档]。

1.4.4 Solr的特点

Solr以其强大的搜索功能和管理界面而著称。它提供了丰富的配置选项和工具,使得用户可以轻松部署和维护搜索服务器。同时,Solr还支持多种数据格式和协议,能够与其他系统进行无缝集成。这些特点使得Solr成为企业级搜索解决方案的首选之一[。

Solr的另一个显著特点是其可扩展性。通过支持分布式部署和水平扩展,Solr能够轻松应对不断增长的数据量和查询负载。用户可以根据需要增加或减少服务器节点,以保持搜索服务的高可用性和性能]。这种灵活性使得Solr能够适应各种规模和复杂度的搜索场景。

第二章 Lucene、Elasticsearch和Solr快速查询比较

2.1 查询速度比较

在对比Lucene、Elasticsearch和Solr的查询速度时,我们发现Elasticsearch和Solr通常表现出更优越的性能。这一优势主要源于它们在Lucene的核心技术上所做的优化和改进,从而提供了更高效的查询机制和算法。Elasticsearch和Solr不仅继承了Lucene强大的索引和搜索功能,还针对分布式环境和大规模数据处理进行了专门的优化,因此在处理复杂查询和大数据集时能够保持较高的响应速度。

查询速度并非仅由搜索引擎本身的技术特性决定,还受到多种外部因素的影响。例如,数据量的大小直接关系到索引的构建时间和查询效率。在数据量较小的情况下,Lucene、Elasticsearch和Solr之间的查询速度差异可能并不明显;但随着数据量的增加,Elasticsearch和Solr的分布式架构优势逐渐显现,能够更好地应对大规模数据的查询需求。

索引结构的设计也对查询速度产生重要影响。合理的索引结构能够显著提高查询效率,减少不必要的计算和数据扫描。Lucene提供了灵活的索引构建方式,但要求开发者具备一定的专业知识和经验;相比之下,Elasticsearch和Solr在索引管理方面提供了更为丰富的功能和工具,帮助用户更容易地创建和维护高效的索引结构。

查询复杂度是另一个不可忽视的因素。不同类型的查询(如精确查询、模糊查询、全文搜索等)对搜索引擎的性能要求各不相同。在某些特定类型的查询中,Lucene可能表现出与Elasticsearch和Solr相当甚至更好的性能。因此,在选择搜索引擎时,需要根据实际应用场景中的查询需求进行综合考虑。

虽然Elasticsearch和Solr在查询速度上通常优于Lucene,但具体性能仍然受到数据量、索引结构和查询复杂度等多种因素的共同影响。在实际应用中,我们需要根据具体需求和场景来选择合适的搜索引擎,以达到最佳的查询效果和性能表现。

为了更全面地评估Lucene、Elasticsearch和Solr在快速查询方面的性能,未来研究可以进一步探讨它们在不同数据集、索引策略和查询负载下的表现。通过实验数据和案例分析,我们可以为搜索引擎的选择和优化提供更具体的指导和建议。同时,随着技术的不断发展,我们也需要关注这些搜索引擎在应对新兴挑战(如、大规模实时数据处理多模态搜索等)方面的最新进展和趋势。

2.2 索引速度比较

Lucene、Elasticsearch和Solr在索引速度方面的表现均令人瞩目。作为底层引擎,Lucene凭借其高效的索引能力为信息检索领域奠定了坚实基础。Elasticsearch和Solr则在Lucene的基石上进行了进一步的扩展与优化,从而实现了索引速度的再度提升。

Lucene的索引速度得益于其精巧的架构设计以及优化的索引机制。通过采用倒排索引技术,Lucene能够迅速地将文档中的词汇与包含这些词汇的文档列表相关联,进而在构建索引时展现出卓越的性能。此外,Lucene还支持增量索引和批量索引,这使得它能够灵活应对不同规模的数据集,在保持高效索引的同时,也确保了数据的实时性。

Elasticsearch在继承Lucene索引机制的基础上,通过引入分布式架构进一步提升了索引速度。其分布式特性使得Elasticsearch能够在多台服务器上并行处理数据,从而显著提高了索引的创建和更新效率。同时,Elasticsearch还支持多种数据类型和复杂的查询操作,这使得它在处理大规模实时数据时能够游刃有余。

Solr同样在Lucene的基础上进行了优化,特别注重于提升索引的实时性和增量更新能力。通过采用与Lucene相似的倒排索引技术,并结合实时索引和增量索引的支持,Solr能够确保用户在对数据进行实时更新时,仍然能够保持高效的索引速度。这一特性对于需要频繁更新数据集的应用场景而言,无疑具有极大的吸引力。

尽管Lucene、Elasticsearch和Solr在索引速度方面均表现出色,但具体的索引速度仍然受到多种因素的影响。例如,硬件配置的高低将直接影响到索引的创建和更新效率。在高性能的硬件环境下,这些搜索引擎能够更充分地发挥其索引速度的优势。此外,数据量的大小以及索引策略的选择也会对索引速度产生显著影响。对于大规模数据集而言,合理的索引策略能够显著提高索引效率,降低索引过程中的时间消耗。

Lucene、Elasticsearch和Solr在索引速度方面的优异表现得益于其各自独特的架构设计和优化策略。在实际应用中,用户应根据具体需求和场景选择合适的搜索引擎,并结合硬件配置、数据量以及索引策略等因素进行综合考虑,以实现最佳的索引效果。

2.3 可扩展性比较

在搜索引擎技术中,可扩展性是一个至关重要的考量因素,尤其当面对日益增长的数据量和查询请求时。Elasticsearch和Solr,作为基于Lucene的搜索引擎,均展现出了在可扩展性方面的优势,这些优势主要体现在分布式架构、高可用性以及可配置性上。

Elasticsearch的分布式架构允许其在多台服务器上并行处理数据。这种架构不仅提高了系统的处理能力,还增强了可靠性。通过分片技术,Elasticsearch能够将索引分割成多个部分,并分散存储在不同的节点上,从而实现了数据的水平扩展。当需要增加处理能力时,只需简单地添加更多节点即可。此外,Elasticsearch还提供了丰富的API和插件支持,使得开发者能够根据需要灵活配置和扩展系统功能。

Solr同样具备出色的可扩展性。其架构设计注重可伸缩性和可扩展性,能够轻松应对大规模数据集的搜索需求。Solr支持分布式索引和查询,使得系统能够随着数据量的增长而平滑扩展。与Elasticsearch相似,Solr也提供了丰富的配置选项和插件支持,以满足不同场景下的搜索需求。Solr还具备强大的容错能力,能够在部分节点故障时保证系统的正常运行,进一步提高了其可用性。

Lucene作为底层的搜索引擎库,虽然提供了高性能的索引和查询功能,但在可扩展性方面稍显不足。Lucene本身并不直接支持分布式架构,需要开发者自行实现数据的分布式处理和索引的分片管理。这增加了开发复杂性和维护成本,也使得Lucene在面对超大规模数据集时可能面临挑战。

Lucene的可扩展性限制并不意味着它在所有场景下都不适用。对于中小型规模的数据集或特定领域的搜索需求,Lucene仍然是一个高效且灵活的选择。此外,通过合理的架构设计和优化,开发者也可以在Lucene基础上构建出具备良好可扩展性的搜索系统。

Elasticsearch和Solr在可扩展性方面相较于Lucene具有明显优势。这些优势主要体现在分布式架构、高可用性以及可配置性上,使得它们能够更好地应对日益增长的数据量和查询请求。在选择搜索引擎时,还需根据具体需求和场景进行综合考虑,以确保选择最适合的解决方案。

2.4 其他特性比较

Lucene、Elasticsearch和Solr在查询语法、全文搜索以及用户界面等方面展现出各自独特的特点。

Lucene,作为底层的搜索库,提供了基础的查询语法,如TermQuery、PhraseQuery等,这些语法允许用户进行精确匹配、短语搜索等操作。同时,Lucene的全文搜索功能也相当强大,它能够通过分词器将文本内容切分为单词或词组,并构建倒排索引以实现高效的全文检索。Lucene在用户界面方面相对简单,主要面向开发人员,需要一定的编程知识才能充分利用其功能。

Elasticsearch在Lucene的基础上进行了扩展,提供了更为丰富的查询类型和高级功能。Elasticsearch的查询DSL(领域特定语言)允许用户以JSON格式编写复杂的查询语句,支持多种查询类型的组合,如bool查询、range查询等。此外,Elasticsearch还支持地理位置查询、聚合查询等高级功能,这些功能使得Elasticsearch在处理复杂搜索需求时表现出色。在用户界面方面,Elasticsearch提供了Kibana这一可视化工具,用户可以通过Kibana轻松地构建仪表盘、监控集群状态以及进行搜索分析等操作。

Solr则提供了基于Lucene的丰富快速搜索查询功能方案和管理界面。Solr的查询语法与Lucene相似,但它在易用性和功能性上进行了增强。例如,Solr支持面搜索(faceted search),这是一种允许用户根据分类或属性对搜索结果进行过滤的功能,大大提高了搜索的灵活性和准确性。同时,Solr的管理界面非常友好,提供了丰富的配置选项和监控工具,使得用户可以轻松地部署和维护搜索服务。此外,Solr还支持多种数据格式和协议的导入,能够与其他系统进行无缝集成,从而满足用户在不同场景下的搜索需求。

Lucene、Elasticsearch和Solr在查询语法、全文搜索以及用户界面等方面各有千秋。Lucene提供了基础的搜索功能,适合作为底层库进行开发;Elasticsearch在Lucene的基础上增加了更多高级功能,适合处理复杂搜索需求;而Solr则注重易用性和管理性,适合作为企业级搜索解决方案。在选择时,用户应根据自身需求和场景进行权衡考虑。

第三章 基于Lucene、Elasticsearch和Solr的快速查询方案

3.1 Lucene快速查询方案

Lucene,作为一款高性能、可扩展的信息检索库,为开发者提供了构建高效搜索引擎的基础。在实现Lucene的快速查询方案时,我们需要从索引构建、查询优化以及性能评估等多个方面进行深入探讨。

在索引构建方面,首先,要明确索引的结构和内容。对于大规模的数据集,我们需要合理地划分索引的粒度,以保证索引的效率和查询的准确性。此外,利用Lucene的增量索引功能,可以实时地更新索引,从而确保查询结果的实时性。为了提高索引的效率,我们还可以考虑使用并行索引技术,将数据分散到多个索引中进行处理。

查询优化是提升Lucene查询速度的关键环节。我们可以从查询语句的构造、查询策略的选择以及查询结果的排序等方面进行优化。具体来说,优化查询语句可以减少不必要的词汇和短语,从而提高查询的精确性和效率;选择合适的查询策略,如布尔查询、短语查询等,可以根据实际需求获取最相关的结果;而合理的排序算法则能够确保用户在最短的时间内找到所需信息。

性能评估是确保快速查询方案有效性的重要手段。我们可以通过对比不同查询策略的执行时间、准确率和召回率等指标,来评估查询方案的优劣。此外,还可以利用Lucene提供的性能监测工具,实时监控查询过程的性能表现,从而及时发现并解决潜在的性能瓶颈。

基于Lucene的快速查询方案需要从索引构建、查询优化和性能评估等多个方面进行综合考虑。通过合理地设计索引结构、优化查询策略以及持续地进行性能评估,我们可以构建出高效、稳定的搜索引擎,为用户提供更加优质的查询体验。

3.2 Elasticsearch快速查询方案

Elasticsearch作为一款功能强大的分布式搜索引擎,其快速查询方案的设计与实施涉及多个关键环节。以下将详细介绍基于Elasticsearch的快速查询方案,涵盖集群配置、索引构建、查询优化等方面。

3.2.1 集群配置

Elasticsearch的集群配置是实现快速查询的基础。首先,需要合理规划集群的拓扑结构,确定主节点、数据节点和协调节点的数量和配置。主节点负责管理集群状态和元数据,数据节点负责存储和检索数据,而协调节点则负责接收客户端请求并协调其他节点完成查询操作。

在配置过程中,应充分考虑硬件资源、网络带宽和数据量等因素,以确保集群的稳定性和性能。此外,还可以通过设置合理的分片策略和副本策略来优化数据存储和查询性能。

3.2.2 索引构建

索引构建是Elasticsearch快速查询方案中的关键环节。为了提高查询效率,需要合理设计索引结构,包括字段类型、分析器和映射等。

在字段类型方面,应根据数据的实际特点选择合适的类型,如文本、关键字、日期等。同时,可以利用分析器对文本字段进行分词处理,以便更好地支持全文搜索功能。

在映射方面,需要定义索引中的字段及其属性,以确保数据的正确存储和检索。此外,还可以通过设置动态映射规则来自动处理新字段的映射问题。

3.2.3 查询优化

查询优化是Elasticsearch快速查询方案中的核心环节。为了提高查询性能,可以采取以下措施:

1、精确查询:尽量避免使用高开销的通配符查询和正则表达式查询,而是使用精确查询来获取特定字段的值。

2、利用过滤器:过滤器可以在不计算评分的情况下过滤文档,从而提高查询效率。在可能的情况下,应尽量使用过滤器而非查询来缩小结果集。

3、分页与滚动:对于大量数据的查询结果,可以采用分页或滚动的方式来逐步获取数据,以减少单次查询的负载。

4、缓存策略:合理利用Elasticsearch的缓存机制,如请求缓存、查询结果缓存等,可以减少重复查询的开销。

5、监控与调优:定期对Elasticsearch集群进行监控和调优,以确保其处于最佳性能状态。这包括检查硬件资源使用情况、调整配置参数、优化索引结构等。

基于Elasticsearch的快速查询方案需要从集群配置、索引构建和查询优化等多个方面进行综合考虑和实施。通过合理规划和设计,可以充分发挥Elasticsearch在快速查询方面的优势,满足用户的高效检索需求。

3.3 Solr快速查询方案

在构建基于Solr的快速查询方案时,我们需要综合考虑集群配置、索引构建、查询优化等多个方面,以确保系统能够满足高性能、高可扩展性和易用性的需求。

Solr支持分布式搜索,因此,集群配置是实现快速查询的关键。我们需要根据数据量和查询负载来合理规划集群的规模,包括节点数量、硬件配置等。同时,我们还需要配置SolrCloud模式,以实现数据的自动分片、冗余复制和负载均衡,提高系统的可用性和容错性。

在集群配置过程中,我们还需要关注网络延迟、数据一致性等问题,以确保集群的稳定性和性能。此外,我们还可以通过配置Solr的监控和日志系统,实时监控集群的状态和性能,及时发现并解决问题。

索引是Solr实现快速查询的基础。在构建索引时,我们需要根据数据的特征和查询需求来选择合适的字段类型、分析器和索引策略。例如,对于文本字段,我们可以选择使用全文搜索引擎来支持复杂的文本搜索;对于数值字段,我们可以选择使用范围查询来支持数值范围的搜索。

我们还需要关注索引的更新和维护问题。Solr支持实时索引和增量索引,我们可以根据数据的更新频率和查询需求来选择合适的索引更新策略。同时,我们还需要定期优化和重建索引,以提高索引的质量和查询性能。

查询优化是实现Solr快速查询的关键环节。在编写查询语句时,我们需要根据数据的特征和查询需求来选择合适的查询类型和语法,以提高查询的准确性和效率。例如,对于精确匹配的需求,我们可以选择使用精确查询;对于模糊匹配的需求,我们可以选择使用模糊查询或通配符查询。

除了查询语句的优化外,我们还可以通过配置Solr的查询缓存、结果高亮、分面搜索等高级功能来进一步提升查询的性能和用户体验。例如,通过配置查询缓存,我们可以缓存热门查询的结果,减少重复计算的开销;通过配置结果高亮,我们可以突出显示查询结果中的关键词,提高用户的阅读体验。

基于Solr的快速查询方案需要综合考虑集群配置、索引构建和查询优化等多个方面。通过合理的规划和优化,我们可以构建一个高性能、高可扩展性和易用的搜索引擎系统,满足用户的多样化查询需求。

作者 east
Elasticsearch, spring 3月 22,2022

Spring Boot直接输出到Logstash

Spring Boot应用程序可以直接远程输出到Logstash。这里以Logback日志为例,新建项目,在项目中加入Logstash依赖。

1、 要使用logback一个插件来将数据转成json,引入maven配置

dependency>

      <groupId>net.logstash.logback</groupId>

      <artifactId>logstash-logback-encoder</artifactId>

     <version>5.3</version>

</dependency>



2、配置 logback-spring.xml

接下来,在src/resources目录下创建logback-spring.xml配置文件,在配置文件中将对日志进行格式化,并且输出到控制台和Logstash。需要注意的是,在destination属性中配置的地址和端口要与Logstash输入源的地址和端口一致,比如这里使用的是127.0.0.1:4560,则在Logstash输入源中要与这个配置一致。其中logback-spring.xml内容如

<xml version="1.0" encoding="UTF-8"?>

    <configuration scan="true" scanPeriod="60 seconds" debug="true">

         <contextName>logstash-test</contextName>

   <!-- 这个是控制台日志输出格式 方便调试对比--->

    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">

      <encoder>

          <pattern>%d{yyyy-MM-dd HH:mm:ss} %contextName %-5level %logger{50} -%msg%n</pattern>

   </encoder>

</appender>

<appender name="stash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">

  <destination>127.0.0.1:4560</destination> 这是是logstash服务器地址 端口

  <encoder class="net.logstash.logback.encoder.LogstashEncoder" /> 输出的格式,推荐使用这个

</appender>

<root level="info">

   <appender-ref ref="console"/>

   <appender-ref ref="stash"/>

</root>

启动项目,就会请求127.0.0.1:4560,如果有监听,就会自动发送日志。

3、logstash配置

input {

             tcp {

                        host => "localhost" #这个一定要是logstash本机ip,不然logstash 无法启动,也可以去除

                        port => 4560

                       codec => json_lines

                       mode => "server"

                  }

}

filter {

                 grok {

               match => {

"message" => "%{URIPATH:request} %{IP:clientip} %{NUMBER:response:int} \"%{WORD:sources}\" (?:%{URI:referrer}|-) \[%{GREEDYDATA:agent}\] \{%{GREEDYDATA:params}\}"

     }

}


output {

       stdout { codec => rubydebug } #标准输出,在命令行中输出方便调试

elasticsearch { hosts => [ "localhost:9200" ]

index => "pybbs"

document_type => "weblog"

    }

}

如果数据特别多,上述方案就会为Elasticsearch带来很大的压力。为了缓解Elasticsearch的压力,可以将Logstash收集的内容不直接输出到Elasticsearch中,而是输出到缓冲层,比如Redis或者Kafka,然后使用一个Logstash从缓冲层输出到Elasticsearch。当然,还有很多种方案进行日志收集,比如使用Filebeat替换Logstash等。笔者在生产环节搭建过ELK配置,这里提几点建议:

(1)根据日志量判断Elasticsearch的集群选择,不要盲目追求高可用,实际应用需要根据实际场景的预算等因素使用。

(2)缓冲层选择,一般来说选择Kafka和Redis。虽然Kafka作为日志消息很适合,具备高吞吐量等,但是如果需求不是很大,并且环境中不存在Kafka,就没有必要使用Kafka作为消息缓存层,使用现有的Redis也未尝不可。

(3)内存分配,ELK三者部署都是占有一定内存的,并且官网建议的配置都很大。建议结合场景来修改配置,毕竟预算是很重要的一环。

作者 east
Elasticsearch, neo4j, solr 3月 22,2022

neo4j、solr、es数据同步和增量更新

一、Neo4j的数据增量更新:

图数据除了节点的增量更新还牵扯到边的增量更新,节点其实还好说,无论是新增节点还是新增节点属性或者是节点属性更新,实际上都是在节点表可以完成,不是很消耗资源;比较复杂且影响更新效率的其实边的增量更新。

1、节点更新

这个需求其实很普遍,比如我有一个节点:

(n:Person {id: 'argan', name: 'argan', age: 32})

然后用户又传递了一个人数据过来:

{id: 'argan', age: 30, sex: 'male', email: 'arganzheng@gmail.com'} 

可以看到更新了一个属性:年龄,新增了两个属性:性别和电子邮件。我们希望最后的结果是:

(n:Person {id: 'argan', name: 'argan', age: 30, sex: 'male', email: 'arganzheng@gmail.com'})。

需要注意的是name是没有传递的,但还是保留着的。如果要删除一个属性,需要把它的值显式的设置为空。

在Neo4j的要怎么做到呢?

Neo4j的提供了合并语句来实现这个功能。

与ON CREATE和ON MATCH合并

如果需要创建节点,请合并节点并设置属性。

MERGE (n:Person { id: 'argan' })
ON CREATE SET n.created = timestamp()
ON MATCH SET n.lastAccessed = timestamp()
RETURN n.name, n.created, n.lastAccessed

上面的例子可以这么写:

MERGE (n:Node {id: 'argan'}) SET n += {id: 'argan', age: 30, sex: 'male', email: 'arganzheng@gmail.com'} 
RETURN n 

因为这里采用了+=本身就是合并属性,所以区分不需要的英文ON CREATE还是ON MATCH。

同样关系也可以用合并保证只创建一次:

MATCH (n), (m) WHERE n.id = "argan" AND m.id = "magi" CREATE (n)-[:KNOWS]->(m)

写成这样子就可以保证唯一了:

MATCH (n:User {name: "argan"}), (m:User {name: "magi"}) MERGE (n)-[:KNOWS]->(m)

2、neo4j如何支持动态节点标签和关系类型?

上面的合并语句能够实现“存在更新,否则创建”的逻辑,但是还有一个问题没有解决,就是没有设置节点的标签。我们希望构建的节点数据完全是运行时根据用户提供的数据构造的,包括。标签比如用户提供如下数据:

:param batch: [{properties: {name: "argan", label: "Person", id: "1", age: 31}}, {properties: {name: "magi", label: "Person", id: "2", age: 28}}]

下面的暗号语句并没有设置节点的标签,虽然节点有一个叫做标签的属性:

UNWIND {batch} as row 
MERGE (n {id: row.id})
SET n += row.properties

那么我们能不能简单的指定标签呢?

UNWIND {batch} as row 
MERGE (n:row.properties.label {id: row.id})
SET n += row.properties

但是遗憾的是这个语句会报错,因为neo4j不支持动态的节点标签。把row.properties.label去掉或者改成一个固定的字符串就没有问题。

改成这样子也不行:

UNWIND {batch} as row   MERGE (n {id: row.id} )   SET n:row.properties.label,  n += row.properties

绑定变量也不行:

UNWIND {batch} as row   MERGE (n {id: row.id} )   SET n:{label},  n += row.properties

直接指定标签就可以了:

UNWIND {batch} as row   MERGE (n {id: row.id} )   SET n:Test,  n += row.properties

也就是说3.3.13.9。在节点上设置标签也并不支持动态标签..

笔记

neo4j的设置标签还有一个问题,就是它其实是新增标签,不是修改标签。要到更新的效果,你需要先删除掉,再新增..

MATCH (n) WHERE ID(n) = 14  REMOVE n:oldLabel SET n:newLabel

如果是单条数据更新,那其实很简单,我们只需要做字符串拼接就可以了:

String label = vertex.getLabel(); "MERGE (n:" + label + " {id: {id}} " + "SET n += {properties}"

但是关键是我们这里是在Neo4j的内部用开卷展开的服务端变量,如果它不允许动态变量,根本搞不定。难道真的要一条条的插入,那会非常慢的!Neo4j的的插入性能是众所周知的差。一种做法就是先批量插入数据,设置一个临时的标签,然后再批量的更新标签。不过需要两次操作,性能肯定至少慢两倍。

有没有什么方式呢?谷歌了很久,发现了也有人遇到这样的问题:功能请求:apoc支持MERGE节点和rels#271和是否可以使用数据驱动的节点或关系标签进行合并?。

原理跟单条数据插入一样,只是由于退绕是在服务端(Neo4j的)进行的,所以拼接也只能在服务端进行,怎么拼接的就是用?apoc.cypher.doIt拼接后让它在服务端执行:

UNWIND {batch} as row  WITH 'MERGE (n:' + row.properties.label + ' { id: row.id }) SET n += row.properties return n' AS cypher CALL apoc.cypher.doIt(cypher, {}) YIELD value return value.n

但是可惜,会报这样的异常:

org.neo4j.driver.v1.exceptions.ClientException: 
Failed to invoke procedure `apoc.cypher.doIt`: 
Caused by: org.neo4j.graphdb.QueryExecutionException: 
Variable `row` not defined (line 1, column 23 (offset: 22)) "MERGE (n:Person { id: row.id }) SET n += row.properties return n"

所以还是要分两步进行,不过可以合并在一起SET标签:传递标签名称作为参数:

UNWIND {batch} as row  MERGE (n { id: row.id }) 
SET n += row.properties  WITH n  CALL apoc.create.addLabels(id(n), [n.label]) 
YIELD node RETURN node

这样就可以正确的保存数据并且动态设置标签了。笔

本来我们是可以直接使用APOC库的apoc.merge.node状语从句:apoc.create.relationship动态的更新节点标签,关系和节点的。但是正如前面分析的,apoc.merge.node状语从句:apoc.create.relationship现在的实现其实的英文一个防重复CREATE而已,不能达到更新的目的。否则我们的实现将非常简单明了:

更新节点:

UWNIND {batch} as row CALL apoc.merge.node(row.labels, {id: row.id} , row.properties) 
yield node RETURN count(*)

更新关系:

UWNIND {batch} as row MATCH (from) WHERE id(from) = row.from 
MATCH (to:Label) where to.key = row.to CALL apoc.merge.relationship(from, row.type, {id: row.id}, row.properties, to) 
yield rel RETURN count(*)

一种做法就是叉一个分支出来,修改源码,部署自己的罐子包。

二、solr 的增量更新

1.首先要弄懂几个必要的属性,以及数据库建表事项,和dataimporter.properties 、data-config.xml里面的数据

<!–  transformer 格式转化:HTMLStripTransformer 索引中忽略HTML标签   —> 
  <!–  query:查询数据库表符合记录数据   —> 
  <!–  deltaQuery:增量索引查询主键ID    —>    注意这个只能返回ID字段 
  <!–  deltaImportQuery:增量索引查询导入数据  —> 
  <!–  deletedPkQuery:增量索引删除主键ID查询  —> 注意这个只能返回ID字段

2.数据库配置注意事项

1.如果只涉及添加,与修改业务,那么数据库里只需额外有一个timpstamp字段 
就可以了,默认值为当前系统时间,CURRENT_TIMESTAMP
2.如果还涉及删除业务,那么数据里就需额外再多添加一个字段isdelete,int类型的 
用0,1来标识,此条记录是否被删除

3.dataimporter.properties 

这个配置文件很重要,它是用来记录当前时间与上一次修改时间的,通过它能够找出,那些,新添加的,修改的,或删除的记录标识,此条记录是否被删除的记录

4.增量更新就是在全量更新的基础上加上一些配置,配置如下:

<?xml version="1.0" encoding="UTF-8" ?>
<dataConfig> 
    <!--数据源-->
    <dataSource type="JdbcDataSource"
                driver="com.mysql.jdbc.Driver"
                url="jdbc:mysql://192.168.2.10:3306/xtjkqyfw"
                user="root"
                password="Biaopu8888"/>
    <document> 

        <entity name="solrTest" 
        query="SELECT fid,ftime,fcontent,ftitle,flastupdatetime FROM solrTest where flag = '0'"
        deltaImportQuery = "SELECT fid,ftime,fcontent,ftitle,flastupdatetime FROM solrTest where fid = '${dataimporter.delta.fid}'"
        deltaQuery = "SELECT fid FROM solrTest where flastupdatetime > '${dataimporter.last_index_time}' and flag = '0'"
        deletedPkQuery = "SELECT fid FROM solrTest where flag = '1'"
        >
            <!--查询的数据和数据库索引意义对应column 是查询的字段name 是solr索引对应的字段-->
            <field column="fid" name="fid"/>
            <field column="ftitle" name="ftitle"/>
            <field column="fcontent" name="fcontent"/>
            <field column="flastupdatetime" name="flastupdatetime"/>
            <field column="ftime" name="ftime"/>
        </entity>
        
    </document> 
</dataConfig>

三、LOGSTASH-INPUT-JDBC 实现数据库同步ES

在数据方面碰到第一个问题是怎么将postgres中的数据库中同步到es中,在网上找了下相关文档,只有logstash-input-jdbc这个插件还在维护,而且在es中logstash高版本已经集成了这一插件,所以就省去了安装ruby和安装插件这一步了

1 安装elasticsearch logstash kibana 三件套

2 下载数据库驱动

图方便的话可以直接拷贝maven仓库里面的即可

3 添加 .conf文件

input {  
jdbc {
# mysql 数据库链接,shop为数据库名
jdbc_connection_string => "jdbc:postgresql://ip:5432/chongqing_gis"
# 用户名和密码
jdbc_user => ""
jdbc_password => ""
# 驱动
jdbc_driver_library => "E:/ES/logstash-7.8.0/postgres/postgresql-42.2.9.jar"
# 驱动类名
jdbc_driver_class => "org.postgresql.Driver" jdbc_paging_enabled => "true"
jdbc_page_size => "50000"
# 执行的sql 文件路径+名称
statement_filepath => "E:/ES/logstash-7.8.0/postgres/jdbc.sql" # 设置监听间隔 各字段含义(由左至右)分、时、天、月、年,全部为*默认含义为每分钟都更新
# schedule => "* * * * *"
}
}
filter {
json {
source => "message"
remove_field => ["message"]
}
}
output {
elasticsearch {
# ES的IP地址及端口
hosts => ["localhost:9200"]
# 索引名称
index => "test_index"
# 需要关联的数据库中有有一个id字段,对应类型中的id document_id => "%{gid}"
}
stdout {
# JSON格式输出
codec => json_lines
}
}

修改输入参数:数据库ip、端口、账号、密码等

修改输出参数:es的ip、端口、索引、document_id等

输出参数中索引如果还没有创建,在启动logstash时会自动根据默认模板创建索引,其中有些教程中出现了index_type的设置,这个类型在es的高版本中已经取消,不需要再设置,如果设置了,启动logstash会报错

statement_filepath 保存准备执行的sql文件

jdbc.sql文件:

select gid,name,address from qtpoi

在qtpoi表中有个字段是保存的空间地理信息geom字段,当我加上这个时,启动logstash一直报错,可能对空间字段需要做进一步的处理

Exception when executing JDBC query {:exception=>#<Sequel::DatabaseError: Java::OrgLogstash::MissingConverterException: Missing Converter handling for full class name=org.postgresql.util.PGobject, simple name=PGobject

4 启动logstash即可同步

bin/logstash -f config/postgres.conf

5 打开kibana即可查看到刚同步的数据

GET test_index/_doc/_search

6 如果设置了定时任务,logstash会定时去访问数据同步到es中,但是上面jdbc.sql文件中获取的是整张表的数据,也就是说每次同步都会对全表进行同步,但是我的需求是只需要第一次同步整张表后面只对更新的和修改的数据做同步,

在网上找了下,思路大概是给表增加一个新的字段,保存当前创建的时间或者是当前更新的时间,然后根据:sql_last_value这个函数获取大于这个函数的时间,就过滤出新增的数据和更新的数据,实现对增量数据同步到es,:sql_last_value这个函数官网也没说的太清楚,我大致认为是最后一个更新的值或者最后一次更新的时间

作者 east
bug清单, Elasticsearch 2月 12,2021

ES无法重启问题分析

ES无法重启问题分析

题背景:

对ES集群进行了重启,集群重启几分钟后,部分实例开始逐渐下线,导致集群不可恢复。

集群规模:

普通模式,3EsMaster,40EsNode,每实例均为31GB内存。

数据量:

1000多index,38365个shard,其中主分片28695个,数据量100T。

日志分析:

ES集群重启,恢复几分钟后,出现大量ping Master节点超时的错误,然后ES节点实例开始逐渐下线,导致集群恢复不了。

原因分析:

集群分片数过多,并发恢复过程中,同时业务没有停止,导致EsMaster处理压力过大,number_of_pending_tasks(挂起的任务)逐渐增加,到达4W多,大量的任务阻塞。

此时_cluster/health命令已无法正常返回结果,导致大量ES实例处于恢复中状态,连续3次检查超时后,Manger将会重启实例。就会导致挂起的任务越来越多,集群不可恢复。

处理步骤:

  1. 重启的过程中,发现大量ES实例执行_cluster/health命令超时错误,但其实数据仍在缓慢恢复中。于是注释_cluser/health检查脚本,防止实例多次失败后,被manger重启。
  2. 再次重启后,发现大量分片处于未分配状态,执行_cluster/allocation/explain查看分片未被分配的原因,发现shard恢复时的cluster.routing.allocation.node_current_incoming达到了最大值。鉴于集群主分片数太多,于是调大恢复参数至:cluster.routing.allocation.node_initial_primaries_recoveries 200 cluster.routing.allocation.node_concurrent_recoveries 100 cluster.routing.allocation.cluster_concurrent_rebalance 100 同时因为有业务数据写入,将分片分配设置为none:cluster.routing.allocation.enable none
  3. 再次重启后,集群开始恢复,查看_cat/thred_pool/,generic 线程池(分片恢复会用到该线程池)已经到达128,查看界面CPU使用率也在70-80,查看日志,分片正在恢复中。
  4. 10分钟左右,集群恢复到80%左右,开始恢复缓慢,初始化分片(initializing_shards)有2000多个,这些分片初始化的过程耗时接近2小时 原因分析:因为在多次重启的过程中,业务侧并没有停止,由于有些primary新写入了数据,在数据的recovery过程中,需要从主副本之间拷贝数据,或者利用translog恢复数据。直达primary-replica完全in-sync后,才会完成初始化。 这个过程取决于shard的大小和新写入量的大小(初始化的分片普遍数据量较大)。
    1. 最后有一个分片无法分配,查看原因,该分片无法从translog in-sync(同步),查看该索引settings,sync_interval设置为360s,设置同步刷新时间过多,会有一定几率发生数据丢失(客户有原数据备份)。
    2. 集群恢复后,还原集群参数配置和健康检查脚本。

问题根因:

  1. 集群的分片数过多,按一个实例管理600shard为标准,该集群分片数过度超标的。合 理设置索引分片,定期对历史索引进行处理(关闭或删除不需要的索引)。
  2. 目前的健康检查机制需要优化,使用_cluster/health去判断各实例的健康是否合理,包 括检查周期等。在EsMaster压力过大的情况下,_cluster/health可能会造成误判。
作者 east
bug清单, Elasticsearch 2月 12,2021

ES实例磁盘空间不足,导致索引read-only

ES实例磁盘空间不足,导致索引read-only

题现象:

数据导入失败错误日志:

retrying failed action with response code: 403 ({“type”=>”cluster_block_exception”, “reason”=>”blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]

问题原因:

磁盘空间不足,磁盘使用率大于95%,索引被强制设置为只读,导致数据无写入。

解决办法:

1. 下线磁盘空间不足的ES实例。

curl -XPUT --negotiate -k -u : "https://127.0.0.1:24100/_cluster/settings" -H 'Content-Type: application/json'  -d '{
"transient" : {
"cluster.routing.allocation.exclude._name" : "EsNode1@192.168.198.6, EsNode2@192.168.198.6 "
}
}'

2. 等待数据迁移完成。执行_cluster/healht命令查询relocating_shards参数的值,直到变为0,说明迁移完毕。

curl -XGET --negotiate -k -u : "https://127.0.0.1:24100/_cluster/health?pretty"

3. 修改索引只读字段属性为null,放开写入。

curl -XPUT --negotiate -k -u : "https://127.0.0.1:24100/*/_settings" -H 'Content-Type: application/json' -d '{"index.blocks.read_only_allow_delete": null}'

4. 继续写入数据。

作者 east
bug清单, Elasticsearch 2月 12,2021

es bulk入库数据丢失 分析思路

bulk入库数据丢失

【问题现象】

用户反馈数据,会生成报文,每天丢20%的报文,ES中存储的是2种日志,通过抽了2个业务日志做比对,反馈说有一些流水的号没有打出来,怀疑有丢失数据的情况

【分析过程】

建议业务单独入库疑似丢掉的数据,但是数据已经丢失,没法复现。

后续了解到业务是通过bulk批量方式入库的,但是bulk方式入库会有个现象:批量入库后会返回整体的成功信息,如果此批次里面有错误数据的话是不会报错的,同时也不会入库错误数据,带来的现象就是数据丢失。

随即本地模拟了bulk方式入库,如下入库3条数据,在其中构造出一条错误数据,可以看到整体是反馈成功的。

bulk入库数据丢失

后续通过查询索引只能查询出2条数据,如下:

bulk入库数据丢失

【处理建议】

1. 从入库数据源头提前了解到数据信息,防止错误数据入库。

2. 可以对代码二次开发进行每条入库数据解析,能及时观察到错误数据。

3. 单独入库每条数据,会对性能有较大影响。

作者 east
Elasticsearch 1月 31,2021

ES的内存xms和xmx设置不一致导致启动失败

ES的内存xms和xmx设置不一致导致启动失败

问题背景与现象

ES启动失败:

1. 页面显示ES实例启动失败,查看详情是Xms和Xmx大小不一致;

ES的内存xms和xmx设置不一致导致启动失败

2. 查看ES后台日志,报错如下,初始化内存和最大内存不一致,导致启动失败

/var/log/Bigdata/elasticsearch/esnode1/elasticsearch_cluster.log

2018-12-11T17:21:49,670][INFO ][o.e.b.BootstrapChecks    ] [EsNode1] bound or publishing to a non-loopback address, enforcing bootstrap checks
[2018-12-11T17:21:49,673][ERROR][o.e.b.Bootstrap          ] [EsNode1] node validation exception
[1] bootstrap checks failed
[1]: initial heap size [536870912] not equal to maximum heap size [1073741824]; this can cause resize pauses and prevents mlockall from locking the entire heap
[2018-12-11T17:21:49,677][INFO ][o.e.n.Node               ] [EsNode1] stopping ...
[2018-12-11T17:21:49,708][INFO ][o.e.n.Node               ] [EsNode1] stopped
[2018-12-11T17:21:49,708][INFO ][o.e.n.Node               ] [EsNode1] closing ...
[2018-12-11T17:21:49,721][INFO ][o.e.n.Node               ] [EsNode1] closed

原因分析

如果JVM以不等的初始(Xms)和最大(Xmx)堆(heap)大小启动,则可能会在系统使用期间调整JVM堆的大小,因此可能会暂停。为了避免这些调整大小的停顿,需要使初始(Xms)堆(heap)大小等于最大Xms堆(heap)大小启动JVM。另外,启用了bootstrap.memory_lock,JVM将在启动时锁定堆(heap)的初始(Xms)大小。如果初始堆大小不等于最大堆大小,在重新调整大小之后,将不会将所有JVM堆锁定在内存中。

因此是ES的内核限制,要求ES的启动参数的初始(Xms)和最大(Xmx)内存相等。

作者 east
Elasticsearch 1月 31,2021

Elasticsearch(ES)运维常用命令

集群检查常用命令

1. 查询集群状态命令:

curl -XGET "http://ip:port/_cluster/health?pretty"

2. 查询Es全局状态:

curl -XGET "http://ip:port/_cluster/stats?pretty"

3. 查询集群设置

curl -XGET "http://ip:port/_cluster/settings?pretty"

4. 查看集群文档总数

curl -XGET "http://ip:port/_cat/count?v"

4. 查看集群文档总数

curl -XGET "http://ip:port/_cat/count?v"

5. 查看集群别名组

curl -XGET "http://ip:port/_cat/aliases"

6.查看当前集群索引分片信息

curl -XGET "http://ip:port/_cat/shards?v"   注:查看某一个索引可用shards/索引名?v

7.查看集群实例存储详细信息

curl -XGET "http://ip:port/_cat/allocation?v"

8.查看当前集群的所有实例

curl -XGET "http://ip:port/_cat/nodes?v"

9.查看某索引分片转移进度

curl -XGET "http://ip:port/_cat/recovery/索引名?v"

10.查看当前集群等待任务

curl -XGET "http://ip:port/_cat/pending_tasks?v"

11.查看集群写入线程池任务

curl -XGET "http://ip:port/_cat/thread_pool/bulk?v" 

12.查看集群查询线程池任务

curl -XGET "http://ip:port/_cat/thread_pool/search?v" 

13.查看分片未分配的原因

curl -XGET "http://127.0.0.1:24100/_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason" | grep UNASSIGNED

集群设置常用命令

1. 设置集群分片恢复参数

curl -XPUT   "http://ip:httpport/_cluster/settings"  -H  'Content-Type: application/json' -d' 
{ 
"transient": { 
   "cluster.routing.allocation.node_initial_primaries_recoveries":60,
   "cluster.routing.allocation.node_concurrent_recoveries":30,
   "cluster.routing.allocation.cluster_concurrent_rebalance":30
   } 
}'

2. 根据实例名称使EsNodeX实例下线:

curl -XPUT  "http://ip:httpport/_cluster/settings" -H 'Content-Type: application/json' -d' 
{ 
    "transient": { 
        "cluster.routing.allocation.exclude._name": "EsNode2@ip" 
     } 
}'

3. 根据ip使ES数据节点下线:

curl -XPUT  "http://ip:httpport/_cluster/settings" -H 'Content-Type: application/json' -d' 
{ 
    "transient": { 
          "cluster.routing.allocation.exclude._ip": "ip1,ip2,ip3" 
     } 
}'

4. 设置分片恢复过程中的最大带宽速度:

curl -XPUT "http://127.0.0.1:24100/_cluster/settings" -H 'Content-Type: application/json' -d
'{
 "transient":{
     "indices.recovery.max_bytes_per_sec":"500mb"
  }
}'

5. 重新分片为空的主分片

 curl -XPOST  "http://127.0.0.1:24100/_cluster/reroute?pretty" -H 'Content-Type:application/json' -d '
{
   "commands": [{
                "allocate_empty_primary": {		
                                      "index": "indexname",			
                                      "shard": 2,
                                      "node": "EsNode1@81.20.5.24",
                                      "accept_data_loss":true
                                           }
               }]
}'

6. 重新分配主分片,会尝试将过期副本分片分片为主。

curl -XPOST "http://127.0.0.1:24100/_cluster/reroute?pretty" -H 'Content-Type:application/json' -d '
{
   "commands": [{
               "allocate_stale_primary": {
                                        "index": "index1",
                                        "shard": 2,
			                "node": "EsNode1@189.39.172.103",
                                        "accept_data_loss":true
                                          }
               }]
}'

7. 清理ES所有缓存

curl -XPOST "http://ip:port/_cache/clear"

8.关闭分片自动平衡

curl -XPUT
 "http://ip:port/_cluster/settings" -H 'Content-Type:application/json' -d '
{
   "transient":{   "cluster.routing.rebalance.enable":"none" }
}'

9.手动刷新未分配的分片

curl -XPOST "http://127.0.0.1:24100/_cluster/reroute?retry_failed=true"

索引查看常用命令

1. 查询索引mapping和settings

curl -XGET --tlsv1.2  --negotiate -k -u : 'https://ip:port/my_index_name?pretty'

2. 查询索引settings

curl -XGET--tlsv1.2  --negotiate -k -u : 'https://ip:port/my_index_name/_settings?pretty'

3.查看分片未分配详细命令

curl -XGET "http://127.0.0.1:24100/_cluster/allocation/explain?pretty" -H 'Content-Type:application/json' -d '
{"index": "indexname","shard": 17,"primary": true}'

4.修改索引只读字段属性为null,放开写入

curl -XPUT  "http://127.0.0.1:24100/*/_settings" -H 'Content-Type: application/json' -d '{"index.blocks.read_only_allow_delete": null}'

索引设置常用命令

1.关闭索引

curl -XPOST 'http://ip:port/my_index/_close?pretty'

2.打开索引

curl -XPOST 'http://ip:port/my_index/_open?pretty'

3.修改索引刷新时间:

curl -XPUT 'http://ip:port/my_index/_settings?pretty' -H 'Content-Type: application/json' -d'{"refresh_interval" : "60s"}'

4.修改translog文件保留时长,默认为12小时

curl -XPUT 'http://ip:port/my_index/_settings?pretty' -H 'Content-Type: application/json' -d'{"index.translog.retention.age" : "30m"}'

5.设置索引副本:

curl -XPUT 'http://ip:port/my_index/_settings?pretty' -H 'Content-Type: application/json' -d'{"number_of_replicas" : 1}'

6.执行refresh,将内存数据刷新到磁盘缓存

curl -XPOST 'http://ip:port/myindex/_refresh'

7.执行flush,将磁盘缓存刷新到文件系统

curl -XPOST 'https://ip:port/myindex/_flush'

8.执行synced flush,生成syncid

curl -XPOST  'http://ip:port/_flush/synced'

9. 强制执行段合并

curl -XPOST 'http://ip:httpport/myindex/_forcemerge?only_expunge_deletes=false&max_num_segments=1&flush=true&pretty'

10.设置索引在每个esnode上的分片个数

curl -XPUT 'http://ip:httpport/myindex/_settings?pretty' -H 'Content-Type: application/json' -d'{"index.routing.allocation.total_shards_per_node" : "2"}'

11. 配置控制段合并的refresh、merge线程数等

curl -XPUT  "http://ip:port/my_index/_settings?pretty" -H 'Content-Type: application/json' -d'
{"refresh_interval": "60s",
 "merge":{"scheduler":{"max_merge_count" : "100",
                        "max_thread_count" : "1"},
          "policy":{"segments_per_tier" : "100",
                    "floor_segment" : "1m",
                    "max_merged_segment" : "2g"}
          }
}'

12.设置索引的刷新时间和translog配置参数

注意:设置translog参数,必须先关闭索引,设置完成后再打开

*代表设置所有索引,如果要设置具体某个索引,可以将*替换为具体的索引名称

curl -XPUT "http://ip:httpport/*/_settings" -H 'Content-Type: application/json' -d'
{ "index": 
          { "refresh_interval" : "60s",
            "translog": 
                      { "flush_threshold_size": "1GB", "sync_interval": "120s", "durability": "async" 
                      } 
          } 
}'

13.限制每个索引在每个实例上的分片个数

curl -XPUT  'http://ip:httpport/myindex/_settings?pretty' -H 'Content-Type:application/json' -d '{"index.routing.allocation.total_shards_per_node":"2"}'

实例检查常用命令

1.查看实例安装插件

curl -XGET "http://ip:port/_cat/aliases"

2.查询指定ES实例的jvm参数:

curl -XGET 'http://ip:port/_nodes/EsNode1*/stats/jvm?pretty'
curl -XGET 'http://ip:port/_nodes/EsNode1@12.40.16.156/stats/jvm?pretty'
作者 east
Elasticsearch 1月 31,2021

Elasticsearch规划及性能规格

影响因子分析

Elasticsearch组件的索引和查询性能主要受到物理资源(内存、磁盘、CPU、网络)和逻辑资源(数据类型、数据长度、分词类别)的影响。

物理资源

影响因子如:

  • 内存:内存大小会影响到写入数据的速度、缓存的多少。
  • 磁盘:磁盘的性能影响到索引数据写入磁盘的速度。
  • CPU:CPU的性能影响到分词的速度、处理倒排索引的速度等。
  • 网络:影响到分布式索引和查询消息处理的速度。

逻辑资源

影响因子如:

  • 数据类型:字符串、整型、浮点型,不同的数据类型对资源的消耗程度不同。
  • 数据长度:字段的大小对资源的消耗程度不同。
  • 分词类别:采用不同的分词器对资源的消耗程度不同。
  • shard个数划分:根据数据量的不同应当对index赋予不同的shard个数。

物理资源规划

频繁的请求下,Elasticsearch对内存、CPU、网络与磁盘的性能有较高的要求,一般情况下,建议Elasticsearch独占这些物理资源,尽量不与其他耗资源的组件合布。

磁盘使用必须使用SAS盘,不建议使用SATA盘进行存储。

内存配置

FusionInsight Elasticsearch单节点(node)默认分配的HeapSize为4GB,若机器内存的50%>实例数*31G,设置为31G,否则设置为机器内存的50%/实例数。资源允许的情况下,单个实例可以分配的最大HeapSize不要超过31GB。

另外,需要留下一半的物理内存作为Lucene缓存使用。如果不按照此建议设置,将会影响索引与查询的性能。

示例

  • 如果系统为128GB物理内存,那么建议留下64GB预留给Lucene缓存,剩下的64GB可以分配2个Elasticsearch节点(nodes)。每个节点分配31GB内存。
  • 如果系统为256GB物理内存,安装上面的计算实际上我们可以设置4个EsNode但是不建议安装4个。 说明: 256G及以上内存的机器只建议安装3个EsNode实例。虽然内存满足要求,但是由于受CPU核数的限制集群性能不会有太大提升。多余的内存Lucene也会全部利用了。

磁盘挂载

Elasticsearch单索引数据目前可以较优支持到TB级别,数据量庞大,建议Elasticsearch按照实例(nodes)进行单独挂盘。

示例

用户某个物理机上分配了两个Elasticsearch nodes,分别是EsNode1和EsNode2,一个实例对应写一个固定磁盘。需要为这两个实例挂载两个磁盘,挂载目录分别为“/srv/BigData/elasticsearch/esnode1/”和“/srv/BigData/elasticsearch/esnode2/”。

说明:

  • 磁盘类型不同,性能也相差巨大。如:SSD读写速度大约是SAS盘的50倍,而SAS盘读写速度可以达到SATA盘的2倍以上。
  • Elasticsearch的总实例数在500以上时,EsMaster必须使用SSD盘,且EsMaster可使用的CPU资源要大于等于32核。

shard个数规划

一个index可以被分为多个shards,从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。

每个分片都可以处理数据写入和查询请求,在设置索引分片数时,可从以下几个方面考虑:

  • 每个shard包含的数据条数越多,查询性能会降低(建议1亿条左右,最多建议不超过4亿)。
  • 建议单个分片保存的数据量在20GB左右,最大不超过30GB。
  • 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说,预计存储的数据量越大,应当分配的shard越多,分布式查询的优势越明显。如果确认某个index的数据量非常少(如一年不到1GB),那么过多的分配shard,反而可能不如单shard的性能好
  • 为了提升数据可靠性,合理设置副本分片个数,至少设置为1,如果集群的存储空间足够,推荐设置为2。
  • 每个node可以支撑的shards个数是有限的,node是物理资源分配的对象,随着shards中数据的增大,shards中的数据在查询时被不断加载到内存,达到一定量时,将会把HeapSize耗尽,导致频繁GC,系统将不能正常工作。推荐1GB内存管理15个shard,以一个Elasticsearch实例内存最大31G为例,单实例管理的shard数保持在500以内。
  • 当Elasticsearch集群实例数大于500时,请确保Elasticsearch集群的总shard数小于等于50000个。过多的shard数会导致EsMaster压力过大,Elasticsearch集群不稳定。

shard个数规划

一个index可以被分为多个shards,从而分布到不同的物理机上。Shard的划分结果也会影响索引和查询速度。

每个分片都可以处理数据写入和查询请求,在设置索引分片数时,可从以下几个方面考虑:

  • 每个shard包含的数据条数越多,查询性能会降低(建议1亿条左右,最多建议不超过4亿)。
  • 建议单个分片保存的数据量在20GB左右,最大不超过30GB。
  • 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说,预计存储的数据量越大,应当分配的shard越多,分布式查询的优势越明显。如果确认某个index的数据量非常少(如一年不到1GB),那么过多的分配shard,反而可能不如单shard的性能好
  • 为了提升数据可靠性,合理设置副本分片个数,至少设置为1,如果集群的存储空间足够,推荐设置为2。
  • 每个node可以支撑的shards个数是有限的,node是物理资源分配的对象,随着shards中数据的增大,shards中的数据在查询时被不断加载到内存,达到一定量时,将会把HeapSize耗尽,导致频繁GC,系统将不能正常工作。推荐1GB内存管理15个shard,以一个Elasticsearch实例内存最大31G为例,单实例管理的shard数保持在500以内。
  • 当Elasticsearch集群实例数大于500时,请确保Elasticsearch集群的总shard数小于等于50000个。过多的shard数会导致EsMaster压力过大,Elasticsearch集群不稳定。
作者 east
Elasticsearch 8月 31,2020

Elsticsearch 数据查询流程

Elasticsearch在存储数据的时候默认是根据每条记录的_id字段做路由分发的,这意味着es服务端是准确知道每个document分布在那个shard上的。

相对比于CURD上操作,search一个比较复杂的执行模式,因为我们不知道那些document会被匹配到,任何一个shard上都有可能,所以一个search请求必须查询一个索引或多个索引里面的所有shard才能完整的查询到我们想要的结果。

找到所有匹配的结果是查询的第一步,来自多个shard上的数据集在分页返回到客户端的之前会被合并到一个排序后的list列表,由于需要经过一步取top N的操作,所以search需要进过两个阶段才能完成,分别是query和fetch。

如下图所示:

(一)query(查询阶段)

当一个search请求发出的时候,这个query会被广播到索引里面的每一个shard(主shard或副本shard),每个shard会在本地执行查询请求后会生成一个命中文档的优先级队列。

这个队列是一个排序好的top N数据的列表,它的size等于from+size的和,也就是说如果你的from是10,size是10,那么这个队列的size就是20,所以这也是为什么深度分页不能用from+size这种方式,因为from越大,性能就越低。

es里面分布式search的查询流程如下:

1,客户端发送一个search请求到Node 3上,然后Node 3会创建一个优先级队列它的大小=from+size

2,接着Node 3转发这个search请求到索引里面每一个主shard或者副本shard上,每个shard会在本地查询然后添加结果到本地的排序好的优先级队列里面。

3,每个shard返回docId和所有参与排序字段的值例如_score到优先级队列里面,然后再返回给coordinating节点也就是Node 3,然后Node 3负责将所有shard里面的数据给合并到一个全局的排序的列表。

上面提到一个术语叫coordinating node,这个节点是当search请求随机负载的发送到一个节点上,然后这个节点就会成为一个coordinating node,它的职责是广播search请求到所有相关的shard上,然后合并他们的响应结果到一个全局的排序列表中然后进行第二个fetch阶段,注意这个结果集仅仅包含docId和所有排序的字段值,search请求可以被主shard或者副本shard处理,这也是为什么我们说增加副本的个数就能增加搜索吞吐量的原因,coordinating节点将会通过round-robin的方式自动负载均衡。

(二)fetch(读取阶段)

query阶段标识了那些文档满足了该次的search请求,但是我们仍然需要检索回document整条数据,这个阶段称为fetch。

流程如下:

1,coordinating 节点标识了那些document需要被拉取出来,并发送一个批量的mutil get请求到相关的shard上。

2,每个shard加载相关document,如果需要他们将会被返回到coordinating 节点上。

3,一旦所有的document被拉取回来,coordinating节点将会返回结果集到客户端上。

作者 east
Elasticsearch 8月 31,2020

Elsticsearch 数据写入流程

前言

由于Elasticsearch使用Lucene来处理shard级别的索引和查询,因此数据目录中的文件由Elasticsearch和Lucene共同编写。

Lucene负责编写和维护Lucene索引文件,而Elasticsearch在Lucene之上编写与功能相关的元数据,例如字段映射,索引设置和其他集群元数据,用户和支持功能由Elasticsearch提供。

ES数据

Node Data

只需启动ES就会有生成下面的目录树:

node.lock:为了确保一次只有一个ES应用从这个数据目录读取/写入。

global-0.st:global-prefix表示这是一个全局状态的文件,而.st扩展名表示这是一个包含元数据状态的文件。这个二进制文件是包含集群的全局元数据,前缀后的数字表示集群元数据版本,这是一个严格增加的版本控制方案。版本号跟随集群而变。

不要去编辑这些文件,因为有可能会导致数据丢失。

Index Data

当我们创建index,文件目录发生变化:

此时可以看出,已经创建了与索引名称对应的新目录。目录有两类子文件夹:_state和0.。

_state包含state-{version}.st索引状态文件,包含了索引的元数据,例如:创建的时间戳。还包含唯一标识符以及索引的settings和mappings。

数字0表示的shard编号,这个文件夹包含了shard相关的数据。

Shard Data

_state目录包含shard的状态文件,其中包含版本控制以及有关分片是主分片还是副本的信息。

index目录包含Lucene拥有的文件。ES通常不直接写入此文件夹。这些文件构成了ES数据目录的大小。

translog:ES事物日志。ES事物日志确保数据可以安全的写入到索引中,而无需为每个文档执行Lucene commit。提交Lucene index会产生一个新的segment,即fsync()-ed,会导致大量的磁盘I/O,从而影响性能。

Lucene数据

Lucene文件如下表所示:

Name Extension Brief Description
Segemnts File segments_N 存储lucene数据文件的元信息,记录所有segment的元数据信息。主要记录了当前有多少个segment,每个segment有一些基本信息,更新这些信息能定位到每个segment的元信息文件。
Lock File write.lock 防止多个IndexWriters写入同一个文件
Segement Info .si 存储有关段的元数据
Compound File .cfs,.cfe 一个segment包含了如下表的各个文件,为减少打开文件的数量,在segment小的时候,segment的所有文件内容都保存在cfs文件中,cfe文件保存了lucene各文件在cfs文件的位置信息
Fields .fnm 存储fileds的相关信息
Fields Index .fdx 正排存储文件的元数据信息
Fields Data .fdt 存储了正排存储数据,写入的原文存储在这
Term Dictionary .tim 倒排索引的元数据信息
Term Index .tip 倒排索引文件,存储了所有的倒排索引数据
Frequencies .doc 保存了每个term的doc id列表和term在doc中位置
Positions .pos 全文索引的字段,会有该文件,保存了term在doc中的位置
Playloads .pay Stores additional per-position metadata information such as character offsets and user payloads全文索引的字段,使用了一些像payloads的高级特性会有该文件,保存了term在doc中的一些高级特性
Norms .nvd,.nvm 存储索引字段加权数据
Per-Document Values .dvd,.dvm Lucene的docvalues文件,即列式存储,用作聚合和排序
Term Vector Data .tvx,.tvd,.tvf 保存索引字段的矢量信息,用在对term进行高亮,计算文本相关性中使用
Live Documents .liv 记录了segment中删除的doc

数据写入流程

1.segment file: 存储倒排索引的文件,每个segment本质上就是一个倒排索引,每秒都会生成一个segment文件,当文件过多时es会自动进行segment merge(合并文件),合并时会同时将已经标注删除的文档物理删除;

2.commit point(重点理解): 记录当前所有可用的segment,每个commit point都会维护一个.del文件(es删除数据本质是不属于物理删除),当es做删改操作时首先会在.del文件中声明某个document已经被删除,文件内记录了在某个segment内某个文档已经被删除,当查询请求过来时在segment中被删除的文件是能够查出来的,但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉;

3.translog日志文件: 为了防止elasticsearch宕机造成数据丢失保证可靠存储,es会将每次写入数据同时写到translog日志中。

translog的写入也可以设置,默认是request,每次请求都会写入磁盘(fsync),这样就保证所有数据不会丢,但写入性能会受影响;如果改成async,则按照配置触发trangslog写入磁盘,注意这里说的只是trangslog本身的写盘。

4. flush:translog什么时候清空?默认是512mb,或30分钟。这个动作就是flush,同时伴随着segment提交(写入磁盘)。flush之后,这段translog的使命就完成了,因为segment已经写入磁盘,就算故障,也可以从segment文件恢复。

5.fsync:另外,有一个/_flush/sync命令,在做数据节点维护时很有用。其逻辑就是flush translog并且将sync_id同步到各个分片。可以实现快速恢复。

综述:fsync指的是translog本身被写入磁盘的动作;flush指的是逻辑上的刷新,包含一系列逻辑操作。

其实flush API的作用是强制停止translog的fsync行为,提交segment并清除translog。间隔要尽量大一点(需要优化写速度的话,就稍微调大一点flush间隔。)

作者 east
Elasticsearch 8月 31,2020

Elasticsearch写入性能调优

bulk批量写入

如果业务场景支持将一批数据聚合起来,一次性写入Elasticsarch,那么尽量采用bulk的方式,bulk批量写入的速度远高于一条一条写入大量document的速度。

并不是bulk size越大越好,而是根据写入数据量具体来定的,因为越大的bulk size会导致内存压力过大,因此最好一个请求不要发送超过10MB的数据量,以5-10MB为最佳值。计算公式为:

一次bulk写入的数据量大小=一次bulk批量写入的文档数*每条数据量的大小。

多线程写入

单线程发送bulk请求是无法最大化Elasticsearch集群写入的吞吐量的。如果要利用集群的所有资源,就需要使用多线程并发将数据bulk写入集群中。多线程并发写入同时可以减少每次底层磁盘fsync的次数和开销。

一旦发现ES返回了TOO_MANY_REQUESTS的错误,JavaClient也就是EsRejectedExecutionException。此时说明Elasticsearch已经达到了一个并发写入的最大瓶颈了。

推荐使用CPU核数的2倍线程数。

修改索引刷新时间及副本数

默认“index.refresh_interval”为“1s”,即每秒都会强制生成1个新的segments文件,增大索引刷新时间,可以生成更大的segments文件,有效降低IO并减少segments merge的压力,该配置项可以建索引时指定(或者配置到template里去)。

如果只是单纯导入数据,不需要做实时查询,可以把refresh禁用(即设置index.refresh_interval为-1),并设置“index.number_of_replicas”为“0”,当然这样设置会有数据丢失风险。等到数据完成导入后,再把参数设置为合适的值。

命令为单索引下操作如下所示,同时也支持多索引(索引名按逗号分隔)和全索引(用*通配符)操作。

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex/_settings" -H 'Content-Type: application/json' -d'
{
    "number_of_replicas": 0,
    "refresh_interval": "180s"
}'

修改事务日志translog参数

默认设置下,translog 的持久化策略是每个请求都flush(durability参数值为request),这样能保证写操作的可靠性,但是对性能会有很严重的影响,实际测试发现如果使用默认设置进行导数据磁盘IO会持续占满。如果系统可以接受一定几率的数据丢失(或有手段补录丢失数据),可以通过调整 translog 持久化策略、周期性和一定大小的时候 flush,能大大提升导入性能。该配置项可以建索引时指定(或者配置到template里去)。执行命令如下所示:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex/_settings" -H 'Content-Type: application/json' -d'
{
"index": {
    "translog": {
          "flush_threshold_size": "1GB",
          "sync_interval": "180s",
          "durability": "async"
          }
     }
}'

备注:数据丢失风险

参数描述清楚

修改merge参数以及线程数

Elasticsearch写入数据时,refresh刷新会生成1个新的segment,segments会按照一定的策略进行索引段合并merge。merge的频率对写入和查询的速度都有一定的影响,如果merge频率比较快,会占用较多的IO,影响写入的速度,但同时segment个数也会比较少,可以提高查询速度。所以merge频率的设定需要根据具体业务去权衡,同时保证写入和查询都相对快速。Elasticsearch默认使用TieredMergePolicy,可以通过参数去控制索引段合并merge的频率:

  1. 参数“index.merge.policy.floor_segment”,Elasticsearch避免产生很小的segment,小于这个阀值的所有的非常小的segment都会merge直到达到这个floor的size,默认是2MB。
  2. 参数“index.merge.policy.max_merge_at_once”,一次最多只merge多少个segments,默认是10。
  3. 参数“index.merge.policy.max_merged_segment”,超过多大size的segment不会再做merge,默认是5g。
  4. 参数“index.merge.policy.segment_per_tier”默认为10,表示每个tier允许的segment个数,注意这个值要大于等于“index.merge.policy.max_merge_at_once”值,否则这个值会先于最大可操作数到达,就会立刻做merge,这样会造成频繁merge。
  5. 参数“ index.merge.scheduler.max_thread_count ”,单个shard上可能同时合并的最大线程数。默认会启动 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2)) 个线程进行merge操作,适用于SSD固态硬盘。但是如果硬盘是机械硬盘,很容易出现IO阻塞,将线程数设置为1。

一般情况下,通过调节参数“index.merge.policy.max_merge_at_once”和“index.merge.policy.segment_per_tier”去控制merge的频率。

参数修改 好处 坏处
提高“index.merge.policy.max_merge_at_once” 和“index.merge.policy.segment_per_tier”参数值(eg :50) 提升indexing速度 减少了segment merge动作的发生,意味着更多的segments,会降低searching速度
降低“index.merge.policy.max_merge_at_once” 和“index.merge.policy.segment_per_tier”参数值(eg :5) Segments更少,即能够提升searching速度 更多的segments merge操作,会花费更多系统资源(CPU/IO/RAM),会降低indexing速度

修改参数命令如下示例:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "https://ip:httpport/myindex-001/_settings?pretty" -H 'Content-Type: application/json' -d' {      "merge":{          "scheduler":{             "max_thread_count" : "1"          },          "policy":{               "segments_per_tier" : "20",               "max_merge_at_once": "20",               "floor_segment" : "2m",               "max_merged_segment" : "5g"          }       } }'


禁用Doc Values

禁用Doc Values

默认情况下,支持doc values 的所有字段都是开启的。因为 Doc Values 默认启用,可以选择对数据集里面的大多数字段进行聚合和排序操作。但是如果确定不需要在字段上进行排序和聚合,或从脚本中访问字段值,则可以禁用 doc values 来节省磁盘空间。

要禁用 Doc Values ,在字段的映射(mapping)设置 “doc_values”为“false”即可。例如,这里我们创建了一个新的索引,字段 “session_id” 禁用了 Doc Values:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : "http://ip:httpport/myindex" -H 'Content-Type: application/json' -d'
{
"mappings": {
      "my_type": {
           "properties": {
                 "session_id": {
                         "type": "keyword",
                         "doc_values": false
                  }
            }
       }
    }
}'

禁用_source字段

“_source”字段包含在索引时传递的原始JSON文档正文。该“_source”字段本身不被索引(因此是不可搜索的),但它被存储,以便在执行撷取请求时可以返回,例如get或search。

虽然很方便,但是“_source”字段确实在索引中有不小的存储开销。因此,可以使用如下方式禁用:

curl -XPUT --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/tweets?pretty' -H 'Content-Type: application/json' -d'
{
   "mappings": {
          "tweet": {
               "_source": {
                       "enabled": false
                 }
           }
     }
}'

说明: 在禁用_source 字段之前请注意:如果_source字段不可用,则不支持以下功能:

  • update,update_by_query,reindex APIs.
  • 高亮
  • 将索引从一个Elasticsearch索引reindex(重索引)到另一个索引的能力,以便更改映射或分析,或将索引升级到新的主要版本。
  • 通过查看索引时使用的原始文档来调试查询或聚合的能力。
  • 潜在的未来可能会自动修复索引损坏的能力。
作者 east

1 2 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (43)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (488)
    • CDH (6)
    • datax (4)
    • doris (30)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (40)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (99)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (70)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (6)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.