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

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

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

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

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

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

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

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

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

相关文章
|
26天前
|
存储 SQL 关系型数据库
Mysql学习笔记(二):数据库命令行代码总结
这篇文章是关于MySQL数据库命令行操作的总结,包括登录、退出、查看时间与版本、数据库和数据表的基本操作(如创建、删除、查看)、数据的增删改查等。它还涉及了如何通过SQL语句进行条件查询、模糊查询、范围查询和限制查询,以及如何进行表结构的修改。这些内容对于初学者来说非常实用,是学习MySQL数据库管理的基础。
103 6
|
24天前
|
存储 关系型数据库 MySQL
Mysql(4)—数据库索引
数据库索引是用于提高数据检索效率的数据结构,类似于书籍中的索引。它允许用户快速找到数据,而无需扫描整个表。MySQL中的索引可以显著提升查询速度,使数据库操作更加高效。索引的发展经历了从无索引、简单索引到B-树、哈希索引、位图索引、全文索引等多个阶段。
56 3
Mysql(4)—数据库索引
|
26天前
|
SQL Ubuntu 关系型数据库
Mysql学习笔记(一):数据库详细介绍以及Navicat简单使用
本文为MySQL学习笔记,介绍了数据库的基本概念,包括行、列、主键等,并解释了C/S和B/S架构以及SQL语言的分类。接着,指导如何在Windows和Ubuntu系统上安装MySQL,并提供了启动、停止和重启服务的命令。文章还涵盖了Navicat的使用,包括安装、登录和新建表格等步骤。最后,介绍了MySQL中的数据类型和字段约束,如主键、外键、非空和唯一等。
62 3
Mysql学习笔记(一):数据库详细介绍以及Navicat简单使用
|
30天前
|
缓存 算法 关系型数据库
Mysql(3)—数据库相关概念及工作原理
数据库是一个以某种有组织的方式存储的数据集合。它通常包括一个或多个不同的主题领域或用途的数据表。
46 5
Mysql(3)—数据库相关概念及工作原理
|
9天前
|
关系型数据库 MySQL Linux
在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。
本文介绍了在 CentOS 7 中通过编译源码方式安装 MySQL 数据库的详细步骤,包括准备工作、下载源码、编译安装、配置 MySQL 服务、登录设置等。同时,文章还对比了编译源码安装与使用 RPM 包安装的优缺点,帮助读者根据需求选择最合适的方法。通过具体案例,展示了编译源码安装的灵活性和定制性。
45 2
|
12天前
|
存储 关系型数据库 MySQL
MySQL vs. PostgreSQL:选择适合你的开源数据库
在众多开源数据库中,MySQL和PostgreSQL无疑是最受欢迎的两个。它们都有着强大的功能、广泛的社区支持和丰富的生态系统。然而,它们在设计理念、性能特点、功能特性等方面存在着显著的差异。本文将从这三个方面对MySQL和PostgreSQL进行比较,以帮助您选择更适合您需求的开源数据库。
53 4
|
17天前
|
存储 关系型数据库 MySQL
如何在MySQL中创建数据库?
【10月更文挑战第16天】如何在MySQL中创建数据库?
|
21天前
|
SQL Oracle 关系型数据库
安装最新 MySQL 8.0 数据库(教学用)
安装最新 MySQL 8.0 数据库(教学用)
93 4
|
20天前
|
存储 SQL 关系型数据库
【入门级教程】MySQL:从零开始的数据库之旅
本教程面向零基础用户,采用通俗易懂的语言和丰富的示例,帮助你快速掌握MySQL的基础知识和操作技巧。内容涵盖SQL语言基础(SELECT、INSERT、UPDATE、DELETE等常用语句)、使用索引提高查询效率、存储过程等。适合学生、开发者及数据库爱好者。
35 0
【入门级教程】MySQL:从零开始的数据库之旅
|
23天前
|
存储 关系型数据库 MySQL
PACS系统 中 dicom 文件在mysql 8.0 数据库中的 存储和读取(pydicom 库使用)
PACS系统 中 dicom 文件在mysql 8.0 数据库中的 存储和读取(pydicom 库使用)
18 2