black11black
V2EX  ›  问与答

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

  •  1
     
  •   black11black · Dec 24, 2020 via Android · 2111 views
    This topic created in 1993 days ago, the information mentioned may be changed or developed.
    如题,现假设需求如下:

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

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

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

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

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

    此外,你的两种设计,第一种是横向而非纵向,第二种是物理模型设计,而横向纵向是逻辑。模型设计。
    monsterxx03
        6
    monsterxx03  
       Dec 24, 2020
    传感器数据, 现在做技术选型可能会考虑时序类数据库了.
    把问题限定在传统关系型数据库(不考虑 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  
       Dec 24, 2020
    横向纵向你是怎么定义的?我怎么想到横向是时间,不是汽车?
    所以,同意#5,横向纵向是逻辑而已

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

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

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

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

    最近我也想做类似的事情,也在发愁数据库要怎么选。不过我的量级大约只有你的百分之一,感觉一个 PostgreSQL 应该撑得住
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5373 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 73ms · UTC 07:59 · PVG 15:59 · LAX 00:59 · JFK 03:59
    ♥ Do have faith in what you're doing.