数据库有成千上万的表是怎么回事?

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 大型数据库经过多年运行常积累数以万计的数据表,其中很多是中间表,占用大量资源,导致数据库膨胀。这些中间表大多为数据呈现服务,因前端报表频繁修改而不断增加。SPL 通过独立计算引擎,将中间数据移至文件系统,减少数据库负担,提高性能,优化资源利用。

许多大型数据库在运行多年后都会积累出很多的数据表,严重者数以万计,非常臃肿。这些数据表年代久远,有些已经忘记建设原因,也可能已不再有用,但因为很难确认而不敢删除。这给运维工作带来巨大的负担。伴随着这些表还有大量的存储过程仍在不断地向这些表更新数据,占用计算资源,经常要迫使数据库扩容。
这些表是真地是业务需要的?业务会复杂到需要成千上万的表才能描述吗?
有过开发经验的人都知道这不大可能,几百个表就能描述相当复杂的业务了。这些表大多数都是所谓的中间表,并不是用来存储基础数据的。

那么,为什么会有中间表?
中间表大多是为数据呈现(报表或查询)服务的。原始数据量很大或计算过程很复杂时,直接计算很麻烦且性能很差,我们就会先计算出一些中间结果存起来,呈现时再根据参数做一些简单过滤汇总计算,用户体验就会好很多。这些中间数据就会以数据表的形式出现,同时也会伴随着存储过程去定时更新数据。前端报表是稳定性很差的业务,要经常修改和增加,随之而生的中间表也就越来越多。
还有一些中间表是外部数据源造成的,有时应用要把库外数据导入到数据库后才能和库内数据混合计算,这也会让数据库多一些表。而且,很多外部数据是多层的 json 格式,在关系数据库中还要建立多个关联的表来存储,会进一步加剧中间表过多的问题。

之所以要把中间数据放进数据库,主要是为了获得数据库的计算能力。数据库外缺乏强有力的计算能力,而数据库的计算能力是封闭的(它不能计算数据库外的数据)。为了获得数据库的计算能力,只能把这些数据装入数据库,形成了中间表。
数据库还有两个工程结构上的原因会成为这件事的帮凶:
数据库是个独立进程,计算能力在应用外部,不从属于某个应用。各个应用共享数据库,都能访问数据库。某个应用中生成的中间表可能被另一个应用引用,这就造成了应用间的耦合性,即使某个中间表的制造者已经下线不用,但因为可能被别的应用使用了而不能删除,中间表就会一直留下来。
数据库表以线性形式组织管理的。在数量不多时尚可,太多(几千上万时)就很混乱,人们一般会用树状结构来组织管理众多的条目。但关系数据库不支持这种方案(它的模式概念可理解为只能分两层),这就要给表起较长的名字来分类,这一方面使用不便,另一方面对开发管理水平要求很高,在工作较急迫时就顾不上规范了,上线了也就忘了,A 业务搞几十个,B 业务弄几十个,时间一长,就会遗留大量的中间表。
中间表及相关的存储过程占用大量昂贵的数据存储及计算资源,显然,在经济上很不划算。

如果能够实现独立计算引擎,使计算不再依赖于数据库提供,那么就可以为数据库瘦身了。
这就是SPL 了。
SPL 拥有开放和可集成的计算能力。开放性是指计算能力与存储分离,计算不依赖于存储,也就是存算分离。否则,如果要求特定的存储方案,只是把数据库的臃肿换了一个地方臃肿。可集成性是指计算能力可以嵌入到应用程序中,成为应用的一部分,而不能象数据库那样是个独立的进程,这样就不会被其它应用(模块)共享,避免出现应用间的耦合问题。
43d67259ba0da7ecf3db8da465b22892_7cbf35c599f34197a734d00211270053_clipboard.png
QQ_1731310920910.png

