V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
XiaoFaye
V2EX  ›  程序员

讨论一下,什么情况下可以把数据全部加载到内存

  •  
  •   XiaoFaye · 2017-05-11 05:25:10 +08:00 · 4049 次点击
    这是一个创建于 2754 天前的主题,其中的信息可能已经有所发展或是发生改变。

    一些只读表数据不大,可以启动时直接全部加载到内存以便使用吗?

    平时大家会不会这样做?如果这样做的话,一般以什么为标准?比如占用内存低于 100M 的都直接加载?

    18 条回复    2017-05-12 09:10:13 +08:00
    ryd994
        1
    ryd994  
       2017-05-11 06:51:14 +08:00 via Android
    没有必要,正常情况下文件都是有缓存的,性能根本不用担心
    如果你是觉得用着不方便的话,mmap
    msg7086
        2
    msg7086  
       2017-05-11 07:31:02 +08:00
    不会。操作系统已经帮你加载到内存了,为什么要加载第二遍。
    k9982874
        3
    k9982874  
       2017-05-11 07:39:10 +08:00 via iPhone
    经常访问的必须加载到内存
    偶尔访问一下的没必要
    XiaoFaye
        4
    XiaoFaye  
    OP
       2017-05-11 07:59:28 +08:00
    因为数据都在数据库里面,频繁地从数据库读出来不太好吧?
    Mbin
        5
    Mbin  
       2017-05-11 08:29:11 +08:00 via iPhone
    如果是线上业务,访问量比较大,数据加载到内存是必须的,不然 io 撑不住的,同 redis 这种一个道理。
    whileFalse
        6
    whileFalse  
       2017-05-11 08:56:39 +08:00
    只读又频繁的当然可以。
    比如全国省市列表之类的。
    不过如果要更新,就得更新完之后重启服务了。
    ebony0319
        7
    ebony0319  
       2017-05-11 08:59:58 +08:00
    如果内存大的话其实可以做一个内存盘。
    QQ2171775959
        8
    QQ2171775959  
       2017-05-11 09:05:02 +08:00
    各种方法都可以实践一下,多个方面进行对比综合分析,然后选出来一个比较适合自己方案的方法,这样子才更有说服力一些。
    ryd994
        9
    ryd994  
       2017-05-11 09:19:45 +08:00 via Android
    @Mbin 如果是只读,全都在缓存里,根本碰不到磁盘,速度就是内存带宽。要是内存带宽都满足不了的话,怎么做都没用。强行保留在内存里,只会妨碍操作系统的内存管理。mmap 也是利用缓存。
    对于数据库,性能难点不是读性能,而是同步写入还要保证一致性。Redis 重要的是利用内存的随机访问特性。毕竟一般数据库是假设数据在硬盘上,主要是对硬盘的访问特性优化。
    edenpan
        10
    edenpan  
       2017-05-11 10:10:22 +08:00
    看数据大小了吧,配置类的数据如果不是很大,加载到内存里面使用要好些吧。而且一般配置类的数据也不大。当然如果内存够大,似乎可以全部到内存里,反正这样快。
    zhujinliang
        11
    zhujinliang  
       2017-05-11 10:19:27 +08:00
    我干过
    软件 B/S 结构,有个 html 页面的文件包,文件包是压缩的,我图方便,就在软件启动时读入文件包,解压到一个 hashtable 里,之后请求文件时直接从 hashtable 读 23333
    troycheng
        12
    troycheng  
       2017-05-11 10:35:18 +08:00
    这个个人觉得没有统一标准。需不需要考虑性能问题,取决于你是否真的存在需要压榨性能的场景。而脱离场景的优化,要么属于学习研究范畴,要么属于炫技。

    在有流量压力的系统里,比如访问压力较大的站点,这种多读少改或者基本不怎么改的数据,可以本地缓存(各种你熟悉的方式)放在内存里,减少 DB 连接耗时以及对 DB 连接无谓的消耗,代价是需要集中分发和允许小概率个别不一致的情况。

    如果不存在这方面的场景,比如一天也没多少量的服务,用你最容易理解最容易维护的方式去写就好了
    XiaoFaye
        13
    XiaoFaye  
    OP
       2017-05-11 10:47:45 +08:00
    @troycheng 因为是固定范围的产品,所以数量不会多到哪里去,撑死了放内存也就 100M,但是操作非常频繁,因为大部分使用场景都是对这些数据的检索,另外每天午夜都会有一次定时更新,到时当然要重新生成 Cache,就是不知道值不值得这样做。
    troycheng
        14
    troycheng  
       2017-05-11 11:15:05 +08:00
    @XiaoFaye 说一句原来 BD 里面常说的看起来很对但好像又没什么帮助的废话:权衡一下你这样做的代价,和带来的收益。

    这里的收益暂且粗分为两方面:1. 是否更快了(数值上和感观上),乘以它的使用量; 2.是否更容易维护了(自己和别人是否容易懂和容易改)

    如果就没有显著的快,又没几个人用,改起来还麻烦,那自然就没必要了。如果数值上有明显的变化,访问的量又很大,那付出一点代价也是值得的。
    qiukong
        15
    qiukong  
       2017-05-11 11:23:03 +08:00
    论数据库服务器 SSD 硬盘的重要性
    julyclyde
        16
    julyclyde  
       2017-05-11 22:43:34 +08:00
    能满足需求:更快
    需要的代价:启动初始化阶段加载数据相比逐步加载更耗时、数据需要更新时如果逐步更新则相当于自己实现一套数据库的难度,如果一次性加载则相当于重新初始化一次,有很长的耗时,如果加载新旧两份则内存开销多一倍仅仅为了节省切换数据那段时间
    zhx1991
        17
    zhx1991  
       2017-05-12 00:07:50 +08:00
    一看需求, 二看量和变更

    有些数据, 高频使用, 内存读取肯定是最快的.

    如果量比较小, 比如一些配置文件或者是路由之类的东西, 那放在内存完全没问题. 不过要注意更新的处理.
    fiht
        18
    fiht  
       2017-05-12 09:10:13 +08:00
    热数据放内存,冷数据放硬盘。
    (具体还是要看业务场景,楼上的各位大佬已经讲得很清楚了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2699 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 10:29 · PVG 18:29 · LAX 02:29 · JFK 05:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.