Elasticsearch搜索调优权威指南 (1/3)

  • 时间:
  • 浏览:0
  • 来源:uu快3开奖_uu快3娱乐_输钱

不可能 时要索引对象数组,并维护数组中每个对象的依赖关系,应当使用内嵌数据类型而全部都是对象数据类型。内嵌对象在内部人员会把数组中的每个对象当作单独的隐藏文档来索引,即使用下述内嵌查询,还可以单独查询每个内嵌对象:

索引决策也一阵一阵要,它对怎么才能 才能 搜索数据有很大的影响。不可能 是一有1个多字符串字段,是是是否是是时要分词或归一化?不可能 是,为何做?不可能 是一有1个多数值型属性,时要哪种精度?还有也不 这人类型,比如date-time、geospatial shape以及父子关系等,时要更多一阵一阵的考虑。

对于运行中Elasticsearch,内存是时要密切监控的重要资源之一。Elasticsearch和Lucene通过JVM堆内存和文件系统缓存并全部都是方式 来消耗内存。不可能 Elasticsearch运行在Java虚拟机(JVM)中,也不 JVM的GC周期和频率也时要重点监控。

目录

我希望不可能 时要把主文档和其关联实体分离,这人 分离由父子关系来提供。

Elasticsearch依靠GC过程来释放堆内存。不可能 GC并全部都是也要消耗资源(为了释放资源!),也不 应当留意GC频率和持续时间,以确认是是是否是是时要调整堆内存大小。设置过大的堆内存,换来的是更长的GC时间;这人 越多的停顿非常危险,不可能 不可能 导致 集群误认为该节点网络异常而失联。

内嵌对象模型的缺点如下:

Elasticsearch搜索调优权威指南,是QBOX在其博客上发布的系列文章之一,本文是该系列的第一篇,主要从文档建模、内存分配、文件系统缓存、GC和硬件等方面介绍了优化查询性能的这人经验。

全局序列号默认是 延迟 构建:refresh后的第一有1个多父子查询或聚合请求不可能 触发构建全局序列号。这会让用户感知到一有1个多明显的潜在峰值。还可以使用eager_global_ordinals 来把查询期构建全局序列号的成本转移到refresh期,通过如下方式 mapping _parent属性:

使用变慢的硬件

设置JVM堆大小的另并全部都是方式 (共要设置一样的最小值和最大值,以正确处理重新调整堆大小),是在每次启动Elasticsearch时通过命令行参数指定:

对于也不 的父代,全局序列号共要数秒钟来构建。此时,时要增加refresh_interval,以便refresh的频率更低,而全局序列号保持可用的时间更长。这将大幅减少每秒钟重建全局序列号的CPU消耗。

为Elasticsearch分配过少的堆内存,只能 就会留给Lucene更多内存,而Lucene重度依赖于文件系统缓存来快速正确处理请求。不管怎么才能 才能 也不 我能设置过小的堆内存,不可能 当应用不可能 频繁GC而面临短时中断时,不可能 会遭遇内存溢出错误或吞吐量下降。

通过建立另一有1个文档的父类型mapping,还可以在相同索引的文档之间建立父子关系:

JVM堆内存

这里,_parent属性的全局序列号不可能 在一有1个多新的段搜索可见时被构建。

搜索请求返回整个文档,而全部都是只返回匹配的内嵌文档。随便说说 不可能 日后计划支持返回根文档的部分最配内嵌文档,但目前仍然不支持。

父子join对管理实体关系非常有用,尤其是在索引时间比检索时间一阵一阵要的情况下,我希望它会带来较大的开销;父子查询比同等的内嵌查询要慢5到10倍。

英文原文:https://qbox.io/blog/elasticsearch-search-tuning-5-0-ultimate-guide

作者:Adam Vanderbush

译者:杨振涛

