使用 man ascii 来查看 ASCII 表。

Elastic日报 第1513期 (2022-10-17)

1. 携程搜索基于 CNN 的新词发现算法
   https://www.6aiq.com/article/1665662220461

2. kibana如何制作出好看酷炫的图表
   https://zhuanlan.zhihu.com/p/86703607

3. 百亿级实时计算系统性能优化–—Elasticsearch篇
   https://zhuanlan.zhihu.com/p/3 ... ao.io

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
继续阅读 »
1. 携程搜索基于 CNN 的新词发现算法
   https://www.6aiq.com/article/1665662220461

2. kibana如何制作出好看酷炫的图表
   https://zhuanlan.zhihu.com/p/86703607

3. 百亿级实时计算系统性能优化–—Elasticsearch篇
   https://zhuanlan.zhihu.com/p/3 ... ao.io

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili 收起阅读 »

Elastic日报 第1512期 (2022-10-13)

1.Elasticsearch杀手神器,让es操作更简单
https://mp.weixin.qq.com/s/oFHPhUzoittNyhIOJ8dm0Q
2.Elasticsearch LDAP 认证(需要梯子)
https://medium.com/%40surangaj ... fcdbf
3.使用 Elasticsearch 预测数据(需要梯子)
https://medium.com/%40surangaj ... 82a1a

编辑:Se7en   
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili
继续阅读 »
1.Elasticsearch杀手神器,让es操作更简单
https://mp.weixin.qq.com/s/oFHPhUzoittNyhIOJ8dm0Q
2.Elasticsearch LDAP 认证(需要梯子)
https://medium.com/%40surangaj ... fcdbf
3.使用 Elasticsearch 预测数据(需要梯子)
https://medium.com/%40surangaj ... 82a1a

编辑:Se7en   
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili 收起阅读 »

Elastic日报 第1511期 (2022-10-12)

1.Elasticsearch:运用 Pinned query 来提升特定的结果
https://blog.csdn.net/UbuntuTo ... 45555

2.Elasticsearch DSL 语法中 queries/filters 执行顺序探秘
https://www.6aiq.com/article/1597589414980

3.Elasticsearch常见的报错处理#yyds干货盘点#
https://blog.51cto.com/liqingbiao/4918018



编辑:kin122
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
继续阅读 »
1.Elasticsearch:运用 Pinned query 来提升特定的结果
https://blog.csdn.net/UbuntuTo ... 45555

2.Elasticsearch DSL 语法中 queries/filters 执行顺序探秘
https://www.6aiq.com/article/1597589414980

3.Elasticsearch常见的报错处理#yyds干货盘点#
https://blog.51cto.com/liqingbiao/4918018



编辑:kin122
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili 收起阅读 »

Elastic日报 第1510期 (2022-10-11)


1. 在k8s上搭企业级ELKB(需要梯子)
https://medium.com/%40siddhart ... 677bb
2. Es8 新功能,NER(需要梯子)
https://medium.com/%40psajan10 ... 6c5e8
3. 还在这样对待ES,他要哭了(需要梯子)
https://medium.com/trendyol-te ... 85746
编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili
 
继续阅读 »

1. 在k8s上搭企业级ELKB(需要梯子)
https://medium.com/%40siddhart ... 677bb
2. Es8 新功能,NER(需要梯子)
https://medium.com/%40psajan10 ... 6c5e8
3. 还在这样对待ES,他要哭了(需要梯子)
https://medium.com/trendyol-te ... 85746
编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili
  收起阅读 »

Elastic日报 第1509期 (2022-10-10)

1. 知识图谱在美团搜索酒旅场景认知中的应用
   https://www.6aiq.com/article/1664520291651

2. 详解闲鱼搜索系统
   https://www.6aiq.com/article/1664281210765

3. 探究 | kafka-connector 同步 Elasticsearch速度慢根因分析
   https://blog.csdn.net/laoyang3 ... 50717

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
继续阅读 »
1. 知识图谱在美团搜索酒旅场景认知中的应用
   https://www.6aiq.com/article/1664520291651

