作者回复: 你好,之所以强调写多读少,因为写操作的负载只能是单体数据库的主节点上,是无法转移的;而读操作,如果对一致性要求不高可以转移到备节点,甚至在某些条件下还能保证一致性。就是说单体数据库可以通过一主多备解决读负载大的问题,而无需引入分布式数据库
作者回复: 呵呵,别急哈,一周更三篇。
作者回复: 总结的很好,log is database是aurora类数据库的设计思想。
作者回复: 你好,说的很好。不能多写,这点很关键,适用场景会有很大区别,所以这是一个重要标准。但是,因为Aurora是基于共享存储的,所以说它是分布式也不是没道理。我们定标准的目的,只是为了让学习的思路更清晰。
作者回复: 你好,如果需要交易代码配合做出补偿和回放,这很可能意味着它不是分布式数据库。在分布式数据库成熟前,确实有不少应用代码配合单体数据库的方式。这类应用代码也会被抽离出来形成独立的框架,如果你感兴趣,可以研究下阿里的SOFA。
作者回复: 你好,这里没有纳入Aurora,是因为它架构不支持对写入负载的横向扩展。当然,对很多小规模的应用来说也足够了,所以这不影响它取得商业成功。
作者回复: 你好,首先我对MyCat的最新发展了解的不多。个人认为随着分布式数据库的发展,MyCat这类中间件的市场会越来越小。当然,它的使用场景也可能转向对异构数据库的支持,就像Presto那样。
PolarDB和Aurora的架构类似,计算与存储分离,计算节点垂直扩展,存储节点水平扩展。这意味着它的写入能力是有上限的,但是因为简化了日志的存储,和其他一些优化,单节点能力比普通的MySQL好强很多。
作者回复: 这个还是挺多的,最典型的是MPP架构数据库,比如Greenplum和华为的GaussDB 200,它们的内核都使用了PostgreSQL。此外,还有Vertica。OLAP不再强调事务的支持,如果弱化了对数据更新的要求,很多大数据生态的产品就都可以纳入进来,比如Clickhouse,Hive on spark,甚至Kylin都可以算是广义的OLAP分布式数据库
作者回复: 分布式数据库和分库分表的最大区别在于,分布式数据库的使用体验是非常接近关系型数据库的,不需要应用进行额外的控制,这就降低了代码的开发难度。而分库分表方案在分布式事务和跨节点查询等方面,通常支持的都不好。
作者回复: 你好,首先,OLTP的写多读少,是指请求数量。互联网确实可以通过通过一主多满足“读多写少”的场景,但前提是对读对一致性要求较低。而在金融场景中,很多读操作依然是无法在备库运行的,就是一致性不满足要求。所以,我觉得对互联网也不能一概而论,还是要区分场景。有关一致性的话题,我在02/03会具体讲解,你可以先看看,我们再讨论。
作者回复:
嗯,AWS的拳头产品,云原生数据库,还是很有特点的。
作者回复: 谢谢,希望不辜负你的期待