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

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

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

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

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

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

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

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

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

相关文章
|
3天前
|
关系型数据库 MySQL 数据库
Python处理数据库:MySQL与SQLite详解 | python小知识
本文详细介绍了如何使用Python操作MySQL和SQLite数据库,包括安装必要的库、连接数据库、执行增删改查等基本操作,适合初学者快速上手。
48 15
|
4天前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。
|
8天前
|
SQL 关系型数据库 MySQL
MySQL导入.sql文件后数据库乱码问题
本文分析了导入.sql文件后数据库备注出现乱码的原因,包括字符集不匹配、备注内容编码问题及MySQL版本或配置问题,并提供了详细的解决步骤,如检查和统一字符集设置、修改客户端连接方式、检查MySQL配置等,确保导入过程顺利。
|
16天前
|
关系型数据库 MySQL 数据库
GBase 数据库如何像MYSQL一样存放多行数据
GBase 数据库如何像MYSQL一样存放多行数据
|
28天前
|
SQL 关系型数据库 MySQL
12 PHP配置数据库MySQL
路老师分享了PHP操作MySQL数据库的方法,包括安装并连接MySQL服务器、选择数据库、执行SQL语句(如插入、更新、删除和查询),以及将结果集返回到数组。通过具体示例代码,详细介绍了每一步的操作流程,帮助读者快速入门PHP与MySQL的交互。
35 1
|
1月前
|
SQL 关系型数据库 MySQL
go语言数据库中mysql驱动安装
【11月更文挑战第2天】
39 4
|
2月前
|
存储 关系型数据库 MySQL
Mysql(4)—数据库索引
数据库索引是用于提高数据检索效率的数据结构,类似于书籍中的索引。它允许用户快速找到数据,而无需扫描整个表。MySQL中的索引可以显著提升查询速度,使数据库操作更加高效。索引的发展经历了从无索引、简单索引到B-树、哈希索引、位图索引、全文索引等多个阶段。
69 3
Mysql(4)—数据库索引
|
1月前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
199 1
|
1月前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
109 2
|
1月前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
144 4