2. 详解闲鱼搜索系统
   https://www.6aiq.com/article/1664281210765

3. 探究 | kafka-connector 同步 Elasticsearch速度慢根因分析
   https://blog.csdn.net/laoyang3 ... 50717

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili 收起阅读 »

ES7.5升级7.17后在写多读少场景下CPU、IO飙升

背景

1.ES PAAS管理的集群升级了100+,从7.5升级到7.17 (保证每个大版本最终仅维护一个小版本集群)

2.由于业务使用差异大,也出了不少问题,前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障:“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了,IO也有明显抖动

1.png

2.png

排查与分析

1.发现YoungGC频率变高了一些,猜测可能是G1GC的问题(我们使用JDK11重新打了ES镜像),经过版本替换,没有明显变化。

参考issue:https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的case,经过测试,不属于我们的场景。

2.多次执行hot_threads API观察, 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据,发现是 FST、DocID 读取慢

3.png

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少,使用的是niofs。可知,7.5版本的FST是在堆外,但是_id字段是在堆内。升级到7.17版本后,FST在堆外,该字段也放到了堆外(官方版本应该是7.9就开始放到堆外了)。数据放到堆外,其实也就是文件放到磁盘,读一次之后放到pagecache。

这样也就可以解释了,在upsert类请求多的时候会频繁查询docId,此时如果_id字段没有进入pageCache或者被踢出pageCache,那么就会出现响应慢,并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内(开源版需要改造)

4.png

可以看到,CPU有显著下降,也相对均衡。(之前蓝色线高,是因为该节点有大量的主分片)

结论

1.update、upsert、get等请求如果十分频繁,_id使用offheap将不会是个好的选择,除非给足够的堆外内存,并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下,实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障,可能不会有这么明显的差距。(官方描述写入速度仅降低了1.8%)

4.最后吐槽一下,写入不停的情况下,translog的恢复实在是太慢了,由于大分片恢复/rebalance时,translog不会被清理,导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

继续阅读 »

背景

1.ES PAAS管理的集群升级了100+,从7.5升级到7.17 (保证每个大版本最终仅维护一个小版本集群)

2.由于业务使用差异大,也出了不少问题,前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障:“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了,IO也有明显抖动

1.png

2.png

排查与分析

1.发现YoungGC频率变高了一些,猜测可能是G1GC的问题(我们使用JDK11重新打了ES镜像),经过版本替换,没有明显变化。

参考issue:https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的case,经过测试,不属于我们的场景。

2.多次执行hot_threads API观察, 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据,发现是 FST、DocID 读取慢

3.png

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少,使用的是niofs。可知,7.5版本的FST是在堆外,但是_id字段是在堆内。升级到7.17版本后,FST在堆外,该字段也放到了堆外(官方版本应该是7.9就开始放到堆外了)。数据放到堆外,其实也就是文件放到磁盘,读一次之后放到pagecache。

这样也就可以解释了,在upsert类请求多的时候会频繁查询docId,此时如果_id字段没有进入pageCache或者被踢出pageCache,那么就会出现响应慢,并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内(开源版需要改造)

4.png

可以看到,CPU有显著下降,也相对均衡。(之前蓝色线高,是因为该节点有大量的主分片)

结论

1.update、upsert、get等请求如果十分频繁,_id使用offheap将不会是个好的选择,除非给足够的堆外内存,并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下,实测是什么情况暂时不明确,目前没有收到搜索类集群CPU、IO方面的报障,可能不会有这么明显的差距。(官方描述写入速度仅降低了1.8%)

4.最后吐槽一下,写入不停的情况下,translog的恢复实在是太慢了,由于大分片恢复/rebalance时,translog不会被清理,导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

收起阅读 »

Elasticsearch:Hadoop 大数据集成 (Hadoop => Elasticsearch)

在本文章中,我们将学习如何使用 Elasticsearch Hadoop 处理大量数据。 对于我们的练习,我们将使用一个简单的 Apache access 日志来表示我们的 “大数据”。 我们将学习如何编写 MapReduce 作业以使用 Hadoop 摄取文件并将其索引到 Elasticsearch 中。在我们今天的练习中,我们将使用如下的架构来搭建我们的系统:

