爱吱声

标题: 阿里的云数据库是如何打败Oracle的 [打印本页]

作者: 晨枫 时间: 2020-9-3 08:28
标题: 阿里的云数据库是如何打败Oracle的
本帖最后由晨枫于 2020-9-2 18:32 编辑

https://www.guancha.cn/daju/2020_09_03_563860_s.shtml

有意思！阿里从“用不起”IOE开始，到IOE“吃不下”双十一，最终走上自己的云数据库的路。云数据库会碾压Oracle吗？触发事件可能是数字货币，传统数据库可能很快就要爆满。

至于坛里总有人把阿里云贬为“不就是偷人家的开源”，自己看看吧，别信口开河。

作者: aniu 时间: 2020-9-3 09:35
这个我可以说一嘴。OceanDB应该算是Distributed SQL(分布式数据库)，应该跟TiDB，Google Spanner 去比。跟Oracle比是降维打击，太欺负人了。
Oracle作为单机时代数据库系统的老大，天生不适合双十一这种海量，高并发的use case。哪怕单机的传统地盘也被新的开源DB MariaDB, Postgres 蚕食。

Oracle和IBM DB2， Microsoft的SQL Server一样，已经是日薄西山了

作者: lorry 时间: 2020-9-3 09:50
阳振坤是王选的学生，748嫡系。

作者: dopplermaxgamil 时间: 2020-9-3 11:22
晨老大，赶紧准备钢盔，口水冰雹即将来袭。

作者: 阿忙 时间: 2020-9-3 11:38
我一直以为晨枫是搞IT的

作者: togo 时间: 2020-9-3 11:50
不知道SAP HANA数据库表现怎么样，至少在ERP方面SAP碾压甲骨文

作者: 无言 时间: 2020-9-3 12:18
本帖最后由无言于 2020-9-3 12:20 编辑

togo 发表于 2020-9-3 11:50
不知道SAP HANA数据库表现怎么样，至少在ERP方面SAP碾压甲骨文

SAP本行是ERP然后收了Sybase，甲骨文本行数据库收了Peoplesoft。

作者: 伯威 时间: 2020-9-3 15:58
斯基每回一出圈IT，必然应者云集。

作者: 伯威 时间: 2020-9-3 16:00
阿里云数据库性能显然已经超过开源了，拿来主义的模范。

作者: 红茶冰 时间: 2020-9-3 21:40
其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。

作者: 晨枫 时间: 2020-9-3 21:45

红茶冰发表于 2020-9-3 07:40
其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。 ...

对，这个每年春节开放购票时的瞬时冲击也是奇观，集中式数据库怕是挡不住

作者: 阿忙 时间: 2020-9-4 01:36

红茶冰发表于 2020-9-3 08:40
其实铁路的网络订票系统就很牛逼了，这个完全是国内码农根据实际流量量身定做的系统，非常看重实操水准。 ...

这个在未名空间吵成一锅粥，基本分成两派，一派是做金融交易平台的，一派是做网站平台的，完全两条路子，可都走得通

作者: 红茶冰 时间: 2020-9-4 02:23

阿忙发表于 2020-9-4 01:36
这个在未名空间吵成一锅粥，基本分成两派，一派是做金融交易平台的，一派是做网站平台的，完全两条路子， ...

两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息要实时更新反应同时又是几百T甚至几千T的流量，与金融平台所考虑的核心关键问题都是一个，延迟
办法只有一方案，第一硬件方面将所有可能需要实时调取的数据全部内存化第二优化各种协议算法。常规的所谓云之类的CDN加速也的重新改，否则一样玩不转。
所以从这件事完全可以看出咱们的网络战备力量还是很强大的，这种涉计到网络最核心的问题都能自足解决了，完全说明无论是人员素质还是设备的冗余程度以及可靠性都没话说的。

作者: 可梦之 时间: 2020-9-4 03:28

红茶冰发表于 2020-9-4 02:23
两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息 ...

这个是很牛的，关键美国没有这种需求。

IBM中国最开始都是美国专家帮助，后来只能自己搞，美国银行没有那么大的交易量，专家也没遇到过中国的问题。

作者: 老福 时间: 2020-9-4 03:51

可梦之发表于 2020-9-4 03:28
这个是很牛的，关键美国没有这种需求。

IBM中国最开始都是美国专家帮助，后来只能自己搞，美国银行没有 ...

物联网时代，美国也会遇到同样的问题的。

作者: 老兵帅客 时间: 2020-9-4 04:01

