OceanBase CTO杨传辉:放手去干,这行没有35岁危机
近日,OceanBase CTO 杨传辉做客 CSDN 《开谈:中国开源数据库新格局》栏目,中达金桥资深数据库专家卢东明对话杨传辉等中国领先数据库厂商从业者。对话开场,杨传辉给 OceanBase 打了 3 个标签:分布式、性价比、HTAP,并由此展开对中国数据库新格局、未来趋势、职业发展等多个话题的探讨。
以下为对话精华 4000 余字实录。
中国数据库应“高水平竞争”
不管是全球的 DB-Engines 排行榜,还是中国的数据库领域排行榜,近年来,大家都非常关注中国数据库的发展情况。据统计,2022 年 1 月,中国数据库大约有 190 多家,到了 12 月,达到了 249 家,并且还在往上涨。关于中国数据库市场是否正在处在百花齐放,百家争鸣的阶段?我有一些自己的看法。
OceanBase 从 2010 年开始研发,当时中国基本没有多少人从事数据库研发,也没有几家数据库研发公司。所以,当我现在听到已经有几百家数据库公司,我是非常高兴的。因为不管是招聘人才,还是人才跳槽都更容易了,数据库从业者的发展空间更加广阔,这是一件有利于整个行业发展的好事情。
百花齐放,百家争鸣可能会有两个走向:一是“低水平重复建设”,二是“高水平竞争”。
虽然现在看起来有这么多家数据库厂商,但不同技术路线的其实没有多少家,每条技术路线都只有几家领头企业。在不同技术路线上数据库厂商越多越好,大家可以一起探索,高水平竞争。反之,如果在一条技术路线上有过多厂商竞争,这就很容易出现低水平的重复建设。重复建设过度的情况下,市场的商业化会进行整合,像美国的数据库小厂商也有很多,但真正做大的只有 Oracle、DB2、MySQL 等几家。
One size a bunch或是未来
2000 年之后,分布式数据库开始发展,“分布式”这个词在市场上刚推开时,大家在选数据库时只有厂之分,没有类型之分。无论是 Oracle 还是 IBM DB2,它们都是关系型数据库,但近年品类突然暴增,比如图数据库、时序数据库、内存数据库。这些品类为什么会出现?存在的意义是什么?值得我们思考。
关系型数据库所包含的 SQL 引擎、SQL 语言、交易处理、关系模型,其实已经基本可以满足用户的需求。但传统的经典 SQL 数据库,自身的设计是一个相对比较封闭的体系,这就导致今天的商业数据库在发展过程中经历了“分久必合,合久必分”。
一开始,用一体化架构来解决所有问题。像 Oracle 什么都能做,不管是 TP 还是 AP 还是时序,即 One size fits all。
但随着需求的发展,大家觉得 One size fits all 解决不了很多其他问题,所以提出了一个新理念——One size does not fit all,认为每一个专用的场景,都需要有一个专门的数据库。
发展到最后,其实大家意识到这两种说法都存在一些问题,最终应该是 One size a bunch,即一类数据库不是只解决某一个专用的场景,也不是解决所有的场景,而是解决一批的场景。
所以,今天 OceanBase 的 HTAP,并不是说什么场景都能应用,而是某些 TP、AP 的交集部分,OceanBase 可以做到最好。这个场景比原来 TP、AP 的范围更大,但不包含全部。以后预计会有越来越多的产品继续 One size a bunch。
数据库选型,稳定性是1
甲方的 CIO/CTO 或其他角色在选型数据库时,面对品类众多、品牌众多的数据库产品常常很难做出抉择。每家厂商似乎都在说自己的数据库能解决绝大部份的问题,再外加某个组件就能完全解决。
作为乙方,其实我们更需要站在甲方的角度思考问题。以 Oracle 为例,Oracle 是做得很好的数据库产品,能在大部分场景满足用户需求,所以全球有很多用户都会优先选择它。OceanBase 有一个 Oracle 兼容的功能,这个功能比 MySQL 兼容难一个量级往上,但我们仍然做到了其高兼容,覆盖了其 95% 以上的常见功能。
抛开数据库种类来看选型,数据库的标准定义是数据库管理系统,所以数据库本质上解决的还是基本的数据管理、存储、事务处理等问题。
对于 CIO/CTO 来说,选型数据库时最重要的就是稳定性。数据库是存数据的,越接近交易的系统,对稳定性的要求越高;越往外围的,可以更“百花齐放”一点。这里的稳定性涉及到很多:数据库有没有经过场景的打磨?数据库的延迟,抖动等一系列难题?数据会不会丢?丢数据时有没有备案?这些非常重要。
OceanBase 在承载“双 11”期间遇到过很多很难的问题,我们之所以能在前期就解决,不让问题在交易中出现,就是因为 OceanBase 做了很多这方面的预防性设计。这就像是 0 和 1 的问题,如果数据库没有稳定性,其他的都免谈。
其次,数据库核心能力。数据库包括不同的种类,有不同的应用场景,但核心能力都聚焦在高可用、可扩展、ACID、存储等等。数据库要满足功能的需求,再是易用性,这是第一个前提。在满足功能需求和易用性的前提下,再看性价比。
如果功能满足不了或者不好用,谈性价比没有意义。数据库是一个长期投资,一旦选择再更换是很难的,所以大家都会倾向于选性价比更高,使用更容易的产品。
最后,厂商的服务能力。智能数据库、无人运维等词近些年大家都在提,但目前其实都没有做得很好。任何数据库目前还是都需要人来支持,通俗点说即遇到问题需要有兜底,这时交付、生态、社区工具等各板块的及时响应非常重要。
开源就是要利他
目前主要有两类数据库公司——独立的数据库厂商、基于云的数据库厂商。
经过多年的发展,数据库的研发模式发生了重要升级。以前的 Oracle、SAP 等传统软件时代,是 License 模式,不管是版本升级、反馈用户需求,还是产品传播的效率都比较低。而基于开源,这种社区协同的高效模式,迭代起来会非常快。对于一个独立的数据库厂商而言,开源是必然选,而不是一个可选项。
开源不是一个商业模式,因为很多时候是要利他的。传统模式是厂商做好蛋糕,再去分配蛋糕;开源模式是大家一起来把蛋糕做大,每个人分一小块,在大蛋糕里切小蛋糕,本质上是新的生产力替代了旧的生产力,效率更高。
在我们认识到开源是必经之路后,就开始坚定地走开源路线。OceanBase 过去是完全的商业软件,从 2021 年儿童节开源到现在的一年多时间,用户采用开源的效率要比商业版高很多,并且扩散速度也非常快。
开源可以说是加速生态建设的必然选择,因为对于数据库这样的基础软件,其实都是用出来的。没有人写的代码是没有 bug 的,也没有人能想到所有东西。在开源社区,每个用户会以各种形式参与进来,可能是贡献代码,可能是贡献需求,最有价值的用户给厂商提供的最有价值的东西是场景。就像当年的支付宝,它给 OceanBase 提供的最有价值的东西不是钱,而是支付宝的各种场景。
有同学问到 OceanBase 是否要开源 Oracle 兼容代码?在我看来 OceanBase 可以理解为是两个产品,一个是兼容 MySQL 的产品形态,另一个是兼容 Oracle 的产品形态,这两个产品形态的应用场景差别很大。虽然看起来 MySQL 和 Oracle 都是数据库,但实际上差距非常大。
互联网有很多应用场景,在 MySQL 里,简单查询是靠 DBA 去完成的,但是在更多的一些传统业务上,Oracle、DB2、SQLServer 用户不仅仅追求 QPS,还有很多复杂的查询。当简单和复杂的查询在一个库解决时,复杂查询不能影响简单查询,这也是我认为 Oracle 也是 HTAP 数据库的主要原因。而且在 OceanBase 的实际场景里,我们发现 HTAP 在中小用户中的使用是最多的。
开发者想要真正参与到社区共建,想要的也是 MySQL 模式,或者 PG 模式、MongoDB 模式,不会是 Oracle 模式,因为 Oracle 对开发者并不友好。这是开发者的需求,不是我们的企业用户,企业用户希望免费的不一定是开源的。
从设计架构的角度来看,我们比较开放,开源逻辑也很简单,MySQL和Oracle模式是两个产品形态,底层共享分布式的能力,包括事务、存储、高可用的能力。但是 Oracle 和 MySQL 的功能有不同,总结来说:MySQL的功能全部开源,而 Oracle 的功能不开源,OceanBase 亦是如此,MySQL 模式开源,Oracle 模式不开源。
数据库这行没有35岁危机
很多年前,中国真正从事数据库行业的工程师很少,但现在有了一个跃升,这个趋势很好。OceanBase 2010 年成立时没有这方面的人才,都是一些应届生或者其他领域的人员应聘。中国的研发当时也比美国少很多,所以我们早期核心更看重应聘人员写代码的潜力。
Oracle 和 SQLServer 里有一些技术人员,比如资源隔离、HTAP 方面,经过几十年积累的这些人才是妥妥的稀缺人才。OceanBase 的核心优势是做数据库比较早,因此美国包括 Oracle 的很多核心人才回国都选择加入了 OceanBase,使得我们在做复杂查询优化等 HTAP 功能得心应手。
OceanBase 最早的一批人都是分布式的背景,这批人基本上是中国最强的,也是最早探索的一波人。我们的核心人员大部分都是当时我们培养的应届生,还有一部分就是从最顶尖的公司挖过来的,这些人才能让我们在技术架构少走很多弯路。
近两年出现了比较乐观的一件事:以前在高校没有人学数据库,但这两年开始出现了。这其实是蛮好的一件事情,并且我也认为这个行业是很好的行业、很好的工作,对于一个做技术软件的程序员来说,如果会写数据库,就可以写所有的软件。
此外,数据库领域从业者的职业生涯往往比较长,是一个非常“老中医”的行业,对从业者和开发者都十分友好,变动往往不会太大。这一行没有 35 和 55 的年龄差异,技术就是永远的竞争力。我也呼吁更多的人加入这个行业,数据库是一个有壁垒的工种,未来会越来越重要,人才也会更加稀缺。
年轻人,学到核心技术是关键
中国现在的数据库市场接近 300 个品牌,而市场占有率仍然有限。但在我看来,五年后私有化部署的数据库,中国品牌的市场份额应该能达到里程碑式的 50%。但能否占据 50% 的市场份额,核心在于有没有平替的方案,其难点就在于 HTAP,既要有简单查询又要有复杂查询,还要保证数据强一致。如果没有平替的方案,可能十年都不会超过 50%。
目前,仅仅是 OceanBase 就在很多行业做了传统数据库的平替,包括银行核心系统、最大的保险公司、中国移动、社保系统等这些大家认为很难平替的瓶颈被打破了。
比如,我们在运营商已经成功上线了好几个省,攻破第一家运营商花费了一年半;在保险行业也平替了千万条传统 Oracle 的应用层代码,第一家超大型保险公司全核心替换大约花费了一年时间。当厂商积累了一定的经验,后面帮助客户平替的速度会越来越快。
今天,不仅是品牌多,中国数据库的类型也很多,但就目前来说更有前景还是面向云设计的数据库。并且面向多云设计的数据库,可以说是一个必然的发展趋势。
偏融合型的数据库是未来的主要发展方向。虽然站在用户角度是越方便越好,但是站在技术角度没办法让用户完全方便,因此厂商在努力做结合,可能是一部分 TP 和 AP 融合在一起,甚至可能是单机和分布式融合在一起,把这些优势组合在一起,能适应更多场景。
这样一来,以前用户可能要使用十个数据库才能满足全部的需求,现在只要使用两三个数据库即可,会方便很多。所以,偏融合型的数据库必然会越来越受欢迎。
对于数据库从业者来说,找工作不一定要和云数据库、融合型数据库完全挂钩。因为虽然数据库类型不同,但很多本质的技术是相通的,所以对于刚毕业的学生来说,更应该看重在哪能学到比较核心的技术,再将这些融会贯通,就会有很强的分辨能力和竞争力!
相关推荐
2018数据架构选型必读:9月数据库产品技术解析完整版
此外,蚂蚁金服的OceanBase 2.0版本在云栖大会上发布,其副CTO胡喜在现场进行的多活容灾演示让市场对国产分布式数据库的信心进一步增强。
中国开源的底气.pdf
以下是从不同方面解析中国开源发展的关键知识点:1. 自主知识产权的开源协议 - 首个由中国人发起并国际化的
高校及科研院所如何利用外部数据完善技术转移转化机制.docx
科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。
完全复现虚拟同步发电机VSG自适应惯量阻尼控制仿真、根轨迹、调节系数对比(Simulink仿真、Matlab代码实现)
内容概要:本文档围绕“【完全复现】虚拟同步发电机VSG自适应惯量阻尼控制仿真、根轨迹、调节系数对比”这一主题,利用Simulink和Matlab平台,系统性地实现了虚拟同步发电机(VSG)的自适应惯量与阻尼控制策略的建模与仿真。内容涵盖VSG的核心控制原理、系统动态响应特性分析、根轨迹绘制以及在不同调节系数下的性能对比研究,旨在深入剖析关键控制参数对系统稳定性与动态性能的影响机制,为新能源并网系统中提升频率支撑能力和暂态稳定性的控制策略设计提供理论依据和技术支持。; 适合人群:具备扎实的电力系统分析与自动控制理论基础,熟练掌握Matlab/Simulink仿真工具,主要从事新能源发电、微电网运行、电力电子变换器控制或电力系统稳定研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①开展虚拟同步发电机(VSG)的建模与先进控制策略的深入研究;②探究自适应惯量与阻尼控制对改善电网频率响应速度和平抑功率波动的作用机理;③运用根轨迹法进行系统稳定性分析,并指导控制器参数的优化整定;④完成高水平学术论文撰写或科研项目申报所需的仿真复现实验。; 阅读建议:本资源以“完全复现”为核心目标,提供了完整的仿真模型与配套代码。使用者应在深入理解同步发电机转子运动方程、虚拟惯量及阻尼物理意义的基础上,结合电力系统暂态稳定理论,逐步操作并调试仿真模型,尤其需关注不同调节系数变化对系统动态性能指标(如超调量、调节时间)的影响,从而深化对VSG内在控制机制与稳定边界的认知。
前端开发基于history.js的HTML5与HTML4浏览器兼容方案:单页应用无刷新历史状态管理技术实现-dQ4ehf7C1792158475
内容概要:本文系统介绍了如何利用history.js实现单页应用(SPA)在HTML5c与HTML4浏览器间s草错发的无缝历史状态管理。通过封装原生History API并在不支持的浏览器中自动降级为哈希路由,history.js解决了因浏览器兼容性导致的后退按钮失效、URL混乱等问题。文章详细讲解了其核心机制,包括状态对象管理、自动模式切换(HTML5 pushState vs HTML4 哈希)、状态数据持久化以及针,对Safari、IE等浏\览器的兼容性修复方案,并提供了从入门到实战的完整示例,涵盖初始化、事,件监听、页面加载及性能优化技巧。;DtPXB1792158476


