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

• 資深大佬 : 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 万设备用。