设为首页收藏本站

爱吱声

 找回密码
 注册
搜索
楼主: 晨枫
打印 上一主题 下一主题

[科技] 阿里的云数据库是如何打败Oracle的

  [复制链接]
  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    21#
    发表于 2020-9-4 06:27:17 | 只看该作者
    老兵帅客 发表于 2020-9-4 06:01
    oceanbase玩花活的地方就在于数据一致性,这也是它致命的地方。它的解决方案是分两步走,本地尽量搁在内 ...

    要做到的是将风险降低到可以忽略不计的水平,就是传统数据库也做不到完全根除风险。只要oceanbase能将风险降低到传统数据库相同的水平,甚至更低的水平,就是可以用的,可以替代传统数据库的。金融业对一致性的要求极高,这也是oceanbase初期推广人们顾虑的原因。如果一致性很糟糕,是不可能大规模部署的。

    风险无处不在,只要够低没人care。硬件也有很多风险。每个flip-flop都有metastability的问题,无法根除,物理决定的。我们的方案就是将概率降低到宇宙灭亡都不会发生一次的水平,然后整个chip那么多flip-flop,整体保持在几十年几百年发生一次的水平。金融行业对一致性要求高,但用传统数据库,事故也是不少的。IBM给工行升级的时候,误操作把几个小时的交易给丢了,幸好是晚上,交易不多,人工补录上去。

    加拿大的方案我不懂,看你说的和oceanbase有什么区别吗?1. 放内存提高性能,2. 同步到硬盘,3. 多个服务器提高可用性。咋在oceanbase就是致命之处,不被欧美认可,咋加拿大搞就啥问题都没了?不是数据库专家,更不了解加拿大的方案。有错误之处请指正。

    正如你所说的,现在数据量大了,很多业务传统数据库做不到了。oceanbase这种路子,海外搞得可能更早,只是国内的数据规模更大。AWS也在搞,Oracle的舒服日子越来越不好过了。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:20

    评分

    参与人数 1爱元 +8 收起 理由
    方恨少 + 8

    查看全部评分

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    22#
    发表于 2020-9-4 06:42:29 | 只看该作者
    可梦之 发表于 2020-9-3 17:27
    要做到的是将风险降低到可以忽略不计的水平,就是传统数据库也做不到完全根除风险。只要oceanbase能将风 ...

    这个就算了吧,OCEANBASE是基于mysql魔改的,而mysql根本就不是政府以及主要商业用户的数据库选择,这个差距决定了oceanbase在主流数据库的很多方面是有缺陷的。作为交换,它得到的是高性能,如此而已。

    那么为什么国内那么多的数据库是从mysql魔改的呢,还不是因为那东西开源。但是要记住,开源的东西永远比不上收费的,否则这个商业世界就没办法运行了。

    阿里的东西,很多是别人的东西加了层皮。而它自己开发的那些东西,八哥太多了,因为缺乏足够的测试。

    再多的就不要扯了,马上就会有一堆人来骂我的。到此为止吧,论坛的公共版面,根本不是可以讨论的环境,因为有着太多的爱国者。

    加拿大这边的关键,在于那个不是存储客户数据,而是存储SSO数据,这个区别决定了即便它的数据一致性有问题也是可以重试的,因此不会造成商业恐慌。在这个世界上,技术方案可以有很多种,哪种能生存下来经常要看商业的需要,并非性能好是优势,风险在很多时候是更重要的考虑因素。

    现在的云服务数据库也多了起来,但是几个传统数据库还是主流。这点,无论是加拿大政府还是加拿大银行都一样,除非是非常小的非关键应用,否则没人会用mysql这类穷人的玩意儿。

    到此为止吧。

    点评

    涨姿势: 5.0
    涨姿势: 5
      发表于 2020-9-4 10:08
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    23#
    发表于 2020-9-4 06:54:55 | 只看该作者
    老兵帅客 发表于 2020-9-4 06:42
    这个就算了吧,OCEANBASE是基于mysql魔改的,而mysql根本就不是政府以及主要商业用户的数据库选择,这个 ...

    Oracle的数据库还是根据一篇paper改出来的呢。mysql和Oracle理论上有本质区别吗,没有,Oracle的好是工程优化的好。你也说了,oceanbase是mysql的魔改,mysql的一系列工程问题肯定解决了。否则支付宝也不敢用。事实是,支付宝去了IOE,并没有三天两头出问题,反而比银行系统更安全些。

    纯技术讨论。我对DB也仅仅了解皮毛。IT的理论突破越来越难,更多的是工程优化。最开始系统烂,优化得越来越好的情况比比皆是,比如vista/win7。不能轻易判人家死刑。毕竟都大规模商业应用了,我们能想到的问题,人家早都考虑过了。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:20
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    24#
    发表于 2020-9-4 07:00:55 | 只看该作者
    可梦之 发表于 2020-9-3 17:54
    Oracle的数据库还是根据一篇paper改出来的呢。mysql和Oracle理论上有本质区别吗,没有,Oracle的好是工程 ...

    mysql与oracle的确没有理论上的本质区别,但是确实有价格上的绝大差距,你能否说因为没有理论上的本质区别,二者的价格就不应该有这么大的差距吗?你能说选择了oracle的那些公司都是白痴吗?这里面肯定有区别的,而且有着相当大的区别。

    事实上,加拿大这边,只有小公司才会选择mysql,中等以上的公司根本不会考虑它作为关键应用的数据库,想想为什么吧。

    点评

    给力: 5.0
    给力: 5
    因为contractor用这方便,出问题还有人能背锅。哈哈哈  发表于 2020-9-8 04:51
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    25#
    发表于 2020-9-4 07:09:36 | 只看该作者
    老兵帅客 发表于 2020-9-4 07:00
    mysql与oracle的确没有理论上的本质区别,但是确实有价格上的绝大差距,你能否说因为没有理论上的本质区 ...

    我没说mysql和oracle没区别,我是说mysql和oceanbase也有区别,都魔改得爷爷不认了,不能用mysql的问题直接说oceanbase,对吧。

    能满足需求的技术就是好技术。很多IT公司,不管国内国外,都在去IOE。算起来还是Google开的头呢,AWS也是,这可不是小公司。IBM/Oracle守着传统的银行、金融、电信等业务,在新兴市场上几乎完败,日子越来越不好过,想想为什么吧。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:21
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    26#
    发表于 2020-9-4 07:18:29 | 只看该作者
    可梦之 发表于 2020-9-3 18:09
    我没说mysql和oracle没区别,我是说mysql和oceanbase也有区别,都魔改得爷爷不认了,不能用mysql的问题直 ...

    其实性能问题根本没必要像阿里这样做,多做应用服务器cluster+load balance,然后下面的数据库服务器分区玩同步,就啥都有了。

    难道我会告诉你,我在loblaw工作的时候,亲手设置了16台WAS来做load balance,然后另外16台WAS来做热备份。这样的服务器群的前面是IBM HTTP SERVER群。请求过来经过验证IP地址分流,走向不同的WAS,下面的数据库玩分区和同步,于是不管是多大的业务压力,只要能适当分流就没事了。

    顺便说一下别处看来的东西,貌似当初阿里选择这样的方案,是因为oracle太贵了。不知道真假,一笑。

    你说IBM/ORACLE在新兴市场上完败?想啥呢,加拿大这边的银行以及政府,我参与了不止一个项目,应用上云,数据库还是ORACLE。而安省政府,几乎就是被IBM产品垄断的。

    点评

    涨姿势: 5.0
    涨姿势: 5
      发表于 2020-9-4 10:09
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2020-1-2 12:07
  • 签到天数: 1 天

    [LV.1]炼气

    27#
    发表于 2020-9-4 07:18:54 | 只看该作者
    阿里的业务量应该是加拿大银行至少两个数量级, 没啥可比的。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:21
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    28#
    发表于 2020-9-4 07:20:24 | 只看该作者
    semtex 发表于 2020-9-3 18:18
    阿里的业务量应该是加拿大银行至少两个数量级, 没啥可比的。

    多玩分层分流就是了,参见26楼。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    29#
    发表于 2020-9-4 07:27:21 | 只看该作者
    老兵帅客 发表于 2020-9-4 07:18
    其实性能问题根本没必要像阿里这样做,多做应用服务器cluster+load balance,然后下面的数据库服务器分区 ...

    原文说了,Oracle满足不了需求了。Google确定是因为Oracle/IBM太贵,才开创的云计算。企业为了节省成本做技术创新,好笑吗?

    银行和政府不就是传统业务吗,都是不差钱+不想折腾的主儿,政府更是出了名的保守低效。从Google开始,FB,Uber,Airbnb。。。这些新兴IT企业,有多少用Oracle的,有多少不用Oracle的?

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:21
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    30#
    发表于 2020-9-4 07:32:58 | 只看该作者
    可梦之 发表于 2020-9-3 18:27
    原文说了,Oracle满足不了需求了。Google确定是因为Oracle/IBM太贵,才开创的云计算。企业为了节省成本做 ...

    企业为了节省成本而作创新,这个想法很好,但是确实省钱了吗?好好想想吧。

    我做那个SSO项目的时候,问过架构师,这样的架构能否用在客户数据处理上,回答是一个字,risk。这是个白人男的,三十多岁。

    到此为止吧,每次我都是给具体例子,你则没有具体的例子。这样扯下去,有意思嘛。

    打住吧啊。

    累了,看电视剧去了。起码,我能确定我得到些什么,而不是一堆的应该如何。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    31#
    发表于 2020-9-4 07:42:24 | 只看该作者
    老兵帅客 发表于 2020-9-4 07:32
    企业为了节省成本而作创新,这个想法很好,但是确实省钱了吗?好好想想吧。

    我做那个SSO项目的时候,问 ...

    你去问问Google有没有省钱了啊。像你说的,人家傻啊?

    OceanBase解决了Oracle解决不了的问题,大规模商用了多年,抗住了除了中国少有的海量请求,铁的事实面前,还纠着mysql的问题,抱着不到中国一个省人口的加拿大的应用,硬说人家不行,我也是服了。

    再给你一个例子。我朋友国内创业,做江苏电网的智能应用。江苏电网有几千万的智能电表,每天光数据都2T多。之前的Oracle/IBM系统根本处理不过来,云计算的方法很好的解决了这个问题。

    时代不同了,新问题要新办法了。


    点评

    给力: 5.0 +1: 5.0
    这真是极好的: 5.0 不能同意更多: 5.0
    涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:21
    给力: 5 涨姿势: 5
      发表于 2020-9-4 09:32
    给力: 5 +1: 5 这真是极好的: 5 不能同意更多: 5
      发表于 2020-9-4 08:23

    评分

    参与人数 1爱元 +8 收起 理由
    方恨少 + 8

    查看全部评分

    回复 支持 2 反对 0

    使用道具 举报

    该用户从未签到

    32#
    发表于 2020-9-4 07:49:54 | 只看该作者
    老兵帅客 发表于 2020-9-4 07:20
    多玩分层分流就是了,参见26楼。

    oceanbase 和Spanner 有人比较过吗?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2020-3-8 17:23
  • 签到天数: 94 天

    [LV.6]出窍

    33#
    发表于 2020-9-4 08:34:42 | 只看该作者
    可梦之 发表于 2020-9-4 07:42
    你去问问Google有没有省钱了啊。像你说的,人家傻啊?

    OceanBase解决了Oracle解决不了的问题,大规模商 ...

    规模是问题的关键。别的不说,拿聚餐为例,三、五个人的规模对于相应的服务压力很小。当上千人一起聚餐,任何一个小问题都会放大。比如洗手间排队,垃圾处理。。。(以上可以看作大规模并发下的IO相关问题)

    对于IT系统建设,规模是前期需求收集时的重要问题,这个会直接影响系统的架构。目前来说,中国的IT系统建设面临的规模压力远超其他地区,也给其他系统的建设提供了很好的参考样例。

    罗马不是一天建成的,IT系统也是不断成长的,前期的bug,后面可以修。没有明确的需求,可以加新模块。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5
      发表于 2020-9-6 09:42
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:22
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2017-12-15 09:06
  • 签到天数: 2 天

    [LV.1]炼气

    34#
    发表于 2020-9-4 08:52:12 | 只看该作者
    老兵帅客 发表于 2020-9-4 06:01
    oceanbase玩花活的地方就在于数据一致性,这也是它致命的地方。它的解决方案是分两步走,本地尽量搁在内 ...

    OceanBase五月做的那个测试,十年前Oracle也做过。你认为那个测试不考虑ACID吗?

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:22
    给力: 5
      发表于 2020-9-4 09:33
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    35#
    发表于 2020-9-4 08:54:35 | 只看该作者
    可梦之 发表于 2020-9-3 18:42
    你去问问Google有没有省钱了啊。像你说的,人家傻啊?

    OceanBase解决了Oracle解决不了的问题,大规模商 ...

    几千万就玩不过来了?可能嘛,PC FINANCIAL一个加拿大的小银行,一个表就是上亿笔记录了,几十个表,几个T的数据流量,ORACLE玩起来很轻松。

    只能说你那位创业的朋友,太水了。

    再者说了,无论多大的数据流量,分层分流就行了,否则谷歌是怎么玩的?

    就这还跟我争辩,有意思嘛。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    36#
    发表于 2020-9-4 09:08:51 | 只看该作者
    看客 发表于 2020-9-3 19:52
    OceanBase五月做的那个测试,十年前Oracle也做过。你认为那个测试不考虑ACID吗? ...


    这是另一个好玩的地方,2019 vs 2010。

    当然了,oracle那个不存在ACID问题
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    37#
    发表于 2020-9-4 09:16:23 | 只看该作者
    老兵帅客 发表于 2020-9-4 08:54
    几千万就玩不过来了?可能嘛,PC FINANCIAL一个加拿大的小银行,一个表就是上亿笔记录了,几十个表,几个 ...

    是几千万个设备,每15分钟发次数据,相当于每分钟有大几百万台设备连接你。人家是每天2T的数据,你那是总共几个T的数据,是同一个级别吗?加拿大银行要是每分钟几百万用户交易,每天几个T的交易记录,Oracle还能玩起来很轻松,那我承认Oracle&加拿大银行很牛逼。

    你可以耻笑我朋友太水了,但人家公司卖了几个亿早财富自由了。你可以说Oceanbase不行,但人家每天给几亿人服务着呢。Oracle的日子是越过越好,还是越来越难,自己知道罢了。

    是个人都知道数据量大了,分而治之,关键是怎么做。人家能做出来,稳定运行,我觉得挺牛逼的。Google云计算也是分布并行,我也觉得人家挺牛的啊。这么说芯片产业不就是把晶体管做得越来越小吗。

    点评

    给力: 5.0 涨姿势: 5.0
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:22
    给力: 5
      发表于 2020-9-4 09:35

    评分

    参与人数 1爱元 +8 收起 理由
    方恨少 + 8

    查看全部评分

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    38#
    发表于 2020-9-4 09:19:35 | 只看该作者
    可梦之 发表于 2020-9-3 20:16
    是几千万个设备,每15分钟发次数据,相当于每分钟有大几百万台设备连接你。人家是每天2T的数据,你那是总 ...

    为什么电表要每15分钟发送一次数据,这个设计就不合理。国内的财务自由方法很多,俺很理解。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2021-4-20 05:43
  • 签到天数: 300 天

    [LV.8]合体

    39#
    发表于 2020-9-4 09:26:14 | 只看该作者
    老兵帅客 发表于 2020-9-4 09:19
    为什么电表要每15分钟发送一次数据,这个设计就不合理。国内的财务自由方法很多,俺很理解。 ...

    具体要问电力系统的专家,不是技术所限,人家还巴不得实时报告数据呢。发送的又不仅仅是用了多少电,还有电压、电流等n多数据呢。他们做的一个应用就是预测未来的用电情况,帮助电网保持均衡。这样,数据当然越及时越准确。

    另外,朋友国内的公司卖了,美国的没卖,PGE也是他们的客户。是不是有美国客户,看起来就不那么水了?

    点评

    给力: 5.0 涨姿势: 5.0
    油墨: 5.0 油菜: 5.0
    油墨: 5 油菜: 5 给力: 5 涨姿势: 5
      发表于 2020-9-24 18:05
    给力: 5 涨姿势: 5
      发表于 2020-9-5 22:22
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    40#
    发表于 2020-9-4 09:29:43 | 只看该作者
    可梦之 发表于 2020-9-3 20:26
    具体要问电力系统的专家,不是技术所限,人家还巴不得实时报告数据呢。发送的又不仅仅是用了多少电,还有 ...

    统计数据不需要这么详细的收集,可以在本地收集,每天报告一次即可。这种收集完全可以用单板机做,费用立刻就下来了。同时因为降低了报告频率,服务器的压力也就下来了。

    当然了,以这样的方案,那公司赚不了多少钱,这才是关键,对吧。
    回复 支持 1 反对 0

    使用道具 举报

    手机版|小黑屋|Archiver|网站错误报告|爱吱声   

    GMT+8, 2024-11-13 14:24 , Processed in 0.057742 second(s), 32 queries , Gzip On.

    Powered by Discuz! X3.2

    © 2001-2013 Comsenz Inc.

    快速回复 返回顶部 返回列表