hadoop1.png


hadoop.png

 
如上所示,我们在左边的 macOS 中安装 Elasticsearch 及 Kibana,而在 Ubuntu OS 中安装 Hadoop。我们将以最新的 Elastic Stack 8.4.2 来进行展示。

Hadoop 是什么?

当我们需要收集、处理/转换和/或存储数千 GB、数千 TB 甚至更多的数据时,Hadoop 可能是完成这项工作的合适工具。它是从头开始构建的,考虑到这样的想法:
  • 一次使用多台计算机(形成一个集群),以便它可以并行处理数据,从而更快地完成工作。我们可以这样想。如果一台服务器需要处理 100 TB 的数据,它可能会在 500 小时内完成。但是如果我们有 100 台服务器,每台只能取一部分数据,例如 server1 可以取第一个 TB,server2 可以取第二个 TB,以此类推。现在他们每个人都只有 1 TB 的数据要处理,而且他们都可以同时处理自己的数据部分。这样,工作可以在 5 小时内完成,而不是 500 小时。当然,这是理论上的和想象的,因为在实践中我们不会减少 100 倍所需的时间,但我们可以非常接近如果条件理想。
  • 在需要时可以很容易地调整计算能力。有更多的数据要处理,而问题要复杂得多?将更多计算机添加到集群。从某种意义上说,这就像在超级计算机上增加了更多的 CPU 内核。
  • 数据不断增长,因此 Hadoop 也必须能够轻松灵活地扩展其存储容量,以满足需求。我们添加到集群的每台计算机都会扩展 Hadoop 分布式文件系统 (HDFS) 的可用总存储空间。
  • 与其他软件不同,它不仅会在硬件故障发生时尝试从硬件故障中恢复。设计理念实际上假设某些硬件肯定会失败。当有数千台计算机并行工作时,可以保证某处某处会不时出现故障。因此,默认情况下,Hadoop 创建数据块的副本并将它们分布在单独的硬件上,因此当偶尔的服务器起火或硬盘或 SSD 死机时,不会丢失任何内容。

总而言之,Hadoop 非常擅长摄取和处理大量信息。它将数据分布在集群中可用的多个节点上,并使用 MapReduce 编程模型在多台机器上同时处理数据(并行处理)。

但这听起来可能有点类似于 Elasticsearch 数据摄取工具所做的事情。尽管它们是为处理相当不同的场景而设计的,但它们有时可能会有些重叠。那么我们为什么以及何时使用其中一个而不是另一个呢?

Hadoop vs Logstash/Elasticsearch

首先,我们不应该考虑哪个比哪个更好。 每个人都擅长为其创造的工作。 每个都有优点和缺点。

为了尝试给你绘制一个图片并让你了解我们何时使用其中一个,让我们考虑以下场景:
  • 当我们需要从数十亿个网站中提取数据时,就像谷歌这样的搜索引擎所做的那样,我们会发现像 Elasticsearch 及 Hadoop 这样的工具非常有用和高效。
  • 当我们需要以这样一种方式存储数据并对其进行索引以便以后可以快速有效地搜索时,我们会发现像 Elasticsearch 这样的东西非常有用。
  • 最后,当我们想要收集实时数据时,例如来自互联网上许多交易所的美元/欧元价格,我们会发现像 Logstash 这样的工具非常适合这项工作。

 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 97392
继续阅读 »
在本文章中,我们将学习如何使用 Elasticsearch Hadoop 处理大量数据。 对于我们的练习,我们将使用一个简单的 Apache access 日志来表示我们的 “大数据”。 我们将学习如何编写 MapReduce 作业以使用 Hadoop 摄取文件并将其索引到 Elasticsearch 中。在我们今天的练习中,我们将使用如下的架构来搭建我们的系统:

hadoop1.png


hadoop.png

 
如上所示,我们在左边的 macOS 中安装 Elasticsearch 及 Kibana,而在 Ubuntu OS 中安装 Hadoop。我们将以最新的 Elastic Stack 8.4.2 来进行展示。

Hadoop 是什么?