红茶冰发表于 2020-9-3 13:23
两派涉及到这种极端环境下其实是有共同语言，常规的前后端IT工程师在面对订票系统这种即要求所有票务信息 ...

没那么神奇，其实不过是尽量都搁在内存，然后死了命地玩cluster，再加上限制数据一致性以降低同步所带来的性能压力。这样做的好处是交易量上去了，代价是数据一致性。

oceanbase的基础是mysql，经过魔改变成了以内存为中心、以数据一致性为代价的分布式数据库。

类似的体系设计方案，加拿大银行界也一样用。但是不以mysql为基础，而是用其它的in memory data store，一样能达到性能要求，但是却避免了数据一致性问题。

作者: 老兵帅客 时间: 2020-9-4 04:01

老福发表于 2020-9-3 14:51
物联网时代，美国也会遇到同样的问题的。

物联网时代，是否会出现还是个疑问呢。

作者: 可梦之 时间: 2020-9-4 05:16

老兵帅客发表于 2020-9-4 04:01
没那么神奇，其实不过是尽量都搁在内存，然后死了命地玩cluster，再加上限制数据一致性以降低同步所带来 ...

金融业务不可能放弃数据一致性的，OceanBase只是换了个方法去实现。

OceanBase解决ACID问题的方法，主要是靠增加备份，将三套OceanBase绑定在一起运行，一个主库，两个备库。只有当至少一个备库也完成任务时，主库才会完成这个任务，这样，任何一个任务至少被保存在两台服务器上，极大降低了事故概率。

传统数据库本身要保证一致性，每一步都要记录，出现错误要回滚到初始状态。这就造成了复杂的逻辑。

我的理解是OceanBase不再考虑这些小概率的错误处理，假设没有问题往下执行，万一出了问题，从备库恢复。这是云计算的典型思路。对业务来说，数据一致性是不变的，变的只是内部实现方式。

加拿大银行界的技术方案不了解，不过中国的业务量至少要大一个数量级，用的话也得魔改，这不就是OceanBase干的事儿吗？

作者: 马鹿 时间: 2020-9-4 05:28
每年黑五好deal 都很难抢到, 因为网站down了

作者: 老兵帅客 时间: 2020-9-4 06:01
本帖最后由老兵帅客于 2020-9-3 17:04 编辑

可梦之发表于 2020-9-3 16:16
金融业务不可能放弃数据一致性的，OceanBase只是换了个方法去实现。

oceanbase玩花活的地方就在于数据一致性，这也是它致命的地方。它的解决方案是分两步走，本地尽量搁在内存里以保证性能，然后服务器同步到SSD硬盘以保证数据一致性，但是这个延迟本身是有危险的，因此它的对应方案是双机甚至多机热备份，以此来尽可能降低风险。这个方案本质上是用软件来替代传统数据库的交易实现，但是却无法根除风险。

这样的做法在中国也许行，但是在欧美则很难被认可，因为它破坏了数据库的基本原则，ACID，因为这个实现不是可保证的，而是非常近似可保证的，这个区别在商界会引起恐慌的。

加拿大这边的银行用这类思想处理的不是客户数据库，而是整个银行范围内的single sign on，也就是本银行所有应用的账户的SSO。由于对延时的要求非常高，传统数据库是不可能做得到的，只能在in memory data store上做文章，然后同步到硬盘以保证数据的保存，同时以多个服务器同步的方式提高服务的可用性。

传统数据库的问题之一就是完善的数据一致性带来了太多的性能损失，因此在追求极高交易量的情况下，只能适当牺牲数据一致性。但是如何保证可接受的数据一致性是关键。

作者: 可梦之 时间: 2020-9-4 06:27

老兵帅客发表于 2020-9-4 06:01
oceanbase玩花活的地方就在于数据一致性，这也是它致命的地方。它的解决方案是分两步走，本地尽量搁在内 ...

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

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

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

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

作者: 老兵帅客 时间: 2020-9-4 06:42

可梦之发表于 2020-9-3 17:27
要做到的是将风险降低到可以忽略不计的水平，就是传统数据库也做不到完全根除风险。只要oceanbase能将风 ...

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

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

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

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

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

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

到此为止吧。

作者: 可梦之 时间: 2020-9-4 06:54

老兵帅客发表于 2020-9-4 06:42
这个就算了吧，OCEANBASE是基于mysql魔改的，而mysql根本就不是政府以及主要商业用户的数据库选择，这个 ...

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

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

作者: 老兵帅客 时间: 2020-9-4 07:00

可梦之发表于 2020-9-3 17:54
Oracle的数据库还是根据一篇paper改出来的呢。mysql和Oracle理论上有本质区别吗，没有，Oracle的好是工程 ...

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

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

