V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
nullcoder
V2EX  ›  数据库

超过 100 列的表,这样的设计存在什么优缺点?

  •  
  •   nullcoder · 2018-09-18 11:43:09 +08:00 · 4197 次点击
    这是一个创建于 1173 天前的主题,其中的信息可能已经有所发展或是发生改变。
    业务背景:
    需要和硬件每分钟通信,写一次记录。
    读取可能是挑其中部分列,列一般不会变,列名会存在另一个表里。
    除了 100 个数据列还有识别的字段和时间戳。

    感觉至少是不方便用 ORM 来做了,不知道还有什么其他的优缺点,读写性能和存储上的考虑之类。
    或者有没有可能的替代方案
    31 条回复    2018-09-19 17:40:31 +08:00
    sampeng
        1
    sampeng  
       2018-09-18 11:55:13 +08:00
    你这个需要 nosql。。100 列。。。mysql 之类不是不可以。。就是存储各方面都会变得大。哪怕你留空
    kelthuzadzbt
        2
    kelthuzadzbt  
       2018-09-18 11:55:23 +08:00
    可以存 json 字符串吗,日志表存{pid:v} pid 对应列名在另一个表里的主键 id,100 多列的话;
    ps:菜鸟 轻喷
    betulachen
        3
    betulachen  
       2018-09-18 12:17:09 +08:00
    换数据库,rrd
    nullcoder
        4
    nullcoder  
    OP
       2018-09-18 12:20:11 +08:00 via Android
    @kelthuzadzbt 关系型数据库一般不用这种设计
    nullcoder
        5
    nullcoder  
    OP
       2018-09-18 12:21:06 +08:00 via Android
    @betulachen rrd 全称是什么?
    hjc4869
        6
    hjc4869  
       2018-09-18 12:30:27 +08:00
    数据冗余,浪费空间。
    有些情况下性能可能好一些,因为不需要多表查询。不过一般写业务还是尽可能 3NF
    hcymk2
        7
    hcymk2  
       2018-09-18 12:51:53 +08:00
    可以尝试下时序数据库。
    littlewing
        8
    littlewing  
       2018-09-18 13:04:27 +08:00
    nosql 或时序数据库
    nullcoder
        9
    nullcoder  
    OP
       2018-09-18 13:05:16 +08:00 via Android
    @hjc4869 数据冗余在哪里?
    100 列一个时间戳和一个识别字段还好吧
    betulachen
        10
    betulachen  
       2018-09-18 13:27:40 +08:00 via iPhone
    百度 rrd 数据库第一条就是
    wingyiu
        11
    wingyiu  
       2018-09-18 13:39:46 +08:00
    hbase
    reus
        12
    reus  
       2018-09-18 13:53:29 +08:00   ❤️ 2
    postgresql + json 列
    关系数据库当然可以这样设计,还能用列内的值创建索引
    yejinmo
        13
    yejinmo  
       2018-09-18 13:57:19 +08:00
    实时数据库了解下?
    ebingtel
        14
    ebingtel  
       2018-09-18 14:05:19 +08:00
    我宁愿用 E-A-V 的方式存储,<id、列名、值>
    wccc
        15
    wccc  
       2018-09-18 14:10:53 +08:00   ❤️ 1
    时序数据库 influxdb 前东家做法
    loveCoding
        16
    loveCoding  
       2018-09-18 14:11:40 +08:00
    hjc4869
        17
    hjc4869  
       2018-09-18 14:25:21 +08:00
    @nullcoder 理解错了, Sorry.
    LadyChunsKite
        18
    LadyChunsKite  
       2018-09-18 14:33:53 +08:00
    @reus 为什么不用 hstore ?
    reus
        19
    reus  
       2018-09-18 16:12:58 +08:00
    @LadyChunsKite jsonb 可以完全替代 hstore
    nullcoder
        20
    nullcoder  
    OP
       2018-09-18 16:47:40 +08:00
    @ebingtel 这样缺了时间戳,如果加上冗余量就大了
    viver
        21
    viver  
       2018-09-18 17:03:13 +08:00   ❤️ 1
    postgresql 支持 json,可以考虑下
    nullcoder
        22
    nullcoder  
    OP
       2018-09-18 17:15:31 +08:00
    @reus @viver 看了一下,这种方案还是很方便的。
    这种设计有没有什么可能的缺点呢?
    opengps
        23
    opengps  
       2018-09-18 17:20:23 +08:00
    看具体业务规则,以我做过的 gps 监控为例子,曾经用过关系型数据库:时间列聚集索引达到类似于“时序数据库”的效果。这张表也用途也设计的超级简单(花了很大精力实现“简单”),单行密集写入,按时间区间批量读取。
    gfreezy
        24
    gfreezy  
       2018-09-18 18:18:05 +08:00
    只取少量字段的时候稍微慢一点吧。MySQL 行存储需要遍历更多的数据。
    absente
        25
    absente  
       2018-09-18 18:47:11 +08:00
    列的多少一般不是问题(当然是有上限的)。一个 erlang 程序随随便便几百上千的微线程,一样跑的好好的。不同之处在于,行式关系型数据库,是一个 x 乘以 y 的关系(如果数据充足)。列式数据库就没这个问题,当然,这已经算 nosql 了
    wizardforcel
        26
    wizardforcel  
       2018-09-18 22:03:11 +08:00 via Android
    日志最好存 nosql,因为( 1 )不需要事务,( 2 )不怕丢失
    liprais
        27
    liprais  
       2018-09-18 22:35:08 +08:00
    pgsql 搞定
    luozic
        28
    luozic  
       2018-09-18 23:41:24 +08:00 via iPhone
    你这明显是时序数据,又没有多少需要关联的,直接走时序数据库不就搞定了,不过为了后面扩展可以搞 pgsql+json
    nullcoder
        29
    nullcoder  
    OP
       2018-09-19 09:05:37 +08:00
    @wizardforcel 不是日志,是数据记录,后面会用来做分析。
    viver
        30
    viver  
       2018-09-19 14:03:57 +08:00
    @nullcoder pgsql 在数据量比较大的时候(包含 json,并且对 json 进行操作),应该只适合数据的写入和读取,如果对单个 json 的 key 值进行操作,效率都会比较低,决解这个问题可以维护基于 json 串的 GIN 索引。数据量小的话,读写性能和普通的字段应该差距不大,建议是 pgsql 只用来数据的存储,对数据的操作尽量在代码层面上搞定。
    nullcoder
        31
    nullcoder  
    OP
       2018-09-19 17:40:31 +08:00
    @viver 现在看因为原始数据一般是类似与 int 数组,所以可能不考虑 json 这种方案了。
    目前主要业务在关系型数据库里,配置时序数据库需要多数据源的配置处理,还在了解这块。
    现在先简单考虑用反射机制解决 ORM 对象属性过多问题。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2204 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 11:29 · PVG 19:29 · LAX 03:29 · JFK 06:29
    ♥ Do have faith in what you're doing.