当我们需要收集、处理/转换和/或存储数千 GB、数千 TB 甚至更多的数据时,Hadoop 可能是完成这项工作的合适工具。它是从头开始构建的,考虑到这样的想法:
  • 一次使用多台计算机(形成一个集群),以便它可以并行处理数据,从而更快地完成工作。我们可以这样想。如果一台服务器需要处理 100 TB 的数据,它可能会在 500 小时内完成。但是如果我们有 100 台服务器,每台只能取一部分数据,例如 server1 可以取第一个 TB,server2 可以取第二个 TB,以此类推。现在他们每个人都只有 1 TB 的数据要处理,而且他们都可以同时处理自己的数据部分。这样,工作可以在 5 小时内完成,而不是 500 小时。当然,这是理论上的和想象的,因为在实践中我们不会减少 100 倍所需的时间,但我们可以非常接近如果条件理想。
  • 在需要时可以很容易地调整计算能力。有更多的数据要处理,而问题要复杂得多?将更多计算机添加到集群。从某种意义上说,这就像在超级计算机上增加了更多的 CPU 内核。
  • 数据不断增长,因此 Hadoop 也必须能够轻松灵活地扩展其存储容量,以满足需求。我们添加到集群的每台计算机都会扩展 Hadoop 分布式文件系统 (HDFS) 的可用总存储空间。
  • 与其他软件不同,它不仅会在硬件故障发生时尝试从硬件故障中恢复。设计理念实际上假设某些硬件肯定会失败。当有数千台计算机并行工作时,可以保证某处某处会不时出现故障。因此,默认情况下,Hadoop 创建数据块的副本并将它们分布在单独的硬件上,因此当偶尔的服务器起火或硬盘或 SSD 死机时,不会丢失任何内容。

总而言之,Hadoop 非常擅长摄取和处理大量信息。它将数据分布在集群中可用的多个节点上,并使用 MapReduce 编程模型在多台机器上同时处理数据(并行处理)。

但这听起来可能有点类似于 Elasticsearch 数据摄取工具所做的事情。尽管它们是为处理相当不同的场景而设计的,但它们有时可能会有些重叠。那么我们为什么以及何时使用其中一个而不是另一个呢?

Hadoop vs Logstash/Elasticsearch

首先,我们不应该考虑哪个比哪个更好。 每个人都擅长为其创造的工作。 每个都有优点和缺点。

为了尝试给你绘制一个图片并让你了解我们何时使用其中一个,让我们考虑以下场景:
  • 当我们需要从数十亿个网站中提取数据时,就像谷歌这样的搜索引擎所做的那样,我们会发现像 Elasticsearch 及 Hadoop 这样的工具非常有用和高效。
  • 当我们需要以这样一种方式存储数据并对其进行索引以便以后可以快速有效地搜索时,我们会发现像 Elasticsearch 这样的东西非常有用。
  • 最后,当我们想要收集实时数据时,例如来自互联网上许多交易所的美元/欧元价格,我们会发现像 Logstash 这样的工具非常适合这项工作。

 
更多阅读,请参阅 https://elasticstack.blog.csdn ... 97392 收起阅读 »

【重启通知】 2022 Elastic 中国开发者大会定于2022年10月29日,深圳好日子皇冠假日酒店,不见不散!

banner_guide.png

亲爱的各位赞助商、合作伙伴、嘉宾和参会朋友:

    很高兴通知大家,经 Elastic 中国开发者大会组委会研究决定,由于疫情原因延期举办的 2022 Elastic 中国开发者大会将于2022年10月29日在深圳好日子皇冠假日酒店重启举办。

    关于会议信息也做一个同步:

    一、会议场地变化:原会议举办场地——深圳圣淘沙酒店,被深圳政府做为深圳市疫情防控指挥中心,酒店工作人员通知2022年全年都无法提供任何场地举办会议。组委会得知情况后,为了大会及时召开,立即做好预案,在不考虑成本的情况下,将会议场地变更为——深圳好日子皇冠假日酒店,会议的整体环境、场地、展厅、茶歇、用餐等都做了全面的升级。

    二、关于讲师和议题:少部分讲师和议题有变化,组委会近期会与讲师沟通确认是否需要更换新的演讲议题。

    这次的 Elastic 中国开发者大会虽然遇到了很多的困难与波折,但因为您们的理解和支持,一直鼓励着我们,给了我们信心与动力,我们会本着办好中国开发者大会的初心继续前行,再次感谢大家的大力支持!

    注:
  1. 目前大会报名购票通道已重新开启,欢迎有兴趣的朋友报名参会,已经报名参会者无需再次报名。报名链接:https://www.bagevent.com/event/7899116
  2. 如需要加入本次大会微信交流群,请加微信(lsy965145175)拉群。
  3. 更多大会资讯请关注官网:https://conf.elasticsearch.cn

 
 
