写多读少的数据应该如何高效存储？

• 資深大佬 : misaka19000

  lsm

• 資深大佬 : chendy

  同 1 ，LSM
  但是，用户名变更记录 也不是 写多读少 的啊……

• 資深大佬 : tonyaiken

  只能修改 3 次，也就是大多数时候应该不让修改，所以写应该少于读吧？

• 資深大佬 : ryd994

  每次改用户名你不还得检查一次
  所以读的次数大于等于写的次数

• 資深大佬 : raaaaaar

  不是读更多吗
• 資深大佬 : crclz

  读多写少：MySQL
  读少写多：MySQL

  业务量大：选择比关系型数据库更适合的

• 資深大佬 : GrayXu

  @crclz MyRocks 可能比较适用写多？

  只是保存“变更记录”的话，那写的比例还是比较高的，虽然不是写多读少。

• 資深大佬 : opengps

  题目写错了，对于大部分人的业务情况都是读远远大于写，一般初步考虑读写分离，缓存等方案，远期考虑分布式存储
  对于写远远大于读的场景现实中偏少，大部分人能接触到的一般是日志系统，iot 存储业务一类，我个人有个特别典型的经历是 gps 写入模块

• 資深大佬 : jorneyr

  先写到 kafka 里慢慢更新到数据库吧，数据库能够满足存储的都差不多。

• 資深大佬 : zhangysh1995

  MySQL 有不同的存储引擎，可以考虑做替换，ARCHIVE 不知道合适不？