想了解内存数据库比磁盘数据库好在哪里,搜一下就能出来很多答案,今天我就举个具体的例子来说明,应该会更直观生动一点。
随着业务数据量的发展和业务复杂度的增长,某家运营商的经分系统在日常数据处理上呈现以下三个技术特点: 数据量大,数据仓库表随业务量逐步发展,典型单表记录数达到亿万级,需要复杂关联分析和高频更新;无索引条件下的多表关联的复杂查询性能瓶颈,主要是多表关联或者无索引时查询缓慢,每当遇到业务高峰期,核心应用响应及时性压力巨大,影响业务报表的生成效率;查询频率高、并发大、数据库负载高,工单由单次任务加上定时任务执行SQL取数分析,查询频率高,任务涉及的表查询中,报表查询并发量在几百到上千个级别。
于是他们决定要改造,尝试使用基于分布式内存数据库的方式来替代原有基于磁盘架构的数据库,以提升数据处理性能,改造后的经分系统前端应用如果需要实时自主分析与自助取数,可以直接从柏睿数据RapidsDB的查询接口传达指令并调取数据,也就是直接从融合数据模型整合子层DWI层对应的事实表和维度表获得数据。
优化后的架构有两个方面好处:对原本使用的磁盘数据库MySQL的处理流程,减少业务数据的预聚合和预处理操作,同时SQL查询避开磁盘I/O,借助内存处理的高效性,有效地减少提数等待时长,实现从数小时的响应周期降低至秒级甚至毫秒级响应的超高性能,极大地提升前端应用的数据访问性能;减少原数仓的数据中间结果落盘存储环节(大多是数据预计算目的,以提升前端查询性能),不仅降低了数据存储空间,同时也减少了数据开发工作量。
随着业务数据量的发展和业务复杂度的增长,某家运营商的经分系统在日常数据处理上呈现以下三个技术特点: 数据量大,数据仓库表随业务量逐步发展,典型单表记录数达到亿万级,需要复杂关联分析和高频更新;无索引条件下的多表关联的复杂查询性能瓶颈,主要是多表关联或者无索引时查询缓慢,每当遇到业务高峰期,核心应用响应及时性压力巨大,影响业务报表的生成效率;查询频率高、并发大、数据库负载高,工单由单次任务加上定时任务执行SQL取数分析,查询频率高,任务涉及的表查询中,报表查询并发量在几百到上千个级别。
于是他们决定要改造,尝试使用基于分布式内存数据库的方式来替代原有基于磁盘架构的数据库,以提升数据处理性能,改造后的经分系统前端应用如果需要实时自主分析与自助取数,可以直接从柏睿数据RapidsDB的查询接口传达指令并调取数据,也就是直接从融合数据模型整合子层DWI层对应的事实表和维度表获得数据。
优化后的架构有两个方面好处:对原本使用的磁盘数据库MySQL的处理流程,减少业务数据的预聚合和预处理操作,同时SQL查询避开磁盘I/O,借助内存处理的高效性,有效地减少提数等待时长,实现从数小时的响应周期降低至秒级甚至毫秒级响应的超高性能,极大地提升前端应用的数据访问性能;减少原数仓的数据中间结果落盘存储环节(大多是数据预计算目的,以提升前端查询性能),不仅降低了数据存储空间,同时也减少了数据开发工作量。