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

各位大佬对预测数据存储有什么好的方案吗

  •  
  •   y0bcn · 2022-03-16 13:55:00 +08:00 · 1204 次点击
    这是一个创建于 1012 天前的主题,其中的信息可能已经有所发展或是发生改变。

    发布时间:t

    预测时间范围:t-->Δi

    现有方案 1:

    发布时间 预测时间 预测项 1 预测项 2 预测项 3 预测项...
    t1 t1+Δ v v v v
    t2 t2+Δ v v v v
    t… t...+Δ v v v v

    有点:心智成本低,读写方便

    缺点:记录数多且查询性能较差,建索引后查询性能有所提升但插入速度较慢

    现有方案 2:

    发布时间 Δ1 Δ2 Δ3 Δ… Δi
    t1 V1 V2 V3 V… Vi
    t2 V1 V2 V3 V… Vi
    t… V1 V2 V3 V… Vi

    优点:可有效降低记录数量,提高查询效率

    缺点:进行各种计算时心智成本过高,代码质量难以保证

    现在用 MySQL 硬存,有以上两种方案,发现要么性能差,要么心智成本高,想跟各位大佬取取经 可以尝试 newSQL ,了解了时序数据库感觉好像也不是特别合适?因为时间会有重合

    4 条回复    2022-03-17 14:05:34 +08:00
    dayeye2006199
        1
    dayeye2006199  
       2022-03-17 05:19:10 +08:00   ❤️ 1
    得分析一下你的下游是怎么使用这个数据的。

    我们做过和你的同样的应用,下游需要支持按照发布时间+预测时间作为查询条件的查询和时间上卷操作。
    所以方案 1 对这个需求支持是最好的。

    对发布时间和预测时间需要建立索引。

    数据量如果非常巨量的话,考虑对发布时间或者发布时间的区间(例如一周)做 partition 进行分表操作。

    方案 2 虽然数据更加紧凑,但是下游的查询是真的难写,不推荐。
    y0bcn
        2
    y0bcn  
    OP
       2022-03-17 08:37:17 +08:00
    @dayeye2006199 感谢回复,目前采用方案 2 ,确实下游查询非常难写,做法是将数据查出来后进行拆解转换,来简化开发,但是感觉这样的代码实在是难以维护,还是想办法提高方案 1 的性能才是好的方案。
    zmal
        3
    zmal  
       2022-03-17 11:33:28 +08:00
    方案一中“建索引后查询性能有所提升但插入速度较慢”,感觉写入速度不应该是瓶颈...mysql 写入有不少优化方案,真心数据量特别大还可以 load data 。
    y0bcn
        4
    y0bcn  
    OP
       2022-03-17 14:05:34 +08:00
    @zmal 好的,感谢提醒,我去学习一下
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2633 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 07:05 · PVG 15:05 · LAX 23:05 · JFK 02:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.