摘要：一直以來，數據庫的核心研發團隊都十分神秘，作為隱藏在幕后的隱士高人，他們對數據庫發展以及數據庫研發團隊的看法是什么呢本文我們就由巨杉數據庫核心技術研發團隊的老司機，向大家分享他分布式數據庫的自研之路。

一直以來，數據庫的核心研發團隊都十分神秘，作為隱藏在幕后的隱士高人，他們對數據庫發展以及數據庫研發團隊的看法是什么呢？本文我們就由巨杉數據庫核心技術研發團隊的“老司機”，向大家分享他分布式數據庫的自研之路。

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的第二期活動也會在北京舉辦，我們也會帶來一些深度的技術分享，屆時也會有現場的視頻直播，希望大家也能多多關注和參與！未來我們也會有更多“神秘”的數據庫“老司機”給大家帶來技術、趨勢、見聞的分享~