有寓意的logo设计图片,恩城seo的网站,怎么做赌钱网站,做外文翻译的网站「导语」 硬石科技#xff0c;成立于2018年#xff0c;总部位于武汉#xff0c;是一家专注于应急管理行业和物联感知预警算法模型的技术核心的物联网产品和解决方案提供商。硬石科技作为一家高新技术企业#xff0c;持有6项发明专利#xff0c;拥有100余项各类平台认证和资… 「导语」 硬石科技成立于2018年总部位于武汉是一家专注于应急管理行业和物联感知预警算法模型的技术核心的物联网产品和解决方案提供商。硬石科技作为一家高新技术企业持有6项发明专利拥有100余项各类平台认证和资质荣获国家级及省市级荣誉共计13项受到应急主管部门的高度认可。多年来硬石科技致力于为应急管理业务提供优质服务并取得了显著成就。 硬石科技专业致力于应急管理行业提供以物联网技术和感知预警算法模型为核心的先进产品和解决方案。应急管理行业的业务非常繁多和复杂很多时候都需要在短时间内交付出稳定高效的业务系统。譬如下图某市的应急综合指挥大屏这款大屏集成了先进的物联网技术和感知预警算法模型为应急管理部门提供了强大的工具和支持。通过实时监测和分析数据应急隐患排查大屏能够帮助应急主管部门在事前、事中和事后快速响应和处理突发事件。 通过之前对MemFire Cloud基本了解它的一些特性比如自动生成API接口、云存储等功能正是本次需求所需要的。综合考量下我们决定使用MemFire Cloud来开发此次的应急大屏。
那么这样一套大屏具体是如何使用MemFire Cloud开发的呢在开发过程中又会遇到哪些挑战呢
应急综合指挥大屏带来的三大挑战
1.大量不同维度的隐患数据需要进行统计分析需要开发各种api接口 隐患数据来源于不同维度的数据采集包括各个行业领域的数据几十个领域、乡镇层面的社区数据以及不同级别和来源的隐患数据等。为了满足前端的多样化数据展示需求需要开发大量的API接口来提供各个维度的数据。
2.多样性展示需求、数据关联性复杂实现各种统计分析 由于隐患数据的多样性和与之相关联的多个数据表表与表之间存在较强的数据关联性。因此特定场景下需要进行复杂的统计分析才能获得所需的数据。
3.存储并检索海量的非结构化的隐患数据 隐患大屏需要存储海量的隐患数据的素材包括图片、视频和附件。这种情况下需要具备强大的存储和管理大数据的能力以确保能够有效地存储和检索这些数据的素材。
面对挑战MemFire Cloud如何破局
那么面对应急综合指挥大屏带来的三大挑战MemFire Cloud如何一一攻克
首先针对大量不同维度的数据需要开发各种API接口的挑战。在项目过程中根据业务需求我们需要根据时间周期、隐患等级、处置状态、行业领域和行政区划等多个不同的维度来统计和分析整个过程中需要开发接近30个api接口。采用MemFire Cloud自动生成REST接口大约一天的工作量就可以获得所有的接口。中途遇到两次需求变更的情况我们也无需重新编写接口和前后端联调只需要根据自动生成的API接口返回数据进行一些数据结构的调整即可。这样的优化方案极大地简化了开发流程提高了开发效率并确保了应对需求变更的灵活性。
接着面对多样性展示需求、数据关联性复杂实现各种统计分析的挑战。在我们开发过程中遇到一些困难例如在数据表之间没有建立外键关联的情况下如何进行多表关联查询。比如像这样的需求场景
现在需要查询当前区县下的所有乡镇的数据乡镇的顺序必须根据表yj_countryside_info里countryside_type 1后的乡镇的顺序。但是乡镇的数据又在表sys_dept里为何不直接使用yj_countryside_info表呢?这是因为yj_countryside_info表里是一个数据字典里面有很多测试乡镇它并不能代表当前区县的所有乡镇。在这种情况下我们遇到的问题就是
「当需要查询一个数据表的数据时这个数据表的过滤是依赖于另外一张表的某些数据或某个字段时但是这两张表又未建立关联关系传统的sql脚本是可以通过左关联查询到的但是在使用MemFire Cloud目前api是无法做到的。」
我们请教了MemFire Cloud相关的技术人员他们耐心的解答并给出了三种解决方案。
a. 创建视图
「优点」视图可以根据特定的业务需求和查询条件对数据进行过滤、排序、聚合等操作从而简化了对数据的操作。使用视图可以将复杂的查询逻辑封装到一个视图中使得用户可以通过简单的查询语句获取所需的数据。
「缺点」它们可能会影响性能因为它们需要消耗额外的资源它们可能不能够提供最新的数据。
b.使用数据库函数
原理就是写一个可以统计数据并且返回统计数据的sql脚本的方法跑在数据库然后通过MemFire Cloud的rpc数据库方法在前端调用该函数。
例如
get_sub_dept就是我们定义的数据库函数
CREATE OR REPLACE FUNCTION get_sub_dept(my_dept_id varchar)
RETURNS TABLE (sub_dept_id VARCHAR)
AS $$
BEGINRETURN QUERY select dept_id from sys_dept d where my_dept_id any (string_to_array(d.ancestors, ,));
END;
$$ LANGUAGE plpgsql;在前端调用此方法
const { data, error } await supabase.rpc(get_sub_dept, { my_dept_id: 1111 })「缺点」对前端人员对数据库知识和设计有一定的要求存在数据库里面的代码不好维护。
c.子查询
熟悉业务和熟悉数据表的设计的同时和条件允许下看是否可以通过子查询方式过滤数据。
例如sql脚本
SELECTsd.dept_id,sd.dept_name
FROMsys_dept sd
WHEREsd.del_flag 0 AND sd.dept_id IN ( SELECT yci.dept_id FROM yj_countryside_info yci WHERE yci.countryside_type 1 )
ORDER BYsd.order_num转换为api查询
const xz_list await supabase.from(yj_countryside_info).select(dept_id).eq(countryside_type, 1)
if (xz_list xz_list.data.length 0) {const xz_array xz_list.data.map(item item.dept_id);const { data, error } await supabase.from(sys_dept).select(dept_id,dept_name).eq(del_flag, 0).order(order_num, { ascending: true }).in(dept_id, xz_array)
}经过综合考虑我们选择了方案C来解决这个问题。我们发现方案C相对于方案A和方案B在后期的维护成本方面有很大的降低。
最后面对存储海量隐患相关的图片、视频和附件的挑战。我们借助MemFire Cloud云存储具备强大的存储和管理大数据的能力创建了存储桶来统一存储海量素材并使用REST接口及SDK快速实现了文件上传、下载和访问等功能的开发满足了项目的需求。
总结
通过借助MemFire Cloud的强大能力项目开发周期由原来的一个月缩短到现在的两周投入人力由原来的两个减少为一个。这使得开发变得更加高效和简化抗住了三大数据的挑战完全不用担心底层数据的问题保证了数据大屏快速稳定的上线缩减了时间与人力成本。
使用MemFire Cloud我们可以专注于前端开发工作而无需担心后端的搭建和维护也不需要开发接口前端只需要关注页面的样式和功能交互。这种快速开发和节约成本的方法能够更好地实现应急大屏的开发需求。
当然在使用MemFire Cloud的时候也遇到了一些在使用文档上的不便比如花费了很长时间才找到自己想要的文档内容。也希望平台能够对此关注起来哈总体来说我们对使用MemFire Cloud的开发海量数据大屏的体验还是感到非常惊喜的也希望MemFire Cloud能够越来越强大
