开源数据库虽香,但需警惕风险勿沦为“韭菜”

2020-10-13 00:00:00 软件 数据库 代码 开源 美国


近,特斯拉因为割了一茬又一茬的“韭菜”从而引发用户征讨,当“韭菜”肯定不开心。但即便被割了“韭菜”,买电动车,相信很多人的,依然是特斯拉,为什么,因为特斯拉的确是一辆好车,而这种好是建立在长期研发投入上的技术优势。


对于国产数据库软件,其实也一样,如果不持续投入用心研发,实打实的做出自己的核心竞争力,只想投机,挣快钱,在开源数据库基础上穿个衣带个帽,结局注定被割“韭菜”。


有人说,开源软件怕是压垮国产基础软件的后一根稻草。虽有些武断和悲观,但充分体现出了一种对国产基础软件现状的忧虑。


科技无国界,开源无国界,被事实证明就是个笑话。


中国是大的开源技术受惠者之一,并正在成为大的反哺者之一。开源代码的贡献率上,中国已经位居全球第二。中国科技公司成为美国开源代码托管平台的重要客户,中国的GitHub用户已居全球第二,仅次于美国。


有媒体数据显示,截至2019年3月,阿里巴巴在GitHub的公司帐号旗下有项目有1243个,百度有746个,腾讯有131个,华为有247个,小米有113个,美团有131个。


遗憾的是,GitHub现已沦为了美国制裁其他国家的政治工具,在美国贸易管制政策下,去年,GitHub切断了包括伊朗、叙利亚和克里米亚在内国家的某些服务,在全球范围内一度引起恐慌和愤怒。


那么,中国会不会在某一天突然被纳入其中呢,谁也不敢打包票,但可能性是存在的。也正是出于这个考虑,7月14日,工信部选出码云Gitee,算是未雨绸缪。


开源中国此前发布的一篇文章《开源界也要注意,Apache 基金会与 GitHub 都受美国法律约束》,其中就提到,Apache基金会官网明确说明遵循美国出口管制,这意味着旗下所有项目,诸如 Hadoop、Spark 都将受到出口管制。而GitHub、Google Code等之类的代码托管平台也均明确声明遵守美国出口管制条例。


Apache基金会有这样的问题,那么其他的基金会呢?我们不能忽视,几乎所有的开源软件团体都位于美国,且有的许可证(例如MPL 1.1)规定了管辖法院为美国法院,且适用法律为美国法。


这些事实无不在提醒我们,开源软件并不等于自由,同样受到美国出口管制的影响,虽然开源软件没有高昂的商业授权许可费用,但使用开源软件是有风险。这种风险不仅包含政治风险,还有法律风险和商业风险。


不仅断供,开源项目也有闭源风险,铁一样的事实告诉我们,开源项目不仅会闭源而且这还并非个例,在数据库领域就有不少。


2018年8月,Redis Labs 闭源了 RediSearch、Redis Graph、ReJSON、ReBloom、Redis-ML 等项目,当时引起了开源社区不小的骚动。


2018年10月,MongoDB宣布其开源许可证将从GNU AGPLv3,切换到 SSPL,新许可证将适用于新版本的MongoDB Community Server 以及打过补丁的旧版本。


同年11月,图数据库Neo4j宣布,从 Neo4j3.5版本开始,企业版将仅在商业许可下提供,不再在GitHub上提供源代码,所有依赖Neo4j的开源项目全部受到影响;


2019年6月,CockroachDB核心代码的授权协议将从Apache License version 2 (APL)变更为Business Source License(BSL)。


众所周知,Andriod开源是谷歌为了对抗苹果iOS系统,但在超越iOS成为全球大移动操作系统后。谷歌也玩起了手段,以开源为幌子,再慢慢的通过一系列手法,掏空开源的Andriod,将手机厂商的命根子抓住了,虽然说是开源,但事实上,并不是真正的全开源,所以,Linux才一直讥讽Android是伪开源。


因依赖的开源项目闭源而导致下游项目受限这样的事件虽是小概率事件,但也确实发生了不止一起。


回到数据库领域,以国内受欢迎的MySQL开源数据库为例。


从授权协议看,MySQL有2种授权协议,一种是GPL授权协议,即不允许修改后和衍生的代码作为闭源商业软件进行发布和销售,只要采用了开源软件的接口和库,哪怕没有修改源代码,也必须对自身代码开源。


另外一种是商业授权协议,针对OEM,ISV、VAR和分销商,如果不想开源代码,则必须与Oracle签订商用授权协议,依然受制于人。


