作者回复: 👍👍👍
作者回复: 1. LSM使用WAL也是为了恢复memtable的数据的
2. 是不涉及事务的
3. 好的呀~
作者回复: 如果是长期都是写多读少,那么可以考虑nosql
如果是瞬时峰值的话,还是用消息队列削峰填谷
作者回复: 是的 应该是这样
作者回复: 大部分放在mysql,像是粉丝数据是在nosql
作者回复: 是的呀 比如你的业务数据放在mysql,索引数据放在es
作者回复: benchmark结果来看,nosql的写入性能要好一些
作者回复: 在实际运用中,nosql数据库比如leveldb确实比mysql有后来更好的写入性能
作者回复: 怎么会呢,分布式之后应该可以知道某个key在哪个分片上
作者回复: 微博的博文是放在MySQL里面的,其实博文的数量没有关系那么夸张,而且热点明显,用户很少会翻之前的微博。
订单的数据可能和博文的数据相当,我觉得放在mysql中应该就够了
作者回复: 其实这就是把MongoDB作为“缓存”了,是可行的
不过从描述来看,前端写入数据会更新MongoDB,再异步更新数据库;然后还会有一个消息队列会从业务数据库读取数据更新MongoDB,这两个是不是有重复?
作者回复: 可以缓解