1
misaka19000 2021-04-09 23:00:12 +08:00
lsm
|
2
chendy 2021-04-10 03:25:58 +08:00
同 1 楼,LSM
但是,用户名变更记录 也不是 写多读少 的啊…… |
3
tonyaiken 2021-04-10 05:53:54 +08:00 via iPhone
只能修改 3 次,也就是大多数时候应该不让修改,所以写应该少于读吧?
|
4
ryd994 2021-04-10 06:11:22 +08:00 via Android
每次改用户名你不还得检查一次
所以读的次数大于等于写的次数 |
5
raaaaaar 2021-04-10 09:35:20 +08:00 via Android
不是读更多吗
|
6
crclz 2021-04-10 10:03:27 +08:00 1
读多写少:MySQL
读少写多:MySQL 业务量大:选择比关系型数据库更适合的 |
8
opengps 2021-04-10 11:11:05 +08:00 via Android
题目写错了,对于大部分人的业务情况都是读远远大于写,一般初步考虑读写分离,缓存等方案,远期考虑分布式存储
对于写远远大于读的场景现实中偏少,大部分人能接触到的一般是日志系统,iot 存储业务一类,我个人有个特别典型的经历是 gps 写入模块 |
9
jorneyr 2021-04-11 13:59:56 +08:00
先写到 kafka 里慢慢更新到数据库吧,数据库能够满足存储的都差不多。
|
10
zhangysh1995 2021-04-13 15:54:47 +08:00
MySQL 有不同的存储引擎,可以考虑做替换,ARCHIVE 不知道合适不?
|