中间数据不必再以数据表的形式落在数据库中,而可以放到文件系统中,由 SPL 提供计算能力。对于只读的中间数据,使用文件存储时不必考虑改写以及相应的事务一致性问题,机制大为简化,这样能获得比数据库更好的性能。文件系统还可以采用树形组织方案,将各个应用(模块)的中间数据分类管理好,使用也更方便,这样中间数据就会天然从属于某个应用模块,不会被其它应用访问到。当有应用修改或下线时,相应的中间数据可以跟随修改删除,而不必担心被共享而产生的耦合问题。用于生成中间数据的存储过程也可以移到数据库外部,作为应用程序的一部分,同样不会产生耦合问题。

SPL 提供了高性能二进制文件格式,采用了压缩、列存、索引等机制,还支持并行分段,以及相关的高性能算法,进一步提升计算的性能。
SPL 还可以直接实现库外数据与库内数据的混合计算,外部数据源不必再导入数据库。临时取数有更好的实时性,而且,还能充分利用原数据源的优势,这些我们在多源混合计算时已经讲过。

有了 SPL 开放且可集成的计算能力,在设计应用的体系结构时就会更为得心应手,计算可以放在最合适的位置,不必为了获得计算能力而部署多余的数据库,让数据库专心做它最合适的事,复杂的灵活的计算都丢给 SPL 解决,将资源效用发挥到最大。欢迎前往SPL开源社区乾学院交流沟通!

目录
打赏
0
5
5
1
70
分享
相关文章
数据库有成千上万的表是怎么回事?
大型数据库长期运行后常会积累海量数据表和存储过程,导致资源浪费与运维负担加重。这些表多为中间表,因报表查询或外部数据源导入而产生。esProc SPL 提供独立计算引擎,实现存算分离,将中间数据从数据库移至文件系统,简化机制并提升性能。其高性能二进制文件格式与混合计算能力,可有效减少数据库负担,优化资源利用。欢迎体验 esProc SPL,让数据库更专注于核心任务。
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
149 82
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
Docker Compose V2 安装常用数据库MySQL+Mongo
以上内容涵盖了使用 Docker Compose 安装和管理 MySQL 和 MongoDB 的详细步骤,希望对您有所帮助。
221 42
MySQL生产环境迁移至YashanDB数据库深度体验
这篇文章是作者将 MySQL 生产环境迁移至 YashanDB 数据库的深度体验。介绍了 YashanDB 迁移平台 YMP 的产品相关信息、安装步骤、迁移中遇到的各种兼容问题及解决方案,最后总结了迁移体验,包括工具部署和操作特点,也指出功能有优化空间及暂不支持的部分,期待其不断优化。
如何排查和解决PHP连接数据库MYSQL失败写锁的问题
通过本文的介绍,您可以系统地了解如何排查和解决PHP连接MySQL数据库失败及写锁问题。通过检查配置、确保服务启动、调整防火墙设置和用户权限,以及识别和解决长时间运行的事务和死锁问题,可以有效地保障应用的稳定运行。
165 25
云数据库:从零到一,构建高可用MySQL集群
在互联网时代,数据成为企业核心资产,传统单机数据库难以满足高并发、高可用需求。云数据库通过弹性扩展、分布式架构等优势解决了这些问题,但也面临数据安全和性能优化挑战。本文介绍了如何从零开始构建高可用MySQL集群,涵盖选择云服务提供商、创建实例、配置高可用架构、数据备份恢复及性能优化等内容,并通过电商平台案例展示了具体应用。
从 MySQL 到时序数据库 TDengine:Zendure 如何实现高效储能数据管理?
TDengine 助力广州疆海科技有限公司高效完成储能业务的数据分析任务,轻松应对海量功率、电能及输入输出数据的实时统计与分析,并以接近 1 : 20 的数据文件压缩率大幅降低存储成本。此外,taosX 强大的 transform 功能帮助用户完成原始数据的清洗和结构优化,而其零代码迁移能力更实现了历史数据从 TDengine OSS 与 MySQL 到 TDengine 企业版的平滑迁移,全面提升了企业的数据管理效率。本文将详细解读这一实践案例。
31 0

数据库

+关注