李玥置顶2020-04-18Hi，我是李玥。 这里回顾一下上节课的思考题： 我们要做一个日志系统，收集全公司所有系统的全量程序日志，给开发和运维人员提供日志的查询和分析服务，你会选择用什么存储系统来存储这些日志？原因是什么？ 对于这个问题，仍然需要根据业务对数据的查询方式，反推数据应该使用什么存储系统。对于日志的查询，最常用的二种方式就是按照关键字去查询或者指定一个时间和IP去浏览。 如果说，日志的量级不超过TB级别，直接放到ES里面最省事，对于二种查询方式都可以获得还不错的查询性能。如果规模太大了，ES也扛不住的情况下，可以考虑把日志放到HDFS中，对于浏览的查询需求，直接定位的具体的日志文件返回是比较快的。对于关键字查询的需求，也可以通过实现Map-Reduce任务，并行查询然后聚合的方式来实现。28
一步2020-04-18New SQL 数据库是不是都是这样设计的？ 执行器支持 SQL，然后底层的存储系统是分布式存储系统？ 区别在与底层的分布式存储系统实现的原理不一样？作者回复: 是的，底层的分布式存储引擎也是差不多的，大部分都是KV。
8
真名不叫黄金2020-04-27老师讲得非常好~ 不过我有一个小问题想请教一下老师，文中说到MySQL的RR级别是没有Write Skew的，但是RR使用的是MVCC读，也是快照读，理论上也会有Write Skew问题，我刚刚测试了一下，RR的事务中进行读取，是快照读不加锁，如果将老师文中的子查询拆分出来，向上提，先进行子查询的余额检查，再进行更新，开启2个事务分别更新父子账户，父账户先读取检查余额，人为没问题，然后子账户读取检查余额，也认为没问题，然后子账户更新余额并提交，父账户更新余额再提交，两个事务都可以成功，但余额不满足业务约束了，也就是Write Skew了，所以说我的理解是，RR是可能会出现Write Skew的，不知道理解有没有问题作者回复: 我们倒不用纠结这个概念，按你设定的场景，确实会出现不满足业务约束的情况，所以一定要把约束写到更新语句中。
共 2 条评论4
一剑2020-04-27例子中，主卡更新和副卡更新同时在两个事务里执行，容易导致死锁吧？作者回复: 这里面不会发生死锁，主卡和副卡分别是二个账户，而且不需要同时持有这2个账户的锁。
leslie2020-04-18不知道老师是否有发现一点，现在大量的Analyze DB在对之前的MYSQL或PG SQL做补充；首当其冲的应当是阿里最近推出的此类DB；tidb做为国产数据库-目前几乎聚集了国内大多所有的RMDB方面的神人，应当是继OceanBase之后又一个国内真正汇聚顶级DB相关人才打造的数据库。老师如何去看待tidb? 谢谢老师的分享，期待后续的继续分享。共 2 条评论9
苗2020-05-14mongodb 4.2.6也支持rc和rr级别的事务了；老师似乎很少提到mongodb。8
icyricky2020-04-18公司有用TiDB…感觉架构很像…还是leader任期之后的续租还是选举，多数票同意选出leader，follower从leader复制数据…检测心跳…在leader宕机之后发起新一轮选举；leader对外提供读写服务，避免数据不一致共 6 条评论5
QQ怪2020-05-14我项目用的就是小强db，的确是有写性能比不上mysql，也出现了相关的锁竞争导致事务回滚的问题，解决了事务问题往往带来了其他新的问题，所以说newSQL并不是什么技术银弹:-D4
Lukia2020-04-18不知道cockroach的两种隔离级别是不是借鉴了postgres的做法共 1 条评论2
健行2023-09-12 来自上海老师有个点说错了。 从维基百科上可以查到，NoSQL的意思是Not only SQL。像mongoDB，支持了SQL也提供的更多方便的功能。