• [二次开发] MRS3.0.3上ES里的Transport客户端起不来,卡住,不报错
    执行esTransportClient.sh 卡住但是同一个客户端上,同一个用户使用RestClient客户端执行esRestClient.sh正常按照MRS3.0.3用户指南上操作, 而且使用java  也是无法创建TransportClient,和上面情况类似也是一直卡住(信息如下),请问这个情况是哪里出问题。
  • [基础组件] 【ElasticSearch产品】如何保证数据可靠性
    【功能模块】可靠性【操作步骤&问题现象】1、ElasticSearch如何保证数据可靠性?2、【截图信息】【日志信息】(可选,上传日志内容或者附件)
  • [问题求助] 【fusioninsight.elasticsearch 产品】
    微服务分布式情况如何实现统一认证写在网关服务中还是?
  • [其他] 【fusioninsight.elasticsearch 产品】
    1,现在要做业务迁移  把之前自己的es业务逻辑 全部都放到华为云的es上2,现有业务使用得是spring data 封装的ElasticsearchRepository工具类操作es3,如果切换为华为的es,需要修改逻辑代码吗  所有ElasticsearchRepository操作变成PreBuiltHWTransportClient这种操作方式吗?4,如果不改代码  华为的 认证模块 应该如何添加
  • [其他] CSS中的elasticSearch(4)
    正排索引,从Key(文档编号)找value,效率很低。倒排索引,通过value找key,有很高的效率。理解的很糊涂。这里的人名、喜欢啊等词就是value,数量虽然有限,但也可以有很多啊通过kibana执行restful api,比如get 看集群健康状况;put 创建一个没有分片的小索引post 添加文档对象(自动生成文档id); delete删除多个索引其实,用CURL也很方便,多指定GET等方法,IP和端口等就可以查找文档的2种路由算法,就是怎么将文档放到分片,又怎么到分片上去找文档。因为默认的路由算法中,主分片的个数是一个重要的因子。所以不能随便修改索引的主分片个数。不同的ES版本,对于扩容的支持的程度是不一样的。如不支持、成倍、自由等。还有一种就是指定写到哪个分片的路由算法。自动分片的平衡算法。算法内容就不深入了。扩容一般建议水平扩容,当单实例索引的数目达到10亿条或大小到了1T;减容,可以通过华为CSS的管理台去操作。使用ES索引Hbase数据,2者之间协同的方式,可以有实时和批量索引的方式(用Hbase2ES组件)当一个节点上部署了多个ES实例,有可能存在同一个节点上既有主分片又有从分片。这样会产生单点故障。有一个跨节点分配的配置可以解决。而不仅是跨实例分配。 cluster.routing.allocation.same_shard.host:true
  • [其他] CSS中的elasticSearch(3)--分布式概念
    分布式架构概念Cluster中包含EsNode 和EsMastershards是索引的分片,放到多个节点上。replicas是索引的副本,也就是分片的副本。好处除了,提供容错性,还有一个你想到了吗就是提高查询效率。recovery是数据恢复或重新分布,当加入、退出节点时有这些工作要做,我猜想可能非常耗时耗力gateway,索引快照的存储方式transport 内部节点或集群与客户端交互方式,默认TCP
  • [其他] CSS中的elasticSearch(2)
    ES是主从结构。主节点由选举机制选出。分片和备份。Shard 和Replica主节点挂了之后,在从节点中选取主节点。数据一般放在内存里,满了刷到磁盘持久化。从下到上的架构:  gateway(索引存储) > distribute lucene dir > Index & Search & Mapping & River> Discovery(节点管理、选举) 支持的脚本语言 插件 > 和客户端的通讯方式 > Restful style API (封装了索引和搜索功能)基本概念是要理解的:Index相当于关系型数据库中的数据库实例,这个很不一样哦Type在es7中已被删除,因为会导致数据稀疏,所以以后是1个Index就1个TypeDocument被索引的基本单位Mapping约束字段的类型,以及如何索引
  • [其他] CSS中的elasticSearch(1)
    最近弄了一个云搜索的服务,简称CSS,那就先要理解一下其中的服务,第一个就是ES,就是elasticSearchES是基于Lucene的全文检索,但对其进行了扩展。它是分布式的,也可以是单台的。它支持结构化和非结构化的数据。特点有什么呢?高性能(BKD,检索快)、扩展性、相关性(排序)、可靠性它的应用场景,除了日志检索,还有:时空检索、智能搜索等。它的生态圈,最下层是数据接入层:logstach中间是ES上层是用户接入层:kibana,具有可视化能力另外还有插件扩展。
  • [二次开发] 【FusionInsight -es产品】jar 包获取不到
    这个jar包如何获取?
  • [问题求助] 【fusioninsight.elasticsearch 产品】
    按照上述方式做了样例代码测试,跑通之后遇到几个问题  望详解1,部署项目上线的时候 conf 文件放到哪里(是否所有涉及到es的微服务项目都需要安全认证----这里应该是要单独在创建一个项目来做权限认证把)2,现有es使用的是ElasticsearchRepository 1.ElasticsearchRepository 使用的是com.springframework下的包,而样例代码使用的是华为封装的包com.huawei是不是要把所有业务代码移植成华为的这种写法?小白一枚 望详解
  • [基础组件] 【fusioninsight.elasticsearch产品】
    功能模块】fusioninsight.elasticsearch 【操作步骤&问题现象】1、样例代码跑通了2、现在要做业务迁移  把之前自己的es业务逻辑 全部都放到华为云的es上3,以前的添加方式, 通过ElasticsearchRepository工具类 直接保存list 4,看了文档没有操作list的方式 ,使用华为的这个工具 应该怎么操作list
  • [ElasticSearch] 【FusionInsight-es】测试样例代码问题
    【功能模块】测试样例代码问题【操作步骤&问题现象】1、linux上跑出现问题2,需要替换成自己的索引吗?如果是 样例代码中是不是都要替换【截图信息】测试样例代码问题
  • [二次开发] HD 6.5.1.7 Elasticsearch  用java代码查询出来的结果是科学计数法,有没有什么方法让直接返回数值型,不
    【操作步骤&问题现象】head插件查询出来的结果不以科学记数法表示,java代码查询的聚合结果是科学记数法索引中原字段是double目前只想到一个一个通过DecimalFormat解析结果做格式化处理,但这样太麻烦。ES中是否有直接指定格式返回的方式?还有比较奇怪的是数值只有 266144704 也不算大,但还以科学记数法显示了。
  • [问题求助] 【鲲鹏920 robox】【android 容器 opengles 2.0】编译的镜像是否支持opengl es 3.0
    环境:运行的服务端内核和编译android镜像都没有打exagear补丁在android容器中执行opengl es3.0编写的应用程序会失败,但是opengl es2.0的就可以正常运行。检测到android系统目前是opengl es 2.0的版本。请问robox是否可以支持opengl es 3.0?还有exagear补丁有适配完成吗?
  • [技术干货] ES写入调优总结
    一、项目背景在**项目中,客户测试大数据场景,在ES写入性能时,使用Jmeter对ES的_bulk接口进行压测,发现Arm的写入TPS性能为x86的70%-80%,低了30%左右。客户已根据BoostKit大数据ElasticSearch调优套件中的调优手段进行调优,包括OS、BIOS和组件的调优,没有明显的效果。 boostkit大数据ElasticSearch调优指导:https://support.huaweicloud.com/tngg-kunpengbds/kunpengelasticsearchhdp_05_0017.html1.1环境配置信息硬件配置:鲲鹏X86 – IntelCPU2* **2* ** v422Cores@2.2GHz内存16*32GB 2933MHz8*32GB 2400MHz磁盘2*1.2T SAS HDD10*960GB SSD1.6T SSD 软件配置:版本OSCentOS 7.6ELK7.4.2JDK毕昇JDK 1.8.0 b272测试功能Jmeter目标软件客户的自研软件1.2 性能对比在客户环境中,ES初次的写入测试中,Arm的写入TPS性能为x86的70%-80%,低了30%左右。单线程批量数连接数机型响应时间(毫秒)ES写入TPSTPS鲲鹏/X86CPU200010鲲鹏12477500-8250070%34%Intel87110000-12000031%20鲲鹏188102000-11000077%66%Intel119130000-14500060%30鲲鹏268110000-11400080%84%Intel213130000-15000075%40鲲鹏355110000-11600081%85%Intel295130000-15000075% 二、调优分析2.1硬件对齐对齐磁盘,包括型号规格,大小,raid和FIO性能测试对比等 x86 用的惠普SATA SSD,4块盘组的raid10 鲲鹏用的三星pm883 SATA SSD,10块盘组raid10根据磁盘fio测试结果,X86 的随机读略强于arm,arm和x86在4k的写入性能基本持平。对比CPU算力SPECCPU 2006  x86 **   v4 VS kunpeng **   x86:intrate 1700, fprate 1070, intspeed 71, fpspeed 108arm: intrate 1550, fprate 1450, intspeed 27, fpspeed 27arm的单核和多核能力均不如x86,单核算力是X86的38%,多核整机算力是X86的91%2.2 CPU、内存、IO和网络的基础资源消耗CPU利用率达85%,属于正常的负载。软中断低,瓶颈不在网络。磁盘的利用率10%左右,写的速度200-500M/S,写入速度大,瓶颈也不在IO。同时,发现只有一个numa0在工作,后来跟客户确认,是关闭numa导致,后来开启numa后恢复4numa运行,但是对性能没提升效果。2.2JAVA热点函数分析热点函数indexShard, ElasticsearchConcurrentMergeScheduler,主要是在索引index和merge上。系默认每个分片会有四个线程用于Merge操作,假设我们有500个分片,那么Merge可以使用的CPU核数达到了2000个,在一个数据写入非常频繁的系统,大部分CPU可能都会被Merge给消耗掉。所以并不是分片越多越好,分片越多,那么用于Bulk的CPU就越多。通过热点函数分析,需要对index和merge的配置进行调整。  三、调优过程和结果3.1多实例+绑核使用numactl –N –m 分别对各实例进行numa nodes和内存进行一对一绑核,cpu利用率有明显的降低。整体性能相对不绑核有20%以上的提升。3实例  不绑核 总11万-13.5万 3实例  160链接  15万-17万绑核后,3实例绑核有36% 、26%提升 4实例  160链接:15-17万   80链接:15万-19.5万 50链接:16万-19万 4实例不绑核  50/160链接,11万-13万 绑核后,4实例绑核有36% ,46%提升。 3.2索引大小,线程池优化索引大小,线程池优化,在elasticsearch.yml 上添加以下配置,有效果indices.memory.index_buffer_size,indices.memory.min_index_buffer_size已经索引好的文档会先存放在内存缓存中,等待被写到到段(segment)中。缓存满的时候会触发段刷盘(吃i/o和cpu的操作)。默认最小缓存大小为48m,不太够,最大为堆内存的10%,可适当调大。thread_pool.search.queue_size:线程写的队列数40链接  总shards:17万,单shard:8.5万3.3索引优化refresh_interval:默认为“1s”,即每秒都会强制生成1个新的segments文件,增大索引刷新时间,可以生成更大的segments文件,有效降低IO并减少segments merge的压力。如果只是单纯导入数据,不需要做实时查询,可以把refresh禁用(即设置index.refresh_interval为-1),并设置“index.number_of_replicas”为“0”,当然这样设置会有数据丢失风险。等到数据完成导入后,再把参数设置为合适的值。测试对比过number_of_replicas为0和1,性能相差不大。Translog.flush_threshold_size: 设置异步刷盘事务日志文件,ranslog大小,增大translog flush大小,可提升性能。 3实例 没做索引优化前 8万-8.6万3实例 索引优化后  8.5万-9.3万 3.4Merge优化index.merge.policy.max_merge_at_once:一次最多只merge多少个segments,默认是10。index.merge.policy.floor_segment:Elasticsearch避免产生很小的segment,小于这个阀值的所有的非常小的segment都会merge直到达到这个floor的size,默认是2MB。index.merge.policy.max_merged_segment:超过多大size的segment不会再做merge,默认是5g。index.merge.policy.segment_per_tier:默认为10,表示每个tier允许的segment个数,注意这个值要大于等于“index.merge.policy.max_merge_at_once”值,否则这个值会先于最大可操作数到达,就会立刻做merge,这样会造成频繁merge;index.merge.scheduler.max_thread_count:设置段合并的线程数量,段合并的计算量庞大,而且还要吃掉大量磁盘I/O。适当增大段合并线程数,可提升段合并性能。3实例 Merge优化   9万-10.1万 4实例 index和merge优化后 50链接 最高10.4万
总条数:106 到第
上滑加载中