继续阅读 »
banner_guide.png

亲爱的各位赞助商、合作伙伴、嘉宾和参会朋友:

    很高兴通知大家,经 Elastic 中国开发者大会组委会研究决定,由于疫情原因延期举办的 2022 Elastic 中国开发者大会将于2022年10月29日在深圳好日子皇冠假日酒店重启举办。

    关于会议信息也做一个同步:

    一、会议场地变化:原会议举办场地——深圳圣淘沙酒店,被深圳政府做为深圳市疫情防控指挥中心,酒店工作人员通知2022年全年都无法提供任何场地举办会议。组委会得知情况后,为了大会及时召开,立即做好预案,在不考虑成本的情况下,将会议场地变更为——深圳好日子皇冠假日酒店,会议的整体环境、场地、展厅、茶歇、用餐等都做了全面的升级。

    二、关于讲师和议题:少部分讲师和议题有变化,组委会近期会与讲师沟通确认是否需要更换新的演讲议题。

    这次的 Elastic 中国开发者大会虽然遇到了很多的困难与波折,但因为您们的理解和支持,一直鼓励着我们,给了我们信心与动力,我们会本着办好中国开发者大会的初心继续前行,再次感谢大家的大力支持!

    注:
  1. 目前大会报名购票通道已重新开启,欢迎有兴趣的朋友报名参会,已经报名参会者无需再次报名。报名链接:https://www.bagevent.com/event/7899116
  2. 如需要加入本次大会微信交流群,请加微信(lsy965145175)拉群。
  3. 更多大会资讯请关注官网:https://conf.elasticsearch.cn

 
  收起阅读 »

Elastic日报 第1508期 (2022-09-29)

1.使用 Elasticsearch 构建搜索 API(需要梯子)
https://medium.com/%40andre.lu ... a06b7
2.重磅 | 死磕 Elasticsearch 8.X 方法论认知清单(2022年国庆更新版)
https://mp.weixin.qq.com/s/OrHmVTfY3T9R76V5wSsmYA
3.一文搞懂 Elasticsearch 监控
https://mp.weixin.qq.com/s/IcouvjxozuoYZYRdsdHWTw

编辑:Se7en
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili
继续阅读 »
1.使用 Elasticsearch 构建搜索 API(需要梯子)
https://medium.com/%40andre.lu ... a06b7
2.重磅 | 死磕 Elasticsearch 8.X 方法论认知清单(2022年国庆更新版)
https://mp.weixin.qq.com/s/OrHmVTfY3T9R76V5wSsmYA
3.一文搞懂 Elasticsearch 监控
https://mp.weixin.qq.com/s/IcouvjxozuoYZYRdsdHWTw

编辑:Se7en
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站: https://ela.st/bilibili 收起阅读 »

复展通知 | 2022国际开源节新档期定于11月5-7日,福田会展,不见不散!


图片3.png

致尊敬的各参展商、合作单位、媒体及观众朋友:
      
      很高兴通知大家,经过不断地协调和沟通,深圳国际电子展暨嵌入式系统展及2022国际开源节共同商定,展会将于11月5-7日复展,地点为深圳会展中心(福田)1/9号馆。

      感谢这段时间大家的理解以及默默的支持!花已开,鹏城不见不散!
 
 


