关系型数据库存储多维指标数据

什么是多维指标数据?

指标是一个统称概念,可以细分为 原子指标​ 和 派生指标 。 以 某企业近一周上海地域的销售金额 为例,整体是一个派生指标,其中的 销售金额 是原子指标; 近一周 是时间, 企业 和 地域 是维度。

可见,指标数据由三部分组成:

  • 时间
  • 维度
  • 数值

其中,维度可以是一个或多个,也可以是零个,简称为多维。

什么是关系型数据库?

典型的关系型数据库就是 MySQL 。

使用时,需要先根据业务设计好数据模式:

  • 数据库中有哪些数据表
  • 数据表中有哪些字段

然后,创建相应的数据库和数据表;最后,存储业务数据。

关系型数据库会有一个特殊的约定 :数据模式是相对固定的。业务不发生变化的情况下,数据模式不会轻易发生变化。

使用关系型数据库存储多维指标数据会有什么问题?

不同的业务会有不同的指标,每一个业务可以单独创建一个数据库,这个比较好理解。

每一个指标都会有时间和数值,但是不同的指标之间,它们的维度名称和维度数目却可能是不同的。

最直接的设计:

  • 每一个指标单独创建一个数据表,位于某个业务数据库
  • 数据表除时间和数值字段外,根据指标的不同,创建若干维度字段

假设某个指标有三个维度:a、b 和 c,表结构如下所示:

timestamp

a

b

c

value

2022-09-15 00:00:00

a1

b1

c1

1

2022-09-15 01:00:00

a2

b2

c2

2

2022-09-15 02:00:00

a3

b3

c3

3

timestamp 表示时间,value 表示数值,a、b 和 c 表示维度。

问题很明显:

  • 如果某个业务拥有成千上万个指标,就需要创建成千上万个数据表。无论是预先创建数据表,还是随着指标的新增动态创建新的数据表,如此数目庞大的数据表是不能接受的。
  • 固化的数据表结构不能很好地应对指标的维度名称和维度数目发生变化的场景。

受限于业务方的部署环境,仅支持关系型数据库 MySQL;而且业务方不能接收一个业务指标一个数据表的粗暴设计。

思考

业务指标的数目是不可控的,但业务指标的维度数目是相对可控的,我们是否可以按维度数目创建 指标表 ,毕竟绝大多数数据可视化组件最多支持三维。

比如:

  • 维度数目为 0 的指标表
  • 维度数目为 1 的指标表
  • 维度数目为 2 的指标表

假设维度数目为 3 的指标表,表结构如下所示:

id

timestamp

d1

d2

d3

value

m1

2022-09-15 00:00:00

a1

b1

c1

1

m2

2022-09-15 01:00:00

a2

b2

c2

2

m3

2022-09-15 02:00:00

a3

b3

c3

3

id 表示指标 ID,用于唯一标识指标;d1 、d2 和 d3 分别表示维度1、维度2 和 维度3。

一张数据表中可以存储多个相同维度数目指标的数据,如:m1、m2 和 m3。存储指标数据时,只要按指标的维度数目,将指标数据存储到相应维度数目的指标表中即可。指标表可以根据业务可能的最大维度数目预先创建,业务维度数目需要扩展时,仅需要新增有限的几张特定维度数目的指标表即可。

还不够!

指标有维度的情况下,指标表仅支持按指标维度次序,依次存储和查询维度1、维度2、… 的维度数据,并不知道具体的维度名称是什么。

考虑到业务希望指标发生变化时,历史数据可追溯,同一个指标需要有多个版本。

也就是说,我们需要知道:

  • 指标的版本有哪些
  • 指标的某个版本有哪些维度,维度名称是什么
  • 指标的某个版本有哪些数据

我们可以:

  • 创建一张版本表,存储指标有哪些版本
  • 创建一张维度表,存储指标的某个版本有哪些维度(名称)
  • 根据维度数目创建若干张指标表,存储指标的某个版本的指标数据

可行!

存储方案

版本表

id

version

m1

1

m2

1

m1

3

id 表示指标 ID,version 表示版本号。

版本表存储着指标和版本的对应关系,可以查询指标的历史版本记录,也可以查询指标的最新版本。

维度表

id

version

name

m1

3

a1

m1

3

a2

m1

3

a3

id 表示指标 ID,version 表示版本号,name 表示维度名称。

维度表存储着指标/版本和维度名称的对应关系,可以按指标 ID 和指标版本查询维度名称列表,多个维度名称的顺序按维度名称存储顺序依次排列。

指标表

id

version

timestamp

d1

d2

d3

value

m1

3

2022-09-15 00:00:00

a1

b1

c1

1

m1

3

2022-09-15 01:00:00

a2

b2

c2

2

m1

3

2022-09-15 02:00:00

a3

b3

c3

3

指标表存储着指标数据。注意,维度1、维度2 和 维度 N 的表现形式。

存储指标数据

新增指标时,使用 Unix 时间戳作为版本号,存储指标 ID 和 版本至版本表;如果指标有维度,存储指标ID、版本号 和维度名称至维度表,如果维度有多个,需要按照维度排列顺序依次存储多条记录。

修改指标时,如果修改后的指标维度名称列表和维度表中该指标最新版本的维度名称列表数目或内容不一致,需要和新增指标一样,存储该指标新的版本号和维度名称列表。

存储指标数据时,获取维度表中该指标最新版本的维度名称列表,即可知指标维度数目;根据维度数目选取指标表,将指标数据存储至该指标表,维度名称需按顺序依次存储至维度1、维度2、…。

查询指标数据

  1. 根据指标 ID 查询版本表,获取该指标的最新版本号,或者直接指定某个版本号;
  2. 根据指标 ID 和版本号,查询维度表,获取该指标的维度名称列表和维度数目;
  3. 根据指标的维度数目,选取指标表;
  4. 根据指标 ID 和版本号,查询指标表,获取该指标的数据;也可以使用时间或维度过滤指标数据。
  5. 使用 2 中获取指标的维度名称,替换 4 中获取的指标数据中的维度1(d1)、维度2(d2) 、…。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/257918.html<

(0)
管理的头像管理
上一篇2025-05-02 00:04
下一篇 2025-05-02 00:06

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注