国外建站网站,怎么做优惠券网站,行业应用网站建设成本,郑州高新区做网站的公司起因
有人反馈说SR#xff0c;在系统资源还有空闲的时候#xff0c;被操作系统杀掉了。没有日志#xff0c;怀疑是bug#xff0c;如果要解决这个bug。据说在网上查到要升级。请我准备一下升级。
质疑
StarRocks是一款分析型数据库#xff0c;2021年正式开源#xff0c…起因
有人反馈说SR在系统资源还有空闲的时候被操作系统杀掉了。没有日志怀疑是bug如果要解决这个bug。据说在网上查到要升级。请我准备一下升级。
质疑
StarRocks是一款分析型数据库2021年正式开源虽然起步晚但是能听过且有不少应用的也不会有非常致命的问题。我觉得如果真的像上面说的那就是比较严重的问题。但是我不认为这个反馈是对的。
现实工作中有太多事情反馈的和实际的简直相差很大。比如有人说数据库写入慢。按说除了那种互联网大厂一般企业的数据库什么时候写入能成为瓶颈一去看就是insert into select 这样。而select又写的是个全表查询。所以不是insert慢其实是查询慢。而查询通过索引或者改写正确的逻辑后不仅不慢反而能让反馈的人吃怎么会这么快
本来就是使用不当。这里我就说很多企业除了那种互联网大厂真的没有有几千万的业务订单好好写设计逻辑和写SQL的话根本没有大数据的场景。还是本身没用好。
分析
本次是be进程那么就去查be的log。因为有两次。
第一次是看上去是访问内存错误。 第二次是看上去应该是资源不足了。 从这个信息来看这两次都不是一回事。
之所以第一次说是内存错误是因为StarRocks在出问题时候做了coredump。
我也是尝试着去用gdb解析一下。得到效果如下 有一句结论Failed to read a valid object file image from memory.
以我浅薄的认知我觉得是去访问内存上遇到问题。为什么遇到问题这里遇到平时没有问题我猜测还是应用肆无忌惮的查询在处理过程中内存不足或者处理上出现问题。 我个人认为都是使用上不当所致。和bug关系不大。SR的使用也是有规范的。SQL的规范。
这个场景是业务人员使用托拉拽的工具访问SR听到这里可能你就能理解。各种表和SQL在这种无代码的工具下使用就会导致SQL的低效进而引发很多问题。
低代码和无代码的区别是低代码面向的是开发和运维人员简化工作。 无代码面对的是业务人员降低技术使用难度。
但是重点是我认为降低的是使用门槛不代表降低业务分析人员的分析门槛。
首先要具备分析师的技能和素质吧不能什么都不懂的就是过来玩一样指望这样碰撞出来能有什么有价值的东西吧
印证
那么这些都已经这样报错了还会是反馈的那样系统没压力SR就不工作了吗
不是的。
通过日志定位的时间。反查监控。这个数值还是非常震惊的。对比出问题前后和出问题之中的数据显而易见的平坦与峰值。 这就彻底说明反馈的和实际情况违背。
结论
不是StarRocks的bug不用升级。 明显是使用不当所致。无代码对该分析场景使用者的专业素质有非常高的要求。要求是专业的分析人员。这种在一个企业中应该是极少数。
其次由于托拉拽的基础表的选择其实又是一个架构问题。如果能清晰的指导业务逻辑应该是CDC汇聚过来的业务基表。而不是经过Hadoop全家桶处理过的大宽表。
我经常看到打开一个页面100个报表。每个报表至于多少个复杂SQL就不得而知了。而使用者可能只用这里的1个报表。即要看百分之一的图表但是要同时把100个运行一下。
方显大数据方显的大负荷非大数据不能处理也。