作者: 可梦之 时间: 2020-9-4 07:09

老兵帅客发表于 2020-9-4 07:00
mysql与oracle的确没有理论上的本质区别，但是确实有价格上的绝大差距，你能否说因为没有理论上的本质区 ...

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

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

作者: 老兵帅客 时间: 2020-9-4 07:18

可梦之发表于 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产品垄断的。

作者: semtex 时间: 2020-9-4 07:18
阿里的业务量应该是加拿大银行至少两个数量级，没啥可比的。

作者: 老兵帅客 时间: 2020-9-4 07:20

semtex 发表于 2020-9-3 18:18
阿里的业务量应该是加拿大银行至少两个数量级，没啥可比的。

多玩分层分流就是了，参见26楼。

作者: 可梦之 时间: 2020-9-4 07:27

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

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

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

作者: 老兵帅客 时间: 2020-9-4 07:32

可梦之发表于 2020-9-3 18:27
原文说了，Oracle满足不了需求了。Google确定是因为Oracle/IBM太贵，才开创的云计算。企业为了节省成本做 ...

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

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

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

打住吧啊。

累了，看电视剧去了。起码，我能确定我得到些什么，而不是一堆的应该如何。

作者: 可梦之 时间: 2020-9-4 07:42

老兵帅客发表于 2020-9-4 07:32
企业为了节省成本而作创新，这个想法很好，但是确实省钱了吗？好好想想吧。

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

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

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

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

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

作者: 史蒂芬周 时间: 2020-9-4 07:49

老兵帅客发表于 2020-9-4 07:20
多玩分层分流就是了，参见26楼。

oceanbase 和Spanner 有人比较过吗？

作者: colin1992 时间: 2020-9-4 08:34

可梦之发表于 2020-9-4 07:42
你去问问Google有没有省钱了啊。像你说的，人家傻啊？

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

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

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

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

作者: 看客 时间: 2020-9-4 08:52

老兵帅客发表于 2020-9-4 06:01
oceanbase玩花活的地方就在于数据一致性，这也是它致命的地方。它的解决方案是分两步走，本地尽量搁在内 ...

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

作者: 老兵帅客 时间: 2020-9-4 08:54

可梦之发表于 2020-9-3 18:42
你去问问Google有没有省钱了啊。像你说的，人家傻啊？

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

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

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

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

就这还跟我争辩，有意思嘛。

作者: 老兵帅客 时间: 2020-9-4 09:08

看客发表于 2020-9-3 19:52
OceanBase五月做的那个测试，十年前Oracle也做过。你认为那个测试不考虑ACID吗？ ...

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

当然了，oracle那个不存在ACID问题

作者: 可梦之 时间: 2020-9-4 09:16

老兵帅客发表于 2020-9-4 08:54
几千万就玩不过来了？可能嘛，PC FINANCIAL一个加拿大的小银行，一个表就是上亿笔记录了，几十个表，几个 ...

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

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

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

作者: 老兵帅客 时间: 2020-9-4 09:19

可梦之发表于 2020-9-3 20:16
是几千万个设备，每15分钟发次数据，相当于每分钟有大几百万台设备连接你。人家是每天2T的数据，你那是总 ...

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

作者: 可梦之 时间: 2020-9-4 09:26

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

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

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

作者: 老兵帅客 时间: 2020-9-4 09:29

可梦之发表于 2020-9-3 20:26
具体要问电力系统的专家，不是技术所限，人家还巴不得实时报告数据呢。发送的又不仅仅是用了多少电，还有 ...

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

当然了，以这样的方案，那公司赚不了多少钱，这才是关键，对吧。

作者: 老兵帅客 时间: 2020-9-4 09:31

史蒂芬周发表于 2020-9-3 18:49
oceanbase 和Spanner 有人比较过吗？

据说前者超越了后者，网页上看来的。Spanner 在加拿大并没有进入政府以及银行的商业领域，因此俺不清楚它到底如何。不过貌似这东西没有JDBC支持，因此在JAVA世界应该不会多火。

作者: 可梦之 时间: 2020-9-4 09:39

老兵帅客发表于 2020-9-4 09:29
统计数据不需要这么详细的收集，可以在本地收集，每天报告一次即可。这种收集完全可以用单板机做，费用立 ...

电网要你预测十分钟后的用电情况，你说，给我一天时间，等明天数据报告上来再给你预测啊。

作者: 老兵帅客 时间: 2020-9-4 09:47

