一直以來，資料庫的核心研發團隊都十分神祕，作為隱藏在幕後的隱士高人，他們對資料庫發展以及資料庫研發團隊的看法是什麼呢？本文我們就由巨杉資料庫核心技術研發團隊的“老司機”，向大家分享他分散式資料庫的自研之路。
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的第二期活動也會在北京舉辦，我們也會帶來一些深度的技術分享，屆時也會有現場的視訊直播，希望大家也能多多關注和參與！未來我們也會有更多“神祕”的資料庫“老司機”給大家帶來技術、趨勢、見聞的分享~