• leslie
    2019-08-30
    老师的结语中其实有一点有误:"从使用界面角度,我们要考虑关系型数据库还是文档型数据库,以及是否需要事务特性",文档型数据库其实只是非关系型数据库中的一种,而不是一类,键值存储redis同样是非关系型数据库,早期的memcache;其实它们有个共同的名称-内存数据库。
            关系型数据库和非关系数据库的关系不是相互取代而是相互补充:MYSQL 8.0已经引入了非关系数据库的部分特性补充和强化自己;其实随着内存数据库的崛起,已经从数据库+数据仓库的模式改变成内存库+数据库的模式,数据仓库在内存库的彻底崛起后彻底基本退出了舞台;之前实时数据存储在数据库中,数据定期存到数据仓库中;现在大多数就存放在内存库中定期落地,数据落地就可能造成延时。这个就像20年前数据库每天都会做全备,可是现在数据库的备份可能都是只有重大升级才会做,完全靠增量备份+日志。
            消息队列的出现又是为了一定程度减轻内存库的压力,多重类型并存;如何合理利用各种工具,让数据库发挥自己的特性扬长避短一直是从业多年致力研究的事情-其中就包括关系型和非关系数据库;由于消息队列的特性为了合理发挥RDBMS+NOSQL+MQ的最大效率,在强化自己的操作系统和计算机组成原理,力争做到组件的负载均衡;以上算是个人近10载DBA兼系统运维或系统运维兼DBA的一点薄见。
    展开

    作者回复: 多谢补充。我目前的确没有把redis归类到数据库,而是归类的类似memcache的内存缓存。

    
     12
  • 不动声色满心澎湃
    2019-11-10
    、这些话题公司都有在说,然后这边也是一笔带过,目前为止,对我没什么帮助。
    
     2
  • 兢
    2019-09-02
    文中提到”为了避免版本回退,写操作应该确保至少有一个从节点收到了最新的数据。”
    请问是如何确保至少有一个从节点收到了最新的数据,是每个写操作后都去验证一遍从库是否同步数据成功吗?如若是这样的话那如何去平衡效率问题?

    作者回复: 这个具体就仁者见仁智者见智了,方法总比困难多😁

     1
     2
  • CrazyAirhead
    2019-09-01
    https://pingcap.com/blog-cn/tidb-internal-1/

    https://pingcap.com/blog-cn/pessimistic-transaction-the-new-features-of-tidb/
    一起看看这两篇效果更佳。

    作者回复: 多谢推荐

    
     2
  • Dean
    2019-08-30
    老师谈到CAP理论,目前感觉绝大多数系统都需要P,只能在C和A之间做取舍,对于A其实大部分场景也不能放弃,所以最后只能在C上退让。在出现网络分区后,仍然尽量处理请求,但各分区之间会有数据不一致的情况。老师可以说说哪些系统是绝对支持C的吗?

    作者回复: mongodb 就可以选择不同的一致性模型,可以选择强一致性。

    
     2
  • Dimple
    2019-11-18
    最近几个月项目原因,没能继续,现在重新回来跟着老师学习了。希望能慢慢赶上老师的节奏
    
     1
  • Rainman
    2019-09-22
    “P简单来说,就是网络出现分区(变成两个相互独立的集群)时,是不是还可以正常提供服务。如果可以正常服务,说明分区容忍度高。” 这里借用下老师的解释。
    因为网络本身无法做到100%可靠,有可能出故障,所以分区是一个必然现象。如果我们选择了CA,放弃了P,那么当发生分区现象的时候(就是两个独立的集群,相互通信不了),该如何保障这两个集群的数据一致性呢(我们假设这两个集群是主从关系,主的数据同步给从,网络分区后,他们俩就通信不了)?
    
     1
  • williamcai
    2019-09-01
    老师,CAP中的P,这个概念有点不太懂,百度了一下好多不一致的说法,老师能解释一下吗

    作者回复: P简单来说,就是网络出现分区(变成两个相互独立的集群)时,是不是还可以正常提供服务。如果可以正常服务,说明分区容忍度高。

    
     1
  • Aaron Cheung
    2019-08-30
    打卡 37
    
     1
  • 靠人品去赢
    2019-08-30
    这个主从关系,我理解就是我们说的读写分离,可以分担一些压力,但有的时候确实需要最新的数据,比如提交订单了,显示余额,要最新的肯定是主库查。那问题来了什么时候主库什么时候分库呢?如果是浏览商品可以salve查余额,金额变化了就要查master主库,单纯的从业务上来判断吗?是不是做不到真正的读写分离?

    作者回复: 理论上读写分离是可行的,因为写的时候需要保证应该一主一从写成功,那么如果能够确认某个slave总是最新的话,可以分担读。

     1
     1
  • 饭
    2019-08-30
    老师,一直不太明白,文档型数据库什么情况下应用会比较合适了?公司项目都是把他当临时缓存在用,把一些调用频繁的json格式的数据存上面。我不太理解,用redis不也可以了吗,还轻量级一些。

    作者回复: 的确算误用。缓存和存储是两码事。

    
     1
  • Eternal
    2019-11-10
    分布式数据库会是未来的主角吗?老师讲的分布式场景下,数据库的瓶颈是整个系统的最大瓶颈,如果分布式数据库能做到数据动态伸缩节点,且能保证数据的可靠性和低延时,那么分布式数据库就能大面积替换MYSQL 和Oracle了,
     1
    
  • subfire
    2019-10-23
    老师, 实践中一般用什么方法保证主从一致呢?

    作者回复: 主从一致是好保证的,只需要写操作只由主执行,从同步主的结果就好。这样数据就可以做到最终一致。

    
    
  • Charles
    2019-08-31
    老师说的,主从结构,主挂掉的情况下,两个以上从选举行为MySQL中是自动完成的吗?主恢复的时候,还需要额外做什么操作才能恢复原来的主吗?

    作者回复: MYSQL 并不会自动做主从切换,更没有自动选举方式来切换。从这个意义来说,MYSQL 并不是“现代”数据库。

    
    
  • Jxin
    2019-08-30
    大佬的课,至今没有一篇能一遍看懂的,除了这篇。所以说这篇讲得太浅,无论是具体的技术,还是之上的思想都太浅。这有失大佬水准。之前的文章能力有限留言不了,这篇却是没什么点可以留言的。

    作者回复: 我们大部分基础平台或基础软件相关的内容是以需求分析和平台的关键点解剖为主,并不是以内容深浅为准则。很难保证每一篇都有高深的东西。上一篇关于存储中间件的通用话题讨论完了,这一篇基本上就只能谈很具体的数据库相关的领域需求了。

     2
    
  • 许童童
    2019-08-30
    跟着老师一起精进。
    
    
  • humor
    2019-08-30
    如果事务提交的时候发现和其他已提交事务冲突,则放弃该事务,对所有修改进行回滚(其实是删除该事务产生的版本修改记录)。
    Mysql的InnoDB会有这种情况出现吗?我理解的InnoDB应该是在事务更新时会加行锁或者间隙锁,如果另外一个事务也对锁范围内的行做更新的话,会一直阻塞直到前一个事务执行完毕释放锁或者超时吧。

    作者回复: InnoDB 的确不是用乐观锁。

    
    
  • 大糖果
    2019-08-30
    老师好,看完文章对数据库有了一个整体概念,老师说如果有兴趣可以参考相关的资料。那么这个相关的资料有什么推荐吗?

    作者回复: 后面这一章的总结篇会给一些参考

    
    
我们在线,来聊聊吧