可梦之发表于 2020-9-3 20:39
电网要你预测十分钟后的用电情况，你说，给我一天时间，等明天数据报告上来再给你预测啊。 ...

统计不会需要那么及时的数据，可以在本地采集，按天上传就够了。真要是发电机出了问题，导致供电不足，统计就是按秒也是没用的。因此你那朋友的方案就是个里应外合，一起发财的方案。

别扯了，没意思的。

作者: 无言 时间: 2020-9-4 09:53

老兵帅客发表于 2020-9-4 09:47
统计不会需要那么及时的数据，可以在本地采集，按天上传就够了。真要是发电机出了问题，导致供电不足，统 ...

这应该是准实时监控，不是简单统计。

作者: 可梦之 时间: 2020-9-4 09:59

老兵帅客发表于 2020-9-4 09:47
统计不会需要那么及时的数据，可以在本地采集，按天上传就够了。真要是发电机出了问题，导致供电不足，统 ...

不仅仅是统计，还有对数据的处理，包括预测。不是说发电机出问题了，是用电量是变动的，有时候用电多，有时候用电少，发电厂的发电量要动态调整，否则电压会过低过高，严重情况电网会出故障。国内很多是火电，调峰机组启动、关闭都需要时间的。能更早预测出来，意义是十分重大的。

需求在这里，你可以搞个更优的方案，说服客户用Oracle数据库，免得我朋友和PGE里应外合，挖资本主义墙角，顺便你也可以发个小财。

作者: MacArthur 时间: 2020-9-4 10:07

无言发表于 2020-9-2 23:18
SAP本行是ERP然后收了Sybase，甲骨文本行数据库收了Peoplesoft。

甲骨文ERP现在又改成NetSuite了，一直做不大

作者: 井木犴 时间: 2020-9-4 10:59
你敢说国内IT比国外强，有些东西马上跑步过来反对。
你看你看来了吧

作者: 晨枫 时间: 2020-9-4 11:04

老兵帅客发表于 2020-9-3 19:29
统计数据不需要这么详细的收集，可以在本地收集，每天报告一次即可。这种收集完全可以用单板机做，费用立 ...

你到底是懂实时潮流预测还是不懂？不懂就不要装。15分钟一次还太频繁？还一天一次？你以为是大妈上门抄表哪。

作者: 晨枫 时间: 2020-9-4 11:10

老兵帅客发表于 2020-9-3 19:31
据说前者超越了后者，网页上看来的。Spanner 在加拿大并没有进入政府以及银行的商业领域，因此俺不清楚它 ...

银行和政府为什么不用开源的东西？这个太好解释了：liability and supportablity。我们也是要求尽量用off the shelf的东西，不要home grown app，尽管后者可能效率更高。工业界差不多都是这样。出了问题，OTS的就可以往vendor那里推；自己留不住人，OTS也可以找vendor或者contractor来。

作者: 小刀 时间: 2020-9-4 11:36
不差钱的单位肯定无脑用商用软件啊，IT吃多了撑的用开源产品干嘛？自己给自己到屎盆子吗？
买oracle就是买个背锅的而已，跟技术水平没啥关系

作者: colin1992 时间: 2020-9-4 14:17
国家电网在神经网络的时序分析方面有需求，应用也很领先。可以理解为啥15分钟上传一次数据，主要是为了预测。

参考这篇文章，国家电网有关AI的专利排在百度后面，https://www.guancha.cn/economy/2019_03_13_493348.shtml

作者: 三体 时间: 2020-9-4 18:55
国内烂技术恰烂钱这么爽，老兵技术这么高，赶紧回来赚傻钱，在论坛打嘴炮带不来一毛钱

作者: cocolong 时间: 2020-9-4 20:39
本帖最后由 cocolong 于 2020-9-4 20:53 编辑

晨枫发表于 2020-9-4 11:04
你到底是懂实时潮流预测还是不懂？不懂就不要装。15分钟一次还太频繁？还一天一次？你以为是大妈上门抄表 ...

知识不更新，老皇历一啃就是几十年，能懂多少呢？

作者: 无言 时间: 2020-9-4 21:42

MacArthur 发表于 2020-9-4 10:07
甲骨文ERP现在又改成NetSuite了，一直做不大

NetSuite可以算Larry的半个私生？

作者: 红茶冰 时间: 2020-9-4 21:48

老兵帅客发表于 2020-9-4 04:01
没那么神奇，其实不过是尽量都搁在内存，然后死了命地玩cluster，再加上限制数据一致性以降低同步所带来 ...

