对话巨杉核心研发团队:分布式数据库自研之路

一直以来,数据库的核心研发团队都十分神秘,作为隐藏在幕后的隐士高人,他们对数据库发展以及数据库研发团队的看法是什么呢?本文我们就由巨杉数据库核心技术研发团队的“老司机”,向大家分享他分布式数据库的自研之路。

Q:作为数据库行业的“老司机”,您能否先介绍一下自己?
A:我叫Danny,是巨杉数据库核心研发团队的成员,是一名数据库资深工程师和架构师,有超过20年的数据库核心研发经验,曾经作为DB2 内核研发团队成员参与了DB2 ,DPF等产品的架构设计和研发工作。
目前,我们北美研发实验室的团队已经有很多数据库的专家“老司机”加入,全部来自DB2 的核心技术团队。
虽然我们团队很多都是来自IBM、华为的“传统企业级IT人”,不太喜欢抛头露面。但是现在是技术圈一个变革的新时代,我们的产品已经开源了,所以我们之后也会让我们团队的技术大牛们多多参与社区活动,分享一下我们做数据库核心研发的心得,同时也和大家一起进步。

Q:作为“老IBM”,您认为像IBM这样历史悠久的IT企业,他们的核心研发团队是怎么样的呢?您对此感受最深的是什么?
A:IBM是最早提出“关系型数据库”这一概念和理论体系的公司,从技术上看,传统三大关系型数据库在发展过程中,其实已经具有很深远的技术储备了。DB2是三大传统关系型数据库中唯一的分布式产品,因此我们团队在分布式技术方面的积累是一脉相承的。
我在DB2的十几年里,感受最深的就是技术底蕴和沉淀。
比如说,在Unix真正支持线程机制之前,针对多线程模型,甚至是针对不同的硬件设备,他们早已使用汇编语言实现了逻辑线程的切换和调用,这些机制在当时其实是相当领先的。
说到研发团队,IBM的实验室也是卧虎藏龙。从最初使用汇编语言开始的技术专家们,一直在参与数据库、操作系统和编译器底层的研发工作,可以说正是他们创造了最早的关系型数据库的概念,也是他们真正把数据库打造成为一个通用的软件平台。

Q:像数据库这样的基础软件,技术上的难度是什么?
A:数据库软件,特别是一款真正企业级ready的产品,并没有大家想象的,只是开发一款软件那么简单。
从技术上来说,数据库既需要有技术基因的传承,又需要创新。
数据库技术到现在已经发展了40多年了。在技术的发展中,数据库软件/平台已经成为一个功能复杂,架构庞大,安全要求很高的庞大软件产品体系。因此,技术上既需要技术的积累,也需要新的创新。
同时,在应用端这边,由于用户都是银行、政府等这些30年前就开始使用数据库的老客户,他们通常无法承担全盘迁移的风险,因此在业务技术架构上,难免保留了各个时代的历史遗留,比如说,北美一些银行的核心IT系统,直到目前仍然运行在40年前的技术平台之上。这也要求企业级ready的数据库基础软件需要有很强的兼容能力,不但可以保证旧业务的运行,还可以不断地推陈出新。
这种创新是必须的,但在技术上却又是最难的。

Q:以您近20年的数据库行业经验,您认为数据库核心团队应该是怎么样的?
A:我认为数据库核心研发团队的基因很重要,就比如说IBM的DB2团队,就是以多位数据库领域的“老炮儿”为核心,搭配有技术实力的资深工程师,而不像现在很多的开源新产品,他们都是以年轻的创新团队为主。
就像我上面提到的技术复杂度和产品历史跨度的问题,数据库产品如果要在大型企业内使用,技术团队必须要有传统数据库的开发经验,这也就是技术老炮儿存在的作用。
简单说,数据库基础软件就是创新技术和技术经验积累的融合体。

Q:海内外基础软件研发有什么不同?
A:相对来说,海外拥有技术人才的基础,也有像IBM Oracle这样的体系的沿袭,培养出了一批批技术人才和团队。所以现在北美很多新一代基础软件产品团队其实还是围绕了老一辈的“老司机”构建的。
国内基础软件的人才积累还不够,因此基础软件领域还没有完全形成基础软件领域的武林门派,这也是近年来基础软件和AI领域国内企业疯狂往外招人的原因。但是数据库由于历史原因,国内无论是互联网还是科研团队想要形成独特的门派,还需要时间。
巨杉这边我们的团队拥有以王涛为代表的很多DB2 团队的核心技术专家,以及来自华为的技术核心团队成员,是技术基因和技术创新很好的结合。