2022国际开源节(IOSF)由OSTech联合中国信息通信研究院、Linux基金会亚太区发起策划,在ELEXCON深圳国际电子展暨嵌入式系统展落地,并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、O3DF、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构,GDG、开源中国等全球知名开发者社区,以及上海开源信息技术协会等权威开源机构的共建支持。
国际开源节旨在汇聚全球开源技术与项目,融合国际文化、开源社区生态和开源产业发展,构建“共创共赢”的开源文化,打造中国开源新生态。
2022国际开源节(IOSF)将同期举办前沿技术峰会,主题涵盖“国际开源教育与人才培养论坛”、“OpenSSF开源安全中国峰会”、“Kubernetes on AI & Edge ”、“Hyperledger超级账本峰会” 、“CNCF云原生论坛”、“开源投融资论坛 ”、“高校学术开源峰会”、“O3DF元宇宙论坛”,敬请期待!




 


合作联系

参展合作(微信同步)
Tony,13713437040;
Friday,17612060999;
宣传合作(微信同步)
Cindy,13553827402;
Katharine,13512772116;


继续阅读 »

图片3.png

致尊敬的各参展商、合作单位、媒体及观众朋友:
      
      很高兴通知大家,经过不断地协调和沟通,深圳国际电子展暨嵌入式系统展及2022国际开源节共同商定,展会将于11月5-7日复展,地点为深圳会展中心(福田)1/9号馆。

      感谢这段时间大家的理解以及默默的支持!花已开,鹏城不见不散!
 
 


2022国际开源节(IOSF)由OSTech联合中国信息通信研究院、Linux基金会亚太区发起策划,在ELEXCON深圳国际电子展暨嵌入式系统展落地,并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、O3DF、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构,GDG、开源中国等全球知名开发者社区,以及上海开源信息技术协会等权威开源机构的共建支持。
国际开源节旨在汇聚全球开源技术与项目,融合国际文化、开源社区生态和开源产业发展,构建“共创共赢”的开源文化,打造中国开源新生态。
2022国际开源节(IOSF)将同期举办前沿技术峰会,主题涵盖“国际开源教育与人才培养论坛”、“OpenSSF开源安全中国峰会”、“Kubernetes on AI & Edge ”、“Hyperledger超级账本峰会” 、“CNCF云原生论坛”、“开源投融资论坛 ”、“高校学术开源峰会”、“O3DF元宇宙论坛”,敬请期待!




 


合作联系

参展合作(微信同步)
Tony,13713437040;
Friday,17612060999;
宣传合作(微信同步)
Cindy,13553827402;
Katharine,13512772116;


收起阅读 »

Elastic日报 第1507期 (2022-09-28)

1.怎么去毁掉 ES 的性能-2(需要梯子)
https://blog.allegro.tech/2021 ... .html
2.利用kafka去部署es双数据中心(需要梯子)
https://medium.com/rahasak/ela ... 95e5e
3.Elasticsearch:词分析中的 Normalizer 的使用
https://blog.csdn.net/UbuntuTo ... 89051

编辑:kin122
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
继续阅读 »
1.怎么去毁掉 ES 的性能-2(需要梯子)
https://blog.allegro.tech/2021 ... .html
2.利用kafka去部署es双数据中心(需要梯子)
https://medium.com/rahasak/ela ... 95e5e
3.Elasticsearch:词分析中的 Normalizer 的使用
https://blog.csdn.net/UbuntuTo ... 89051

编辑:kin122
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili 收起阅读 »

ES7.17版本terms查询性能问题

背景

1.对于7版本(大版本)集群希望只维护一个版本,最终选择7.17,对同大版本的7.5版本集群进行升级

2.根据官方描述,_id放到堆外性能损失非常小可以忽略,且对BKD进行了优化

3.升级完成,一段时间之后,收到用户报障

1-cpu.png

2-time.png

4.抽样检查了下部分升级的集群,其中部分受到影响,部分不受影响。且每个集群内存均有一定优化(预期内)

调查&分析

1.发现is_deleted文档特别多,怀疑是7.17版本对于碎片过于敏感。做forcemerge,没什么效果。

2.GET _nodes/hot_threads 查看耗时部分,结果展示笼统,没得到关键信息。

