做名片制作网站有什么,新闻采编与制作专业简历,设计公司啊 网站,百度推广收费标准在我之前的文章 “Elasticsearch#xff1a;如何提高查询性能” 及 “Elasticsearch#xff1a;提升 Elasticsearch 性能” 里#xff0c;我详细描述了如何提高搜索的性能。在今天的文章里#xff0c;我从另外一个视角来描述如何调整搜索的速度。希望对大家有所帮助#x… 在我之前的文章 “Elasticsearch如何提高查询性能” 及 “Elasticsearch提升 Elasticsearch 性能” 里我详细描述了如何提高搜索的性能。在今天的文章里我从另外一个视角来描述如何调整搜索的速度。希望对大家有所帮助 为文件系统缓存提供内存 Elasticsearch 严重依赖文件系统缓存来提高搜索速度。 一般来说你应该确保至少一半的可用内存用于文件系统缓存以便 Elasticsearch 可以将索引的热区域保留在物理内存中。 在 Linux 上使用适度的预读值来避免页面缓存抖动 搜索可能会导致大量随机读取 I/O。 当底层块设备具有较高的预读值时可能会执行大量不必要的读取 I/O特别是当使用内存映射访问文件时请参阅存储类型。 大多数 Linux 发行版对单个普通设备使用 128KiB 的合理预读值但是当使用软件 raid、LVM 或 dm-crypt 时生成的块设备支持 Elasticsearch path.data最终可能会具有非常大的预读值在 几个 MiB 的范围。 这通常会导致严重的页面文件系统缓存抖动从而对搜索或更新性能产生不利影响。 你可以使用 lsblk -o NAME,RA,MOUNTPOINT,TYPE,SIZE 检查当前值以 KiB 为单位。 有关如何更改此值的信息请参阅发行版的文档例如使用 udev 规则在重新启动后保持不变或通过 blockdev --setra 作为瞬态设置。 我们建议预读值为 128KiB。 警告blockdev 期望值以 512 字节扇区为单位而 lsblk 报告值以 KiB 为单位。 例如要将 /dev/nvme0n1 的预读临时设置为 128KiB请指定 blockdev --setra 256 /dev/nvme0n1。 使用更快的硬件 如果你的搜索受 I/O 限制请考虑增加文件系统缓存的大小见上文或使用更快的存储。 每次搜索都涉及跨多个文件的顺序和随机读取的混合并且每个分片上可能同时运行许多搜索因此 SSD 驱动器的性能往往比旋转磁盘更好。 直连本地存储通常比远程存储性能更好因为它更易于配置并避免通信开销。 通过仔细调整有时使用远程存储也可以获得可接受的性能。 使用实际工作负载对你的系统进行基准测试以确定任何调整参数的效果。 如果你无法达到预期的性能请与存储系统的供应商合作找出问题。 如果你的搜索受 CPU 限制请考虑使用更多更快的 CPU。 文档建模 应该对文档进行建模以便尽可能减少搜索时间操作。 特别是应该避免 joins。 nested 可以使查询慢几倍而父子关系可以使查询慢数百倍。 因此如果可以通过非规范化文档来回答相同的问题而无需 joins则可以预期显着的加速。 搜索尽可能少的字段 query_string 或 multi_match 查询的目标字段越多速度就越慢。 提高多个字段搜索速度的常用技术是在索引时将它们的值复制到单个字段中然后在搜索时使用该字段。 这可以通过映射的 copy_to 指令来自动化而无需更改文档的源。 下面是一个包含电影的索引示例该索引通过将两个值索引到 name_and_plot 字段来优化搜索电影名称和情节的查询。 PUT movies {mappings: {properties: {name_and_plot: {type: text},name: {type: text,copy_to: name_and_plot},plot: {type: text,copy_to: name_and_plot}}} } 索引前数据 你应该利用查询中的模式来优化数据索引方式。 例如如果你的所有文档都有 price 字段并且大多数查询在固定的范围列表上运行 range 聚合则可以通过将range 预先索引到索引中并使用 terms 聚合来加快聚合速度。 例如如果文档如下所示 PUT index/_doc/1 {designation: spoon,price: 13 } 搜索请求如下所示 GET index/_search {aggs: {price_ranges: {range: {field: price,ranges: [{ to: 10 },{ from: 10, to: 100 },{ from: 100 }]}}} } 然后可以在索引时通过 price_range 字段来丰富文档该字段应该映射为 keyword PUT index {mappings: {properties: {price_range: {type: keyword}}} }PUT index/_doc/1 {designation: spoon,price: 13,price_range: 10-100 } 然后搜索请求可以聚合这个新字段而不是在 price 字段上运行 range 聚合。 GET index/_search {aggs: {price_ranges: {terms: {field: price_range}}} } 考虑将映射标识符作为关键字 并非所有数值数据都应映射为 numeric 字段数据类型。 Elasticsearch 优化 range 查询的数字字段例如 integer 或 long。 但是keyword 字段更适合 term 和其他term-level查询。 ISBN 或产品 ID 等标识符很少在 range 查询中使用。 然而它们通常是使用 term-level 级查询来检索的。 如果出现以下情况请考虑将数字标识符映射为 keyword 你不打算使用 range 查询来搜索标识符数据。快速检索很重要。 keyword 字段上的 term 查询搜索通常比数字字段上的术语搜索更快。 如果你不确定使用哪个可以使用 multi-field 将数据映射为 keyword 和数字数据类型。 避免脚本 如果可能请避免使用基于脚本的排序、聚合中的脚本和 script_score 查询。 请参阅 Scripts、caching 和 search speed。 搜索四舍五入的日期 对使用 now 的日期字段的查询通常不可缓存因为匹配的范围一直在变化。 然而就用户体验而言切换到四舍五入日期通常是可以接受的并且具有更好地利用查询缓存的好处。 例如下面的查询 PUT index/_doc/1 {my_date: 2016-05-11T16:30:55.328Z }GET index/_search {query: {constant_score: {filter: {range: {my_date: {gte: now-1h,lte: now}}}}} } 可以替换为以下查询 GET index/_search {query: {constant_score: {filter: {range: {my_date: {gte: now-1h/m,lte: now/m}}}}} } 在这种情况下我们四舍五入到分钟因此如果当前时间是 16:31:29范围查询将匹配 my_date 字段值在 15:31:00 和 16:31:59 之间的所有内容。 如果多个用户在同一分钟内运行包含此范围的查询则查询缓存可以帮助加快速度。 用于舍入的间隔越长查询缓存的帮助就越大但请注意过于激进的舍入也可能会损害用户体验。 注意为了能够利用查询缓存将范围分割为大的可缓存部分和较小的不可缓存部分可能很诱人如下所示 GET index/_search {query: {constant_score: {filter: {bool: {should: [{range: {my_date: {gte: now-1h,lte: now-1h/m}}},{range: {my_date: {gt: now-1h/m,lt: now/m}}},{range: {my_date: {gte: now/m,lte: now}}}]}}}} } 然而这种做法在某些情况下可能会使查询运行速度变慢因为 bool 查询引入的开销可能会抵消更好地利用查询缓存所节省的成本。 强制合并只读索引 只读索引可能会受益于合并到单个段。 基于时间的索引通常就是这种情况只有当前时间范围的索引正在获取新文档而旧索引是只读的。 已强制合并为单个分段的分片可以使用更简单、更高效的数据结构来执行搜索。 重要不要强制合并你仍在写入或将来将再次写入的索引。 相反依靠自动后台合并进程根据需要执行合并以保持索引平稳运行。 如果你继续写入强制合并索引那么它的性能可能会变得更糟。 热身全局序数 全局序数global ordinals是一种用于优化聚合性能的数据结构。 它们是惰性计算的并作为字段数据缓存的一部分存储在 JVM 堆中。 对于大量用于分桶聚合的字段你可以告诉 Elasticsearch 在收到请求之前构建并缓存全局序号。 应该谨慎执行此操作因为它会增加堆使用量并使刷新时间更长。 通过设置 eager global ordinals 映射参数可以在现有映射上动态更新该选项 PUT index {mappings: {properties: {foo: {type: keyword,eager_global_ordinals: true}}} } 预热文件系统缓存 如果运行 Elasticsearch 的机器重新启动文件系统缓存将为空因此操作系统需要一些时间才能将索引的热区域加载到内存中以便搜索操作快速。 你可以使用 index.store.preload 设置显式告诉操作系统哪些文件应根据文件扩展名立即加载到内存中。 警告如果文件系统缓存不够大无法容纳所有数据则在太多索引或太多文件上急切地将数据加载到文件系统缓存中将使搜索速度变慢。 谨慎使用。 使用索引排序来加速连词 索引排序index sorting很有用可以使连接 (conjunctions) 速度更快但代价是索引速度稍慢。 请在索引排序文档中相关信息。 使用 preference 项来优化缓存利用率 有多种缓存可以帮助提高搜索性能例如文件系统缓存、请求缓存或查询缓存。 然而所有这些缓存都是在节点级别维护的这意味着如果你连续两次运行相同的请求有 1 个或更多副本并使用默认路由算法 round-robin那么这两个请求将转到不同的分片副本 阻止节点级缓存发挥作用。 由于搜索应用程序的用户通常会相继运行类似的请求例如为了分析索引的较小子集因此使用标识当前用户或会话的 preference 项值可以帮助优化缓存的使用。 副本可能有助于提高吞吐量但并不总是如此 除了提高弹性之外副本还可以帮助提高吞吐量。 例如如果你有一个单分片索引和三个节点则需要将副本数设置为 2以便总共拥有 3 个分片以便利用所有节点。 现在假设你有一个 2 分片2-shard索引和两个节点。 在一种情况下副本数为 0这意味着每个节点拥有一个分片。 在第二种情况下副本数为 1这意味着每个节点有两个分片。 哪种设置在搜索性能方面表现最佳 通常每个节点总共具有较少分片的设置会表现更好。 原因是它为每个分片提供了更大份额的可用文件系统缓存并且文件系统缓存可能是 Elasticsearch 的第一大性能因素。 同时请注意如果单个节点发生故障没有副本的设置可能会失败因此在吞吐量和可用性之间需要进行权衡。 那么正确的副本数量是多少 如果您的集群总共有 num_nodes 个节点、num_primaries 个主分片并且你希望能够一次最多处理 max_failures 个节点故障那么适合你的副本数量是 max(max_failures, ceil(num_nodes / num_primaries) - 1). 使用搜索分析器调整你的查询 Profile API 提供有关查询和聚合的每个组件如何影响处理请求所需时间的详细信息。 Kibana 中的 Search Profiler 可以轻松导航和分析分析结果并让你深入了解如何调整查询以提高性能并减少负载。 由于 Profile API 本身会显着增加查询开销因此此信息最好用于了解各种查询组件的相对成本。 它不提供实际处理时间的可靠测量。 使用 index_phrases 加快短语查询速度 Text 字段有一个索引 2-shingles 的 index_phrases 选项并由查询解析器自动利用来运行没有倾斜的短语查询。 如果你的用例涉及运行大量短语查询这可以显着加快查询速度。 使用 constant_keyword 来加速过滤 一般规则是过滤器的成本主要是匹配文档数量的函数。 想象一下你有一个包含 cycles 的索引。 自行车 (bicycle) 数量很多许多搜索都会对 cycle_type: bycycle 进行过滤。 不幸的是这种非常常见的过滤器也非常昂贵因为它与大多数文档匹配。 有一种简单的方法可以避免运行此过滤器将 bycycles 移动到自己的索引并通过搜索此索引来过滤自行车而不是向查询添加过滤器。 不幸的是这可能会使客户端逻辑变得棘手而这正是 constant_keyword 可以发挥作用的地方。 通过将 cycle_type 映射为 constant_keyword并在包含 bicycles 的索引上使用值 bicycle客户端可以继续运行与在整体索引上运行完全相同的查询并且 Elasticsearch 将通过忽略 cycle_type 上的过滤器来对 bicycles 索引执行正确的操作如果该值是 bycycle否则不返回任何命中。 映射可能如下所示 PUT bicycles {mappings: {properties: {cycle_type: {type: constant_keyword,value: bicycle},name: {type: text}}} }PUT other_cycles {mappings: {properties: {cycle_type: {type: keyword},name: {type: text}}} } 我们将索引一分为二一个仅包含 bicycles另一个包含其他 cycles独轮车、三轮车等。然后在搜索时我们需要搜索这两个索引但不需要修改查询 。 GET bicycles,other_cycles/_search {query: {bool: {must: {match: {description: dutch}},filter: {term: {cycle_type: bicycle}}}} } 在 bicycles 索引上Elasticsearch 将简单地忽略 cycle_type 过滤器并将搜索请求重写为以下请求 GET bicycles,other_cycles/_search {query: {match: {description: dutch}} } 在 other_cycles 索引上Elasticsearch 会很快发现 cycle_type 字段的术语字典中不存在 bicycle 并返回没有命中的搜索响应。 通过将通用值放入专用索引中这是一种降低查询成本的强大方法。 这个想法也可以跨多个领域组合例如如果你跟踪每个自行车的颜色并且你的 bicycles 索引最终包含大多数黑色自行车你可以将其分为 bicycles-black 索引和 bicycles-other-colors 索引 。 此优化并不严格需要 constant_keyword还可以更新客户端逻辑以便根据过滤器将查询路由到相关索引。 然而constant_keyword 使其变得透明并允许将搜索请求与索引拓扑解耦以换取很少的开销。