为什么说关系型数据库,纵向设计总是优于横向设计?

如题,现假设需求如下:

我有一中央管理系统,下有智能汽车一万台,每台汽车上有若干传感器,以微秒为级别记录数据,假定每天每车平均产生一万条数据。

以前看到过一个说法是,关系型数据库尽量不要采用横向设计。按这个理论的话,数据库应设计为只包含一张大表,表内有主键、汽车编号、传感器编号、时间、数值这五列。

假定缓存一年数据,那可粗略估算数据量为 365 亿行,以某种方式分区。

而按照我个人感觉,则应设计为每车数据储存一张表,共一万张表,每张表不分区。我觉得这样有一个好处是,比如如果全部储存在一张大表中,大表按照时间分区,比如每天一区。那么面对比如调出某车过去一年全部数据这种需求时,效率应不如另一种方案高。

因为是基于数据行数非常大的情况下的假设,真做实验对比的话比较费时间,想先来论坛里问问各位的看法,有没有大佬解惑一下哪种模式好

Click to rate this post!
[Total: 0 Average: 0]

相关文章

15 thoughts on “为什么说关系型数据库,纵向设计总是优于横向设计?

  1. mark,菜鸡一名,觉得按汽车 ID hash 后两位分库分表,没必要 1W 张表吧?大佬怎么看(=_=)

  2. 你考虑下扩展性.
    增加传感器怎么办, 数据量太大了分表怎么分,分库怎么分,怎么备份,插入慢怎么优化,查询慢怎么优化………sql 怎么维护

  3. 谁告诉你看基础设施考虑谁优先,去怼死他。

    此外,你的两种设计,第一种是横向而非纵向,第二种是物理模型设计,而横向纵向是逻辑。模型设计。

  4. 传感器数据, 现在做技术选型可能会考虑时序类数据库了.
    把问题限定在传统关系型数据库(不考虑 spanner, tidb 等 NewSQL)
    要考虑下面问题:
    – 单节点内表 sharding 还是多节点 sharding?
    – 你假设的问题里数据是均匀的, 实际业务里不太可能, 所以会有 hash(id)%N 的做法.

    每台车一个表实际造作上很可能是行不通的, 问题里每台车几乎是同时在线的, 意味着数据库需要同时维持 1w 张表是 open 状态, mysql 为例, 一张表至少要打开 frm,ibd 两个文件,需要考虑到操作系统 fd 限制, mysql table_open_cache, innodb_open_files 等参数的调优. 要同时开 1w 张表, 这些参数需要调到很高, 还有持续的同时写入, 文件系统可能就先崩了.

  5. 横向纵向你是怎么定义的?我怎么想到横向是时间,不是汽车?
    所以,同意#5,横向纵向是逻辑而已

    不熟悉数据库,早年的同事是这样考虑的
    1.机器处理能力
    2.业务逻辑(需求)

    现在好像钱多了,第一条逐渐弱化了,变得不重要

  6. 想明白设计目的就知道了。如果数据量有限,那么横向大表当然用起来省事。
    但如果增长巨快,你横向设计得哭。纵向设计倒是可以轻松分布式增加节点

  7. 我就是像你这么想的,也是这么干的。
    16 年时候入公司搞的新项目,公司也没啥钱招 dba,只有几个新毕业的 PHPer,甚至连个前端都木有。
    本以为这项目前期需求都搞明白了,横向有横向的优势,数据采集频率也不高,直接横向 MySQL 表。
    半年以后开发的七七八八,以为可以进行下一个项目,结果这项目一个劲的扩,还要兼容其他近似的产品,越来越发现这种方式的弊端。
    不同传感器采集频率不同,延迟采集到的数据不容易补回去,现场传感器有变化,就需要程序员跟进,而不是只需要运维人员就能搞定,丢失很多数据细节,阿里云 MySQL RDS 默认存储引擎是 innoDB,最多只能有 1000 多列。

    我们用的第三方采集平台是 PostgreSQL,当初好像是 4 核 8G 的阿里云,所有数据集中在一个表里。我们只要过去查点历史记录就很容易卡死,对方被迫把不同项目的点分配到不同数据表,到后来是单个通道一张表,以适应我们读取需求,但还是有些扛不住。后来我们只好改变策略,把查历史的操作限制到一个线程,也给服务器升级到 8 核 16G,轻易不敢找它要历史数据。

    你可以看看时序数据库,我也没玩过,但你要明白,做这活的核心就是别给老板省钱,不然省下的钱都要用你的头发还回去。

  8. @whileFalse
    @FFFire
    合理的质疑,单独提取某个节点的数据,和统一查询都是常见业务范围。只不过想象一下你有一张百亿行级别的大表,感觉做搜索也不会很轻松,而提取单一节点的数据则会显著变慢,比如一分钟才提取出来,感觉并不划算?

  9. @whileFalse 本质上就是需要储存+提取,需求层面讲已经很简化,不压在 sql 上还能压在哪呢。

  10. @black11black 压在 Hive 或者 Spark 这种上面怎么样?

    最近我也想做类似的事情,也在发愁数据库要怎么选。不过我的量级大约只有你的百分之一,感觉一个 PostgreSQL 应该撑得住

发表回复

您的电子邮箱地址不会被公开。