3.给语句加上profile,查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来,主要是 status、pId 字段耗时高,这两个字段都是integer类型,并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题,进一步排查:使用arthas工具获取一段时间内的火焰图

3-火焰图.png

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题:https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差,看起来官方描述的BKD相关优化指的是range

7.测试验证,将字段改成keyword,查看结果,CPU查询耗时恢复到正常范围

4-结果.png

5-结果-time.png

继续阅读 »

背景

1.对于7版本(大版本)集群希望只维护一个版本,最终选择7.17,对同大版本的7.5版本集群进行升级

2.根据官方描述,_id放到堆外性能损失非常小可以忽略,且对BKD进行了优化

3.升级完成,一段时间之后,收到用户报障

1-cpu.png

2-time.png

4.抽样检查了下部分升级的集群,其中部分受到影响,部分不受影响。且每个集群内存均有一定优化(预期内)

调查&分析

1.发现is_deleted文档特别多,怀疑是7.17版本对于碎片过于敏感。做forcemerge,没什么效果。

2.GET _nodes/hot_threads 查看耗时部分,结果展示笼统,没得到关键信息。

3.给语句加上profile,查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来,主要是 status、pId 字段耗时高,这两个字段都是integer类型,并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题,进一步排查:使用arthas工具获取一段时间内的火焰图

3-火焰图.png

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题:https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差,看起来官方描述的BKD相关优化指的是range

7.测试验证,将字段改成keyword,查看结果,CPU查询耗时恢复到正常范围

4-结果.png

5-结果-time.png

收起阅读 »

Elastic日报 第1506期 (2022-09-27)


1. 构建搜索服务?SpringBoot和ES是绝配哦(需要梯子)
https://medium.com/javarevisit ... 0b41f
2. ASP.NET也可以拿ES处理日志吗?yes!(需要梯子)
https://medium.com/%40technica ... 9eaa9
3. Elastic agent,一站式日志解决方案,你值得拥有(需要梯子)
https://medium.zenika.com/how- ... 5aec7

编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
 
继续阅读 »

1. 构建搜索服务?SpringBoot和ES是绝配哦(需要梯子)
https://medium.com/javarevisit ... 0b41f
2. ASP.NET也可以拿ES处理日志吗?yes!(需要梯子)
https://medium.com/%40technica ... 9eaa9
3. Elastic agent,一站式日志解决方案,你值得拥有(需要梯子)
https://medium.zenika.com/how- ... 5aec7

编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
  收起阅读 »

Elastic日报 第1505期 (2022-09-26)

1. 快手搜索在向量检索方向的探索和实践
   https://www.6aiq.com/article/1663498700156

2. 美团大众点评搜索相关性技术探索与实践
   https://www.6aiq.com/article/1657116010069

3. Elasticsearch 汉字补全和拼写纠错
   https://blog.51cto.com/u_14693305/5018534

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili
继续阅读 »
1. 快手搜索在向量检索方向的探索和实践
   https://www.6aiq.com/article/1663498700156

2. 美团大众点评搜索相关性技术探索与实践
   https://www.6aiq.com/article/1657116010069

3. Elasticsearch 汉字补全和拼写纠错
   https://blog.51cto.com/u_14693305/5018534

编辑:yuebancanghai
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
B站:https://ela.st/bilibili 收起阅读 »

INFINI 产品更新啦 20220923

INFINI Labs 产品更新发布

今天 INFINI Labs 为大家又带来了一波产品更新,请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下:

  • 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
  • 修改备集群故障,主集群不能正常写数据的 Bug。
  • 修复 Bulk 请求处理异常造成数据复制不一致的问题。
  • 修复请求日志里面关于 Bulk 统计数据丢失的问题。
  • 修复大并发情况下,请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下:

  • 新增主机概览。

1-640.png

  • 新增主机监控。

2-640.png

  • 节点概览新增日志查看功能(需安装 Agent)。