Q:数据库开发和其他软件有什么不同?
A:因为刚才提到的这些特点,基础软件特别是数据库的研发,和其他应用软件有很大的不同。其中最大的一个不同点就是开发语言和开发模式。
从计算机的发展来看,C是最面向机器语言(汇编代码)的,原则上每一行C代码都可以很精准地映射到一些汇编指令上,因此从对操作系统底层的操控来看最为精准。
C++则是在C之上发展起来的面向对象语言。在底层编程中,C++的高级特性被使用的非常少,但是其设计模式对于模块化开发很有帮助。因此使用C++既可以兼顾对操作系统底层最精准的把控,也可以将一些面向对象的理念融入代码中,在复杂系统构建时起到重要作用。
如今新的一些新型开发语言则不是面向对象,因此在设计模式上不适合大型复杂系统的开发。同时,这些语言语言简化了很多C/C++里最为重要的指针概念,使其对内存的精准操作变得不可能完成。指针这个概念用好了是神器,用差了是垃圾,大部分能力不高的程序员,或者没有非常完善测试框架的项目很难完美把握指针这类高级特性,使得大型项目开发里面内存泄露和崩溃漏洞遍地都是。
但是对于我们巨杉来说,有着DB2数据库内核的研发经验,从人员能力,到代码质量管理,到测试框架的完善都能够完美驾驭这类高级特性,最大程度挖掘出操作系统和数据库底层的性能与处理能力。

Q:分布式数据库方向是什么?
A:根据Gartner和我们CTO王涛的共同观点,真正特别大使得传统关系型数据库存不下的表相对来讲数量都是可控的。因此有很多workaround都可以搞定这个问题,这也是为什么传统以来大家用分库分表虽然麻烦,但也不是解决不了应用问题。
数据库其实真正面临的痛点是“微服务”下,数据服务的资源池化。
应用程序从传统烟囱式构建,向微服务转型的过程中,在每一个微服务上都放一个独立的数据库已经是不可能的事情了。这种情况下,数据服务资源池需要直接面向上层成百上千个,来自不同开发商、不同团队的,开发能力不一、应用类型不同、SLA安全级别不同等等的各类需求。
因此,资源池必须拥有弹性扩张、资源隔离、多租户、可配置一致性、多模式(支持各类SQL协议)、集群内可配置容灾策略等一系列功能,同时每个数据库实例的计算和存储能力需要做到能够无限扩张,毕竟有些微服务可能会涉及到极多的流水数据,不能限定每个数据库实例使用的资源仅局限于一台物理设备。
所以说,单纯为了分布式的OLTP只是解决了不构成刚需的问题(分库分表早可以解决),但是在微服务应用开发的环境下,数据库更是要从资源池化的角度对上层提供服务,同时资源池中的每个数据库实例内部也要支持分布式交易等一系列特性,做到与传统数据库的全兼容。

Q:SequoiaDB自从发布3.0版本以来,在社区和市场得到的反馈都很好,能否透露一下产品的一些新动向?
A:近期,我们会发布一个新的版本,其中OLTP场景选性能会有大的提升,同时对于SQL处理能力也会有很大提升。在分布式的交易型业务下,整体性能提升将比现在版本有2~3倍的提升,对比同类产品性能将高出5~6倍以上。
这些在本周的活动我们也会做一个简单的分享和介绍。
3月30号,本周末我们巨杉Techday的第二期活动也会在北京举办,我们也会带来一些深度的技术分享,届时也会有现场的视频直播,希望大家也能多多关注和参与!未来我们也会有更多“神秘”的数据库“老司机”给大家带来技术、趋势、见闻的分享~

原文地址:https://blog.51cto.com/13722387/2370462

时间: 2024-09-29 12:34:29

对话巨杉核心研发团队:分布式数据库自研之路的相关文章

巨杉Tech | 使用 SequoiaDB 分布式数据库搭建JIRA流程管理系统

介绍 JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪.客户服务.需求收集.流程审批.任务跟踪.项目跟踪和敏捷管理等工作领域.很多企业与互联网公司都在使用Jira作为内部流程管理系统,进行团队协作与问题单管理. JIRA的后台数据库可以选择使用嵌入式数据库或MySQL/PGSQL等专业数据库.一般来说,大部分企业选择MySQL作为底层的数据存储.但是,随着问题工单的不断积累,对于较大型企业来说MySQL所支撑的数据量可能很快达到瓶颈.用户可以选择使用SequoiaD

巨杉Talk | 拒绝数据碎片化,原生分布式数据库灵活应对数据管理需求