得亏我还有点老底子，否则还真被老兵给唬住了。
开头我就说了铁路票务系统是实时性的系统，否则就会出现你把票订好了钱也转账确认了，然后铁路那边告诉你，不好意思，票没了~~这在票务系统才上线时就出现了，也是最被人诟病的地方。
所以票务系统的票池信息是实时更新的，而且为了保障系统不至于崩溃，专门写了一个刷新排序算法，根据点击量随时提高某条热门线路的刷新等级。为了保证订票者公平，每个注册用户在票务系统里所有的订票行为会生成一段串列号，这个号码很好识别，单号+个人ID+时间戳。其中时间戳就是用来识别这张车票到底花落那家。
现在你还觉得简单吗~

作者: togo 时间: 2020-9-4 23:52

晨枫发表于 2020-9-3 19:10
银行和政府为什么不用开源的东西？这个太好解释了：liability and supportablity。我们也是要求尽量用off ...

我工作中需要解决方案比如设备或者材料的时候都是买买买，而且要买市面上最贵的。这样如果问题还解决不了就可以说问题超出了目前可以解决的范围。反正不是自己的钱。你花钱买便宜的东西，问题解决了皆大欢喜，解决不了就会被人说为省那点钱解决不了问题，如果买贵的说不定问题就解决了。判断力有问题，这个标签被贴上了，公司里就混不好了。

作者: erha 时间: 2020-9-5 00:52

cocolong 发表于 2020-9-4 06:39
知识不更新，老皇历一啃就是几十年，能懂多少呢？

都是加拿大滴，咋就这么不一样尼？

作者: mezhan 时间: 2020-9-5 06:15

红茶冰发表于 2020-9-4 21:48
得亏我还有点老底子，否则还真被老兵给唬住了。
开头我就说了铁路票务系统是实时性的系统，否则就会出现 ...

爱坛签到首页可用此刷新排序算法

作者: r52097 时间: 2020-9-5 22:11
本帖最后由 r52097 于 2020-9-5 23:38 编辑

晨枫发表于 2020-9-4 11:10
银行和政府为什么不用开源的东西？这个太好解释了：liability and supportablity。我们也是要求尽量用off ...

这就是巴菲特问底下公司CTO，关于IBM业务然后吃瘪的真实写照。

And then we went around to all of our companies to see how their IT departments functioned and why they made the decisions they made. And I just came away with a different view of the position that IBM holds within IT departments and why they hold it and the stickiness and a whole bunch of things.

from https://www.cnbc.com/2011/11/14/ ... m-stock-part-5.html

作者: qyangroo 时间: 2020-9-6 07:50

r52097 发表于 2020-9-5 22:11
这就是巴菲特问底下公司CTO，关于IBM业务然后吃瘪的真实写照。

And then we went around to all of our ...

这个访谈里巴菲特说了最直白的一句是

But every time we went into a place to sell them our tab cards at a lower price and with better delivery than IBM, the purchasing agent would say, nobody’s ever gotten fired from buying—by buying from IBM. I mean, we probably heard that about a thousand times.

作者: 老兵帅客 时间: 2020-9-6 08:00

三体发表于 2020-9-4 05:55
国内烂技术恰烂钱这么爽，老兵技术这么高，赶紧回来赚傻钱，在论坛打嘴炮带不来一毛钱 ...

国内靠技术要是能赚钱的话，你告诉我为何有35岁大关。

作者: semtex 时间: 2020-9-6 08:13

老兵帅客发表于 2020-9-6 08:00
国内靠技术要是能赚钱的话，你告诉我为何有35岁大关。

国内一线做技术应该收入比加拿大高吧。二线不清楚。

作者: 老兵帅客 时间: 2020-9-6 08:21

semtex 发表于 2020-9-5 19:13
国内一线做技术应该收入比加拿大高吧。二线不清楚。

十年而已，然后改行。而加拿大可以做四十年直到退休，因此你告诉我应该如何比较。

另外，一线城市房价已经上千万了。就算你一年能挣百万，十年后滚蛋，房子还没付完，已经不再有你的高薪机会了，你想如何？

所以看收入一定要和房价去比，否则没意义。

早先华为那批人，我指的是九十年代的，的确有不少发了的，但是之后00年代的，就差了许多，现在的更差了。理论上，他们的收入明显上升，但是现实中，房价跑得更快，因此实际上不合算。

另外，国内一线做技术的，看公司，那几个主要的，例如华为、阿里巴巴这类，的确是高，但是是以加班为代价的，而且寿命只有十年（到35岁）。其余的收入一般，一般也就是一万多到两三万每月，然后一样有35岁的限制，但是房价呢。

