经常访问的简单数据是不是放在内存为佳？

[Phishion]

我有一个任务，大概 15 秒要访问一次服务器配置以决定是否继续，服务器配置表其实就一条数据，表里面的内容也不多。

从性能角度来讲，是不是放到 Redis 里比较好？ Postgres 对于这样经常访问的数据应该也有优化才对，但是我看 Debug 日志倒是成片成片的，是不是眼不见为净就算了？

[msg7086]

是的，放在内存里比较好，所以你的数据库和你的操作系统都会把经常访问的数据存在内存里。

[7911364440]

加缓存的话需要注意下数据一致性

[Vegetable]

确实，但...
15 秒访问一次还考虑什么 redis 数据库？
放 redis 还要考虑持久化、可配置、一致性这三者怎么同时满足。还不如直接放数据库。你要是说 1 秒 15 次，还可以考虑缓存一下。

[securityCoding]

没啥问题为什么要改呢?

[matrix67]

一天也就 4* 60 *24 = 5760 次，数据库一秒的 pps 也不止这个数了

[thevita]

只看这点描述，完全没必要想这么多啊，所以忽略你的其他背景的情况下：
1. 先正确实现业务，用最熟悉的存储后端
2. 优化性能表现，最简单的就在 1 基础上插入一成缓存，最好缓存后端灵活点，单机就内存，replicate 就弄个外部的缓存

总结来说就是，都要

[Huelse]

就这个频率而言，你放 pgsql 里完全没问题，或者像楼上所说的，在程序层面加个缓存就够了

[eason1874]

小文件，15 秒访问一次，I/O 负担不值一提。放内存会稍微快一点，但也不明显

代码本身需要使用 Redis 那可以顺便放 Redis ，如果本身没用到就没必要专门去连接了，不放也不会有什么性能问题

[yidinghe]

这种没什么负担的，保持每 15 秒查一次数据库，无需引入复杂的设计，也有利于将来能减轻设计负担。

[dddd1919]

有限小批量数据放内存是最佳选择，但要注意多机一致性
如果量是递增的最好是放到 redis ，防止 oom 。但读频率非常高的话 redis io 也可能成为瓶颈，所以还是要看下实际业务情况权衡

[karloku]

15 秒一次这个访问频率没必要引入额外的 redis, 放在 pg 里就够了.
如果已经有现成的 redis, 而且不是做缓存用途是作为数据库的, 倒是可以选择放进去

[Feiex]

15 秒一次实在没必要，除非这个过程对整体系统有较大影响

[loading]

如果确实像放内存，可以先试一下 sqlite3 内存模式，你可以容易接受（上手）一些。

[shayuvpn0001]

放在 CPU 的 Cache 里

[adoal]

15 秒一次何必这么紧张…还以为是抢鸡蛋呢

[jusonalien]

访问频率这么低。。。没必要过度优化

[sagaxu]

15 秒访问一次，QPS ~= 0.066 ，但是如果 10 万设备在线呢，马上 6666 了。
如果每次请求产生 10 次 read 和 3 次 write ，那就 9 万次读写了，偶尔小高峰抖一下轻松破 10 万。

[ch2]

又不是 15 毫秒

[TomVista]

上 cdn 协商缓存更有效,扔内存,治标不治本

[saulshao]

@sagaxu 他这是个定时任务，按道理跟并发没啥关系...即使有，完全可以服务器端访问一次，然后并发给 10 万设备用。