對話巨杉核心研發團隊：分佈式數據庫自研之路

一直以來，數據庫的核心研發團隊都十分神祕，做爲隱藏在幕後的隱士高人，他們對數據庫發展以及數據庫研發團隊的見解是什麼呢？本文咱們就由巨杉數據庫核心技術研發團隊的「老司機」，向你們分享他分佈式數據庫的自研之路。

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均可以搞定這個問題，這也是爲何傳統以來你們用分庫分表雖然麻煩，但也不是解決不了應用問題。
數據庫其實真正面臨的痛點是「微服務」下，數據服務的資源池化。
應用程序從傳統煙囪式構建，向微服務轉型的過程當中，在每個微服務上都放一個獨立的數據庫已是不可能的事情了。這種狀況下，數據服務資源池須要直接面向上層成百上千個，來自不一樣開發商、不一樣團隊的，開發能力不1、應用類型不一樣、SLA安全級別不一樣等等的各種需求。
所以，資源池必須擁有彈性擴張、資源隔離、多租戶、可配置一致性、多模式（支持各種SQL協議）、集羣內可配置容災策略等一系列功能，同時每一個數據庫實例的計算和存儲能力須要作到可以無限擴張，畢竟有些微服務可能會涉及到極多的流水數據，不能限定每一個數據庫實例使用的資源僅侷限於一臺物理設備。
因此說，單純爲了分佈式的OLTP只是解決了不構成剛需的問題（分庫分表早能夠解決），可是在微服務應用開發的環境下，數據庫更是要從資源池化的角度對上層提供服務，同時資源池中的每一個數據庫實例內部也要支持分佈式交易等一系列特性，作到與傳統數據庫的全兼容。

Q：SequoiaDB自從發佈3.0版本以來，在社區和市場獲得的反饋都很好，可否透露一下產品的一些新動向？
A：近期，咱們會發佈一個新的版本，其中OLTP場景選性能會有大的提高，同時對於SQL處理能力也會有很大提高。在分佈式的交易型業務下，總體性能提高將比如今版本有2~3倍的提高,對比同類產品性能將高出5~6倍以上。
這些在本週的活動咱們也會作一個簡單的分享和介紹。
3月30號，本週末咱們巨杉Techday的第二期活動也會在北京舉辦，咱們也會帶來一些深度的技術分享，屆時也會有現場的視頻直播，但願你們也能多多關注和參與！將來咱們也會有更多「神祕」的數據庫「老司機」給你們帶來技術、趨勢、見聞的分享~