这就是为什么现在很多人向往外企和国企，挣的是没那么多，但是也没有年龄限制和工作压力，实际上更合算。

作者: semtex 时间: 2020-9-6 08:40

老兵帅客发表于 2020-9-6 08:21
十年而已，然后改行。而加拿大可以做四十年直到退休，因此你告诉我应该如何比较。

另外，一线城市房价已 ...

这个是老话题了。我对老兵这个看法完全无法理解。不过这个讨论也没有结果。

作者: 老兵帅客 时间: 2020-9-6 08:46

semtex 发表于 2020-9-5 19:40
这个是老话题了。我对老兵这个看法完全无法理解。不过这个讨论也没有结果。 ...

很简单，你是创业模式还是工作模式。前者是靠着股票期权来赌命，因此奋斗几年争取发财是目标；后者则是工作是为了生活，收入需要能满足家庭的长期需要。这二者是矛盾的，但是国内忽悠人，用的是创业模式，给的钱是生活模式的，而其实现则是连房贷都没办法保证还完的。这样的做法，短期可行，长期就是国内制造业面临的问题，招不到人。为啥，因为房价高的已经使得上班没意义了。

或者干脆说，只要国内房价问题不解决，最后就是所有的实体经济都会完蛋的，因为无论做什么都不如炒房子来钱。

作者: semtex 时间: 2020-9-6 08:49

老兵帅客发表于 2020-9-6 08:46
很简单，你是创业模式还是工作模式。前者是靠着股票期权来赌命，因此奋斗几年争取发财是目标；后者则是工 ...

我猜老兵大概和国内多年没啥联系了。很多事我听来都匪夷所思。

作者: 老兵帅客 时间: 2020-9-6 08:50

semtex 发表于 2020-9-5 19:49
我猜老兵大概和国内多年没啥联系了。很多事我听来都匪夷所思。

原来我那些国内同学，以及微信电话都是假的。

你可以在头条、留园网以及文学城看看。

作者: semtex 时间: 2020-9-6 08:52

老兵帅客发表于 2020-9-6 08:50
原来我那些国内同学，以及微信电话都是假的。

你可以在头条、留园网以及文学城看看。 ...

我想如果没啥经济联系，其它真的可能都是假的。

作者: 老兵帅客 时间: 2020-9-6 08:54

semtex 发表于 2020-9-5 19:52
我想如果没啥经济联系，其它真的可能都是假的。

打住吧，不要歪楼，让我们为阿里打败甲骨文而欢呼，板载，板载，板载！！！

作者: semtex 时间: 2020-9-6 09:03

老兵帅客发表于 2020-9-6 08:54
打住吧，不要歪楼，让我们为阿里打败甲骨文而欢呼，板载，板载，板载！！！ ...

这有什么可讨论的， K线早给了答案。

作者: 雷声 时间: 2020-9-6 09:37

老兵帅客发表于 2020-9-6 08:54
打住吧，不要歪楼，让我们为阿里打败甲骨文而欢呼，板载，板载，板载！！！ ...

我看您二位是看到了盾牌的两面，一个就说是金盾牌，一个说错了是银盾牌。然后撕逼打架。。。

作者: 老兵帅客 时间: 2020-9-6 09:40

雷声发表于 2020-9-5 20:37
我看您二位是看到了盾牌的两面，一个就说是金盾牌，一个说错了是银盾牌。然后撕逼打架。。。 ...

哪儿呀，我一方面在这边解闷，一方面在考虑td的mutual funds选择呢。后者是关键，前者只是解闷。

活到我这个年纪，什么国家、公司胜败都是扯淡，自己的利益才是真的。

作者: 可梦之 时间: 2020-9-6 14:58
世界不是非黑即白的。国内有问题，也有成就，这两者并不冲突。不能因为成绩掩盖一切问题，也不能说因为问题就抹杀一切进步。我们做技术的，要尽量保持公正之心，探讨具体的技术问题。

作者: 晨枫 时间: 2020-9-6 21:49

老兵帅客发表于 2020-9-5 18:50
原来我那些国内同学，以及微信电话都是假的。

你可以在头条、留园网以及文学城看看。 ...

按照你说的35岁线，你国内的那些同学早都脱离ICT的一线甚至二线了吧？他们的话如何就比段子可信？

作者: 老兵帅客 时间: 2020-9-6 22:00

晨枫发表于 2020-9-6 08:49
按照你说的35岁线，你国内的那些同学早都脱离ICT的一线甚至二线了吧？他们的话如何就比段子可信？ ...

他们讲述的是他们周围发生的事情，如果你连同学朋友的话都不相信的话，咱家无话可说。