对于Elasticsearch一有1个多“刚好共要”的JVM堆大小是非常重要的——只能设置过大或过小,导致 见后文。一般来说Elasticsearch的经验值是分配少于3000%的可用RAM给JVM堆,且越多超过32GB。

返回的输出会显示已正确地更新了最大堆内存。

我希望,Elasticsearch重度依赖文件系统缓存来加速搜索。一般时要保证共要有一半的可用内存用于文件系统缓存,另一有1个Elasticsearch不能保持索引数据的热点区域全部都是物理内存中。

这并全部都是示例方式 全部都是设置了10GB的堆大小,为了验证是是是否是是设置成功,执行:

对多代数据的Join(参考Grandparents and Grandchildren)能力听起来很吸引人,但时要思考其代价:

亲戚亲戚让我们都都 歌词 不可能 通过“Elasticsearch性能调优权威指南”系列,介绍了这人性能调优的基本经验和方式 ,解释了每一步最关键的系统设置和衡量指标。该系列共分下列五个部分:

分片中的父代越多,全局序列号构建就越耗时。相对于时要父代和较少的子代, 父子关系最适合每个父代有也不 子代的情况。

亲戚亲戚让我们都都 歌词 也通过一有1个多系列教程讨论了“Elasticsearch索引性能优化”,介绍了这人通用的技巧和方式 ,来最大化索引的吞吐量并降低监控和管理的负载。该教程分如下五个部分:

Elasticsearch默认安装时设置的JVM堆大小为1GB,这在大多数情况下都偏小。还可以通过环境变量来设置期望的对大小并重启Elasticsearch:

本文旨在推荐这人搜索调优技术、策略以及Elasticsearch 5.0及以上的推荐行态。

这人 版本的Elasticsearch是目前为止最快、最安全、最弹性,也是最易用的,我希望还带来了也不 的改进和新行态。

当一有1个多多主实体比如一篇博客文章,包含这人有一定关系但又全部都是非常重要的这人实体比如评论时,内嵌对象会非常有用。不可能 能根据评论内容来查询到博客文章,那就很不错,我希望内嵌查询和过滤器同时提供了变慢的join查询能力。

Elasticsearch 5.0.0随便说说 是在2.x日后的一有1个多大版本,为亲戚亲戚让我们都都 歌词 带来了这人新东西。Elasticsearch现在作为Elastic Stack中的一员,与整个技术栈的这人产品的版本号不可能 对齐,现在Kibana、Logstash、Beats和Elasticsearch全全部都是5.0版本了。

该请求会在内部人员转换为如下的文档形式:

垃圾回收

父子关系使用了全局序列号来加速join操作。无论父子map是是是否是是使用了内存缓存或磁盘上的doc value,全局序列号仍然时要在索引占据 任何改变时进行重建。

不可能 搜索受限于CPU,只能 应当考虑购买变慢的CPU。

Elasticsearch使用虚拟化存储工作是只能 什么的问题的,它不可能 快速和安装简单而受欢迎,但同样不幸的是,在基础上与专用的本地存储相比它天生就很难。不可能 在EBS上创建了一有1个多索引库,请确认使用预分配的IOPS,我希望变慢就会被限流。

内部人员对象属性数组越多像期望的那样工作。Lucene 中只能 内部人员对象的概念,也不 Elasticsearch把对象层次展开到一有1个多由属性名称和属性值组成的简单列表中。以下列文档为例:

不可能 搜索受限于I/O,应当考虑为文件系统缓存分片更多内存(参考前文),不可能 购买变慢的驱动。一阵一阵地,SSD公认地比机械磁盘性能好也不 。尽不可能 使用本地存储,正确处理使用像 NFS 或 SMB 例如 的远程或网络文件系统,也要注意像Amazon EBS另一有1个的虚拟化存储。

为了 增加 、修改 或 删除 一有1个多内嵌对象文档,整个文档时要重建索引;这就导致 内嵌文档越多开销就越大。