阿里的云数据库是如何打败Oracle的
本帖最后由 晨枫 于 2020-9-2 18:32 编辑https://www.guancha.cn/daju/2020_09_03_563860_s.shtml
有意思！阿里从“用不起”IOE开始，到IOE“吃不下”双十一，最终走上自己的云数据库的路。云数据库会碾压Oracle吗？触发事件可能是数字货币，传统数据库可能很快就要爆满。
至于坛里总有人把阿里云贬为“不就是偷人家的开源”，自己看看吧，别信口开河。 这个我可以说一嘴。OceanDB应该算是Distributed SQL(分布式数据库)，应该跟TiDB，Google Spanner 去比。跟Oracle比是降维打击，太欺负人了。
Oracle作为单机时代数据库系统的老大，天生不适合双十一这种海量，高并发的use case。哪怕单机的传统地盘也被新的开源DB MariaDB, Postgres 蚕食。
Oracle和IBM DB2， Microsoft的SQL Server一样， 已经是日薄西山了 阳振坤是王选的学生，748嫡系。 晨老大，赶紧准备钢盔，口水冰雹即将来袭。 我一直以为晨枫是搞IT的 不知道SAP HANA数据库表现怎么样，至少在ERP方面SAP碾压甲骨文 本帖最后由 无言 于 2020-9-3 12:20 编辑
togo 发表于 2020-9-3 11:50
不知道SAP HANA数据库表现怎么样，至少在ERP方面SAP碾压甲骨文
SAP本行是ERP然后收了Sybase，甲骨文本行数据库收了Peoplesoft。 斯基每回一出圈IT，必然应者云集。{:188:} 阿里云数据库性能显然已经超过开源了，拿来主义的模范。{:222:} 其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。 红茶冰 发表于 2020-9-3 07:40
其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。 ...
对，这个每年春节开放购票时的瞬时冲击也是奇观，集中式数据库怕是挡不住 红茶冰 发表于 2020-9-3 08:40
其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。 ...
这个在未名空间吵成一锅粥，基本分成两派，一派是做金融交易平台的，一派是做网站平台的，完全两条路子，可都走得通 阿忙 发表于 2020-9-4 01:36
这个在未名空间吵成一锅粥，基本分成两派，一派是做金融交易平台的，一派是做网站平台的，完全两条路子， ...
两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息要实时更新反应同时又是几百T甚至几千T的流量，与金融平台所考虑的核心关键问题都是一个，延迟
办法只有一方案，第一 硬件方面将所有可能需要实时调取的数据全部内存化 第二 优化各种协议算法。常规的所谓云之类的CDN加速也的重新改，否则一样玩不转。
所以从这件事完全可以看出咱们的网络战备力量还是很强大的，这种涉计到网络最核心的问题都能自足解决了，完全说明无论是人员素质还是设备的冗余程度以及可靠性都没话说的。 红茶冰 发表于 2020-9-4 02:23
两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息 ...
这个是很牛的，关键美国没有这种需求。
IBM中国最开始都是美国专家帮助，后来只能自己搞，美国银行没有那么大的交易量，专家也没遇到过中国的问题。 可梦之 发表于 2020-9-4 03:28
这个是很牛的，关键美国没有这种需求。
IBM中国最开始都是美国专家帮助，后来只能自己搞，美国银行没有 ...
物联网时代，美国也会遇到同样的问题的。 红茶冰 发表于 2020-9-3 13:23
两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息 ...
没那么神奇，其实不过是尽量都搁在内存，然后死了命地玩cluster，再加上限制数据一致性以降低同步所带来的性能压力。这样做的好处是交易量上去了，代价是数据一致性。
oceanbase的基础是mysql，经过魔改变成了以内存为中心、以数据一致性为代价的分布式数据库。
类似的体系设计方案，加拿大银行界也一样用。但是不以mysql为基础，而是用其它的in memory data store，一样能达到性能要求，但是却避免了数据一致性问题。 老福 发表于 2020-9-3 14:51
物联网时代，美国也会遇到同样的问题的。
物联网时代，是否会出现还是个疑问呢。 老兵帅客 发表于 2020-9-4 04:01
没那么神奇，其实不过是尽量都搁在内存，然后死了命地玩cluster，再加上限制数据一致性以降低同步所带来 ...
金融业务不可能放弃数据一致性的，OceanBase只是换了个方法去实现。
OceanBase解决ACID问题的方法，主要是靠增加备份，将三套OceanBase绑定在一起运行，一个主库，两个备库。只有当至少一个备库也完成任务时，主库才会完成这个任务，这样，任何一个任务至少被保存在两台服务器上，极大降低了事故概率。
传统数据库本身要保证一致性，每一步都要记录，出现错误要回滚到初始状态。这就造成了复杂的逻辑。
我的理解是OceanBase不再考虑这些小概率的错误处理，假设没有问题往下执行，万一出了问题，从备库恢复。这是云计算的典型思路。对业务来说，数据一致性是不变的，变的只是内部实现方式。
加拿大银行界的技术方案不了解，不过中国的业务量至少要大一个数量级，用的话也得魔改，这不就是OceanBase干的事儿吗？
每年黑五好deal 都很难抢到, 因为网站down了 本帖最后由 老兵帅客 于 2020-9-3 17:04 编辑
可梦之 发表于 2020-9-3 16:16
金融业务不可能放弃数据一致性的，OceanBase只是换了个方法去实现。
oceanbase玩花活的地方就在于数据一致性，这也是它致命的地方。它的解决方案是分两步走，本地尽量搁在内存里以保证性能，然后服务器同步到SSD硬盘以保证数据一致性，但是这个延迟本身是有危险的，因此它的对应方案是双机甚至多机热备份，以此来尽可能降低风险。这个方案本质上是用软件来替代传统数据库的交易实现，但是却无法根除风险。
这样的做法在中国也许行，但是在欧美则很难被认可，因为它破坏了数据库的基本原则，ACID，因为这个实现不是可保证的，而是非常近似可保证的，这个区别在商界会引起恐慌的。
加拿大这边的银行用这类思想处理的不是客户数据库，而是整个银行范围内的single sign on，也就是本银行所有应用的账户的SSO。由于对延时的要求非常高，传统数据库是不可能做得到的，只能在in memory data store上做文章，然后同步到硬盘以保证数据的保存，同时以多个服务器同步的方式提高服务的可用性。
传统数据库的问题之一就是完善的数据一致性带来了太多的性能损失，因此在追求极高交易量的情况下，只能适当牺牲数据一致性。但是如何保证可接受的数据一致性是关键。