作者: 晨枫 时间: 2020-9-6 22:09

老兵帅客发表于 2020-9-6 08:00
他们讲述的是他们周围发生的事情，如果你连同学朋友的话都不相信的话，咱家无话可说。 ...

一个大班那么多同学，尽信当然是不行的。多少人退出微信同学圈，就是因为同学圈里胡说八道太多。莫非你的同学圈特别？或者你也是那些胡说八道的一份子所以臭味相投？

作者: semtex 时间: 2020-9-6 22:40
其实那些同学的闲聊真的不可信，不是说他们在撒谎，而是中国人有为他人着想的毛病，和国外的说话，经常是卖惨，焦虑。

其实什么信息，都需要经过金钱的考验。

作者: semtex 时间: 2020-9-6 22:44
国内的发展，只是闲聊是很难了解的。

其实产业升级很顺利。而且最近我发现，商业模式也走在西方的前面。比如中国在线上线下结合上。美国的传统MALL还在痛苦转型。

作者: 煮酒正熟 时间: 2020-9-7 06:06

semtex 发表于 2020-9-6 09:44
国内的发展，只是闲聊是很难了解的。

其实产业升级很顺利。而且最近我发现，商业模式也走在西方的前面。 ...

能否对“中国线上线下结合”多聊两句？对商业模式的创新很感兴趣

作者: lorry 时间: 2020-9-7 10:08
蚂蚁上市，很多千万富翁。

作者: lorry 时间: 2020-9-7 10:15
阳振坤持股市值200多亿元。

作者: ChuPaChuPs 时间: 2020-9-7 11:23
老兵关于创业模式和工作模式的说法还是很精准的
不过这种极高并发,超高时效的应用,阿里还是有点东西的,国内那些买票日,购物节的应用场景,数据量美国真比不上

作者: 史蒂芬周 时间: 2020-9-7 11:43

lorry 发表于 2020-9-7 10:15
阳振坤持股市值200多亿元。

阿里的jeff dean啊。

作者: 史蒂芬周 时间: 2020-9-7 11:53

老兵帅客发表于 2020-9-4 09:31
据说前者超越了后者，网页上看来的。Spanner 在加拿大并没有进入政府以及银行的商业领域，因此俺不清楚它 ...

如果oceanbase是mysql 基础上改出来的集群，那么跟Vitess 比较可能更合适。

作者: 风云际会 时间: 2020-9-7 14:44

老兵帅客发表于 2020-9-4 09:47
统计不会需要那么及时的数据，可以在本地采集，按天上传就够了。真要是发电机出了问题，导致供电不足，统 ...

你这个回复真完全是外行的话....电网的稳定性需要有足够实时的统计信息, 统计时间越密集就能越有力的保障电网整体供电的稳定性, 电网的问题远不仅仅只是发电机的问题....举个例子, 电网某个地方可能出现了一次较大的电流涨落(比如雷击,甚至电网自身的非线性涨落), 这个涨落的影响就会在十几分钟内扩散到电网各处引起系统性风险. 而如果我们能在十分钟的scale上了解到这样的涨落,那么我们就可以平抑这样的波动, 保持电网的供电的稳定性.

作者: 老兵帅客 时间: 2020-9-7 19:22

ChuPaChuPs 发表于 2020-9-6 22:23
老兵关于创业模式和工作模式的说法还是很精准的
不过这种极高并发,超高时效的应用,阿里还是有点东西的,国内 ...

极高并发，超高时效的应用，北美一样有对应的实现，只不过没有像国内那样死命吹而已。

作者: 可梦之 时间: 2020-9-8 08:48

老兵帅客发表于 2020-9-7 19:22
极高并发，超高时效的应用，北美一样有对应的实现，只不过没有像国内那样死命吹而已。 ...

来，吹一个，加拿大有什么极高并发，超高时效的应用？Pornhub？

作者: 史蒂芬周 时间: 2020-9-8 14:43

可梦之发表于 2020-9-8 08:48
来，吹一个，加拿大有什么极高并发，超高时效的应用？Pornhub？

哈哈，P站也就只是并发。

加拿大第一大tech公司现在是SHOP。SHOP还是有点东西的。

作者: akboz 时间: 2020-9-8 22:21

史蒂芬周发表于 2020-9-8 14:43
哈哈，P站也就只是并发。

加拿大第一大tech公司现在是SHOP。SHOP还是有点东西的。 ...

Shopify 吧，哪家用的主力数据库就是老兵看不上的MySQL。

作者: 红茶冰 时间: 2020-9-9 04:24