3-640.png

  • Insight 配置框新增 Search 配置。
  • 优化 Discover 时间范围 Auto Fit,设为15分钟。
  • 优化 Discover 保存搜索,会保存当前的字段过滤和 Insight 图表配置。
  • 优化本地列表搜索查找,支持通配符过滤。
  • 优化告警规则必填字段标记显示。
  • 修复了 Discover 字段过滤白屏问题。
  • 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
  • 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
  • 修复了创建新索引不成功时,异常处理的问题。
  • 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
  • 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针(INFINI Agent)更新如下:

  • 新增按节点读日志文件列表的API
  • 新增读具体日志文件内容的API
  • 新增 Elasticsearch 节点掉线后的基础信息保存
  • 新增主机在线状态的采集
  • 新增基于 Centos 的 Docker 镜像
  • 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
  • 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
  • 新增 Elasticsearch 进程信息采集
  • 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
  • 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
  • 修复 CPU 指标数据显示异常的Bug
  • 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进:

  • 重构了磁盘队列压缩相关配置,支持段文件的压缩。
  • 当集群不可用的情况下,跳过集群节点元数据的获取。
  • 完善节点可用性检测,避免频繁的不可用状态切换。
  • 修复 Elasticsearch 主机地址为空的异常。
  • 完善本地磁盘队列文件的清理,避免删除正在使用的文件。

期待反馈

如果您在使用过程中遇到如何疑问或者问题,欢迎前往 INFINI Labs Github(https://github.com/infinilabs)中的对应项目中提交 Feature Request 或提交 Bug。

您还可以通过邮件联系我们:hello@infini.ltd

或者拨打我们的热线电话:(+86) 400-139-9200

也欢迎大家微信扫码添加小助手,加入用户群讨论,或者扫码加入我们的知识星球一起学习交流。 联系我们

感谢大家的围观,祝大家周末愉快。

继续阅读 »

INFINI Labs 产品更新发布

今天 INFINI Labs 为大家又带来了一波产品更新,请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下:

  • 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
  • 修改备集群故障,主集群不能正常写数据的 Bug。
  • 修复 Bulk 请求处理异常造成数据复制不一致的问题。
  • 修复请求日志里面关于 Bulk 统计数据丢失的问题。
  • 修复大并发情况下,请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下:

  • 新增主机概览。

1-640.png

  • 新增主机监控。

2-640.png

  • 节点概览新增日志查看功能(需安装 Agent)。

3-640.png

  • Insight 配置框新增 Search 配置。
  • 优化 Discover 时间范围 Auto Fit,设为15分钟。
  • 优化 Discover 保存搜索,会保存当前的字段过滤和 Insight 图表配置。
  • 优化本地列表搜索查找,支持通配符过滤。
  • 优化告警规则必填字段标记显示。
  • 修复了 Discover 字段过滤白屏问题。
  • 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
  • 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
  • 修复了创建新索引不成功时,异常处理的问题。
  • 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
  • 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针(INFINI Agent)更新如下:

  • 新增按节点读日志文件列表的API
  • 新增读具体日志文件内容的API
  • 新增 Elasticsearch 节点掉线后的基础信息保存
  • 新增主机在线状态的采集
  • 新增基于 Centos 的 Docker 镜像
  • 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
  • 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
  • 新增 Elasticsearch 进程信息采集
  • 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
  • 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
  • 修复 CPU 指标数据显示异常的Bug
  • 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进:

  • 重构了磁盘队列压缩相关配置,支持段文件的压缩。
  • 当集群不可用的情况下,跳过集群节点元数据的获取。
  • 完善节点可用性检测,避免频繁的不可用状态切换。
  • 修复 Elasticsearch 主机地址为空的异常。
  • 完善本地磁盘队列文件的清理,避免删除正在使用的文件。

期待反馈

如果您在使用过程中遇到如何疑问或者问题,欢迎前往 INFINI Labs Github(https://github.com/infinilabs)中的对应项目中提交 Feature Request 或提交 Bug。

您还可以通过邮件联系我们:hello@infini.ltd

或者拨打我们的热线电话:(+86) 400-139-9200

也欢迎大家微信扫码添加小助手,加入用户群讨论,或者扫码加入我们的知识星球一起学习交流。 联系我们

感谢大家的围观,祝大家周末愉快。

收起阅读 »