V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
black11black
V2EX  ›  问与答

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

  •  1
     
  •   black11black · 2020-12-24 12:01:03 +08:00 via Android · 1639 次点击
    这是一个创建于 1430 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题,现假设需求如下:

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

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

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

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

    因为是基于数据行数非常大的情况下的假设,真做实验对比的话比较费时间,想先来论坛里问问各位的看法,有没有大佬解惑一下哪种模式好
    16 条回复    2020-12-25 20:49:20 +08:00
    oneisall8955
        1
    oneisall8955  
       2020-12-24 12:49:10 +08:00 via Android
    mark,菜鸡一名,觉得按汽车 ID hash 后两位分库分表,没必要 1W 张表吧?大佬怎么看(=_=)
    qiayue
        2
    qiayue  
       2020-12-24 12:55:33 +08:00
    这个时候,需要用到时序数据库
    lpts007
        3
    lpts007  
       2020-12-24 12:57:06 +08:00 via Android
    这个场景关系型数据库就算了吧,kv 列存储的数据库选一个
    f6x
        4
    f6x  
       2020-12-24 13:15:58 +08:00
    你考虑下扩展性.
    增加传感器怎么办, 数据量太大了分表怎么分,分库怎么分,怎么备份,插入慢怎么优化,查询慢怎么优化.........sql 怎么维护
    passerbytiny
        5
    passerbytiny  
       2020-12-24 13:16:04 +08:00 via Android
    谁告诉你看基础设施考虑谁优先,去怼死他。

    此外,你的两种设计,第一种是横向而非纵向,第二种是物理模型设计,而横向纵向是逻辑。模型设计。
    monsterxx03
        6
    monsterxx03  
       2020-12-24 13:22:10 +08:00
    传感器数据, 现在做技术选型可能会考虑时序类数据库了.
    把问题限定在传统关系型数据库(不考虑 spanner, tidb 等 NewSQL)
    要考虑下面问题:
    - 单节点内表 sharding 还是多节点 sharding?
    - 你假设的问题里数据是均匀的, 实际业务里不太可能, 所以会有 hash(id)%N 的做法.

    每台车一个表实际造作上很可能是行不通的, 问题里每台车几乎是同时在线的, 意味着数据库需要同时维持 1w 张表是 open 状态, mysql 为例, 一张表至少要打开 frm,ibd 两个文件,需要考虑到操作系统 fd 限制, mysql table_open_cache, innodb_open_files 等参数的调优. 要同时开 1w 张表, 这些参数需要调到很高, 还有持续的同时写入, 文件系统可能就先崩了.
    imn1
        7
    imn1  
       2020-12-24 13:25:55 +08:00
    横向纵向你是怎么定义的?我怎么想到横向是时间,不是汽车?
    所以,同意#5,横向纵向是逻辑而已

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

    现在好像钱多了,第一条逐渐弱化了,变得不重要
    whileFalse
        8
    whileFalse  
       2020-12-24 13:55:04 +08:00
    怎么对所有车的某项特性进行统计?查询一万次吗
    opengps
        9
    opengps  
       2020-12-24 14:04:44 +08:00
    想明白设计目的就知道了。如果数据量有限,那么横向大表当然用起来省事。
    但如果增长巨快,你横向设计得哭。纵向设计倒是可以轻松分布式增加节点
    aegon466
        10
    aegon466  
       2020-12-24 14:11:25 +08:00
    一辆车一张表怎么感觉怪怪的 表是关系模型 应该是静态的 稳定的
    FFFire
        11
    FFFire  
       2020-12-24 15:10:35 +08:00
    所以你查的时候一次查一万张表吗
    prodcd
        12
    prodcd  
       2020-12-24 17:56:56 +08:00
    我就是像你这么想的,也是这么干的。
    16 年时候入公司搞的新项目,公司也没啥钱招 dba,只有几个新毕业的 PHPer,甚至连个前端都木有。
    本以为这项目前期需求都搞明白了,横向有横向的优势,数据采集频率也不高,直接横向 MySQL 表。
    半年以后开发的七七八八,以为可以进行下一个项目,结果这项目一个劲的扩,还要兼容其他近似的产品,越来越发现这种方式的弊端。
    不同传感器采集频率不同,延迟采集到的数据不容易补回去,现场传感器有变化,就需要程序员跟进,而不是只需要运维人员就能搞定,丢失很多数据细节,阿里云 MySQL RDS 默认存储引擎是 innoDB,最多只能有 1000 多列。

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

    你可以看看时序数据库,我也没玩过,但你要明白,做这活的核心就是别给老板省钱,不然省下的钱都要用你的头发还回去。
    black11black
        13
    black11black  
    OP
       2020-12-25 04:42:32 +08:00
    @whileFalse
    @FFFire
    合理的质疑,单独提取某个节点的数据,和统一查询都是常见业务范围。只不过想象一下你有一张百亿行级别的大表,感觉做搜索也不会很轻松,而提取单一节点的数据则会显著变慢,比如一分钟才提取出来,感觉并不划算?
    whileFalse
        14
    whileFalse  
       2020-12-25 07:55:00 +08:00
    @black11black 感觉这个需求全压在 mysql 上就扯淡
    black11black
        15
    black11black  
    OP
       2020-12-25 12:04:47 +08:00
    @whileFalse 本质上就是需要储存+提取,需求层面讲已经很简化,不压在 sql 上还能压在哪呢。
    volvo007
        16
    volvo007  
       2020-12-25 20:49:20 +08:00
    @black11black 压在 Hive 或者 Spark 这种上面怎么样?

    最近我也想做类似的事情,也在发愁数据库要怎么选。不过我的量级大约只有你的百分之一,感觉一个 PostgreSQL 应该撑得住
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2219 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 01:35 · PVG 09:35 · LAX 17:35 · JFK 20:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.