可梦之发表于 2020-9-8 08:48
来，吹一个，加拿大有什么极高并发，超高时效的应用？Pornhub？

pornhub谈不上高并发数，至于时效啥的压根没这需要，他的VIP会员数据库完全与注册会员独立开了。
pornhub技术含量高的地方在不负载平衡，所以CDN才是他家需要做的

作者: xiejin77 时间: 2020-9-24 11:15
晨大这个话题确实是有点关公战秦琼的意思了。

对标甲骨文和IBM DB2的产品，似乎应该是国内的达梦之类的。这方面是我们的短板，至少我这么认为。

分布式数据库在国内是oceanbase、中兴的goldenDB，华为的高斯DB、巨杉SequoiaDB。tx也有自己的产品，忘了名字了。国外的spanner TiDB都是类似的。连Cassandra似乎也算是广义的竞品。

至于说oceanDB好不好用，嘿嘿，我想我还是有些发言权的。毕竟金融行业里拿这个玩意儿打造自主产品的就有我们这里一号。

站在一个实际使用者和架构选择者的角度来说，这个玩意儿是领导的最爱，是码农的噩梦，运维的沼泽。

根源在于，解决了能与不能，却忽略了行与不行。

CIO的考虑在于能还是不能，技术实践者却在所谓能的基础上要去验证什么行什么不行。

CAP的三角形决定了分布式体系的天花板，ACID不是项目计划进度，领导一句统筹考虑就能解决的。

老兵老师的话，俺也冒昧评价一下；其实跟俺的传统思维差不多。但是新兴技术的应用不可以用固有观念来一概否定。俺作为十几年前那个对于DB2的coder讲师不以为然的少年，自然也会努力革故鼎新。至少不能成为自己当年鄙视的人。所以呢，个人观点，分布式数据库，国内确实可能有优势。但是只有像我们这样的金融业老农也能够欣然认可oceanbase，goldenDB和高斯DB之类的产品应用。那时再来说打败XX，似乎才有实质性的意义吧。

反正，如今阶段，不要急着说去打败谁。自己先用起来，用的别开生面、虎虎生风之后，可能就已经不需要再去比较了。

作者: 老兵帅客 时间: 2020-9-24 18:16

xiejin77 发表于 2020-9-23 22:15
晨大这个话题确实是有点关公战秦琼的意思了。

对标甲骨文和IBM DB2的产品，似乎应该是国内的达梦之类的。 ...

不要称俺老师，俺就是个软件老兵罢了，毕竟干这行已经32年，几乎三分之一世纪。一直在一线干活，自然思维比较实际一些，不喜欢天马行空的爱国口号而已。

另外说一句，所有的所谓新技术，本质上不过是现有数据结构与内存和硬盘的访问策略之组合罢了，因此没啥让人耳目一新的东西，都能让人一眼看出其中的问题来的。分布式数据库西方早就有了，为啥流行不起来，或者只在非常有限的范围内使用，原因就是它的问题太多，在很多场合下得不偿失。

再者劝一句，不要跟有信仰的人争论，那是没希望的，因为人家在乎的是信仰而非实际。调子高高的经常没几个是一线干活的，相反，倒经常是些书记、政委一类的货色。因此，还是免了吧。

作者: pcb 时间: 2020-9-24 21:53

xiejin77 发表于 2020-9-24 11:15
晨大这个话题确实是有点关公战秦琼的意思了。

对标甲骨文和IBM DB2的产品，似乎应该是国内的达梦之类的。 ...

"不要急着说去打败谁。自己先用起来，用的别开生面、虎虎生风之后，可能就已经不需要再去比较了。"

"可能就已经不需要再去比较了。" 赞这个！

作者: SkyWalkerJ 时间: 2020-9-28 18:34

老兵帅客发表于 2020-9-4 06:42
这个就算了吧，OCEANBASE是基于mysql魔改的，而mysql根本就不是政府以及主要商业用户的数据库选择，这个 ...

很难想象一名严肃的码农会说出开源的不如收费的这种话。
Windows phone仰望着安卓哭晕在厕所。

作者: SkyWalkerJ 时间: 2020-9-28 18:41
本帖最后由 SkyWalkerJ 于 2020-9-28 18:42 编辑

老兵帅客发表于 2020-9-6 08:00
国内靠技术要是能赚钱的话，你告诉我为何有35岁大关。

因为35岁以后都当领导了啊。没办法，发展太快。
华为很多几亿美刀营业额的产品线经理也就30~35之间。
互联网公司就不说了吧。

欢迎光临爱吱声 (http://aswetalk.net/bbs/)