2019年7月19-20日,以"运筹帷幄,数揽未来"为主题的DAMS中国数据智能管理峰会在上海青浦区成功举办.在DAMS峰会上,巨杉数据库为大家带来了题为"云架构下的分布式数据库设计与实践"的主题分享. 微服务下数据库架构的演进 应用开发从传统架构向分布式转型,最先面临改造的自然就是应用程序框架.如今的微服务框架已经非常成熟,其代表性架构往往包括协议处理.服务拼装.原子服务.以及底层持久化四层.业务逻辑从传统的单一中间件被拆解成众多微服务模块,每个微服务模块由完全对

探析大数据需求下的分布式数据库

一.前言 大数据技术从诞生到现在,已经经历了十几个年头.市场上早已不断有公司或机构,给广大金融从业者"洗脑"大数据未来的美好前景与趋势.随着用户对大数据理念与技术的不断深入了解,人们已经开始从理论探索转向对场景落地的寻找,让大数据在企业中落地并开花结果. 从大数据的管理和应用方向集中在两个领域.第一,大数据分析相关,针对海量数据的挖掘.复杂的分析计算:第二,在线数据操作,包括传统交易型操作以及海量数据的实时访问.大数据高并发查询操作.用户根据业务场景以及对数据处理结果的期望选择不同的大

中小型研发团队架构实践三要点--转

来自微信公众号聊聊架构 作者|张辉清 编辑|雨多田光 如果你正好处在中小型研发团队…… 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式,很少去关注技术架构. 这时如果继续按照原有的架构及研发模式,会出现大量的问题,再也无法玩下去了.能不能有一套可直接落地.基于开源.成本低,可快速搭建的中间件及架构升级方案呢? 我是一个有十多年经验的 IT 老兵,曾主导了两家公

阿里10年分布式数据库技术沉淀,AliSQL X-Cluster的应用实战

MySQL 数据库从诞生以来就以简单.易用.开源为主打特点,成为不少开发者首选的数据库系统.阿里集团在 2008 年开始提出"去 IOE"的口号,迈入了  MySQL 数据库的时代.系统使用大量的 MySQL,配合业务的改造替代原有的商业版 Oracle 系统.根据阿里交易型应用的特点,以及双十一这样业界罕有的需求推动下,我们在官方的 MySQL 基础上增加了非常多实用的功能.性能补丁,打造了 AliSQL 这个  MySQL 分支品牌. 时间很快走到 2014 年,随着业务高速的增长

中小型研发团队对于架构技术的选择与思考

如果你正好处在中小型研发团队-- 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式,很少去关注技术架构. 这时如果继续按照原有的架构及研发模式,会出现大量的问题,再也无法玩下去了.能不能有一套可直接落地.基于开源.成本低,可快速搭建的中间件及架构升级方案呢? 在接下来的一段时间里,我会陆续推出此系列文章. 本系列文章涉及内容清单如下(并不按这顺序发布),其中有感

中小研发团队架构实践之系列大纲

以下是中小研发团队架构实践系列的大纲,部分已链接,未链接部分我也会持续的更新和发布,期待你的支持与互动. 第一篇 开篇--照着做,你也能成为架构师 第1章 中小研发团队架构实践,附案例和代码 一.框架篇--工欲善其事,必先利其器 二.架构篇--思想提升 三.公共应用篇--业务与技术的结合 四.进阶篇--从架构到管理 五.案例参考和Demo下载 第二篇 架构篇--思想提升第2章 企业总体架构规划 一.企业商务模型 二.架构现状 2.1 功能架构 2.2 应用架构 2.3 数据设计 2.4 物理架构

跨越数据库发展鸿沟,谈分布式数据库技术趋势

金融行业架构转型需求随着移动化与互联网化的不断发展,我国金融行业的商业模式与技术体系已经逐渐走上了与西方世界完全不同的道路.众所周知,欧美国家的移动化普及率远远不如我国,同时人口基数也有着数量级的不同,这就使得国内外金融行业所面临的业务类型.数据量.并发量都存在巨大的差异,导致对整个IT基础设施的需求截然不同. 在最近的一两年中,国内部分科技领先的银行已经率先对微服务与分布式技术进行了探索,一些新建的互联网金融类业务也已经开始尝试使用微服务架构.分布式技术.DevOps框架进行应用的开发与维护.

微软中国的相关研发团队 交流平台

1. 微软中国研发集团服务器与开发工具事业部: http://blogs.msdn.com/stbcblog 作为微软中国研发集团的核心研发部门之一,服务器与开发工具事业部在上海和北京与总部及世界各地产品研发机构紧密配合,致力于为微软用户提供安全与访问.管理与服务.互连系统.数据平台.Windows服务器解决方案.商业在网服务和开发工具等核心产品与技术的研发和孵化. 服务器与开发工具事业部还积极与本土合作伙伴展开战略合作,分享研发管理和产品开发的经验,将创新成果带给广大用户.此外,事业部还在中国