事实上,国内一些“拿”开源数据库的公司,很大一部分并没有进行开源的计划,那么,随时可能面对Oracle强大的法务团队。


有些人,可能会说想多了,咸吃萝卜淡操心,其实不然,看一看甲骨文和谷歌长达10年的Java版权案,就知道这种担心并不多余,要知道,谷歌只复制了少量的Java代码,而且仅仅是声明部分。有报道显示,在安卓系统的1500万行相关代码中,复制的代码还不到0.1%。


甲骨文能在Java上这么做,那么,同等重量级的MySQL上也不是没可能。现在甲骨文不搭理你,只是因为你还不够大,还不到收割的时候。


事实上,Oracle收购MySQL后,国外就有很多人压根就不信任Oracle,担心其会将 MySQL闭源,因此,又搞出了MariaDB。


中国的数据库软件,多源自或者借鉴开源数据库及其变种,大数据平台,多源自或直接整合开源大数据生态组件,纯自研的还是少数,这是事实。


可以通过开源数据库,去学习别人的经验,但绝不是简单的“拿来主义”。因为,这没有技术创新,也解决不了核心技术供应问题,还会造成“劣币驱逐良币”的恶性竞争发展趋势。


如果不能技术自立,今天的韭菜,明天依然是韭菜,只是更为粗壮的韭菜而已。


从自主研发能力看,清华大学地球系统科学系副教授刘利就曾说过,长期使用国外免费开源基础软件,很大程度上制约了我国自主研发的积极性和创新能力,拉大了我国在相关领域与其他国家的差距。如果有一天被釜底抽薪,有的产业可能会崩塌。


他强调,“我们这一代人必须努力,用真正的自主创新去申请专利。如果现在打不好基础,下一代人会过得更苦。”


无论是MySQL还是PostgreSQL,都是模仿的Oracle的架构,但在功能、稳定性上却都比不了Oracle。几十年过去了,也未曾超越Oracle,而且,还要受限其单机架构的短板,天生就不支持分布式事务。因此,作为追赶者,采用技术跟随战略是没希望的。尤其是关键信息技术基础设施需要走向自主,而非一味的模仿和“拿来”,必须通过技术创新,用新的技术架构突破限制,走别人未走的路,才能有机会真的追赶、甚至超越,也才可能不被卡脖子。


如果技术不能自立,仅靠修改开源软件的弊端是显而易见的,国内的应用场景更为复杂,数据量也更大,开源改造的产品即便没有政治或者国际环境的影响,也无法完全满足企业级市场诉求。因为,对于传统企业级客户,IT能力往往不是他们的核心竞争力,他们更依赖通用数据库产品来提供完整解决方案,保障服务级别SLA,而不是强迫业务修改代码。


好在,这些年,国内已经开始有几家开辟了自己独特技术路线的厂商


比如:在OLTP方面,有蚂蚁金服纯自研的分布式强一致性关系数据库OceanBase,两次登顶TPC-C榜首,并创造7.07亿tpmC的性能记录。


在OLAP方面,有星环科技的ArgoDB,2018年5月,TPC-DS打榜,是全球通关TPC-DS的厂商。事实上,星环科技早期基于Hadoop,因为Hadoop在技术和商业方面的局限性,无法很好的满足企业级市场。2015年星环完全脱离Hadoop技术路线,走向自研,重构五层架构。


在HTAP方面,有PingCAP的TiDB,国内火HTAP数据库,理论基础来源于Spanner/F1论文 ,以及工业级分布式一致性协议算法Raft论文,并通过开源方式获取全球用户的信任,定期持续输出内容,用户关注度非常高。这点值得其他数据库厂商学习。


后,国产基础软件的发展需要良好的市场环境,国家应该在保护知识产权方面加大力度,严厉打击抄袭、盗版、破解等行为,建立公平公正的市场秩序,这样才能让从事基础软件开发的企业、开发者真正获得收益,基础软件产业才能真正发展壮大并站在世界舞台参与全球竞争。



2020年10月22日~24日,由IT168旗下ITPUB企业社区平台主办的第十二届中国系统架构师大会(SACC2020)将在云端进行网络直播。自2009年以来,SACC架构师大会已成功举办了十一届,云集了国内CTO、研发总监、系统架构师、开发工程师和IT经理等技术人群,与会规模超千人。过去为期3天的议程,涉及20+专场,近120个主题,完整迁移到线上进行网络直播对会议。整装待发,奋起逆袭的SACC2020,期待您的报名参与,共襄盛举!


喜欢就点个在看再走吧


相关文章