演講實錄：「分散式資料庫海量數據存儲和實時查詢實現與應用」

簡單介紹我們公司，有些朋友還不太了解。我們公司叫巨杉資料庫，核心產品是SequoiaDB巨杉資料庫。是我們的團隊完全從零開始研發的。巨杉資料庫是商業資料庫，同時我們本身也將產品開源，我們是中國第一款商業開源資料庫產品

美國矽谷有《紅鯡魚》雜誌，評了全球企業100強，絕大多數是矽谷的企業，只有少數中國企業，這是對我們創新能力的認可。

這是2016年的矽谷大數據全景圖，本圖囊括當今世界上所有的科技企業，很多是大家耳熟能詳的企業。在圖中可以看到巨杉資料庫，在本圖中巨杉資料庫是唯一一家中國企業。

1. 海量數據存儲

1）分散式架構

這是我們巨杉資料庫分散式資料庫的架構。

談到分散式資料庫以及分散式的其他產品，必然會提到節點，無論你給這個節點起什麼名字，在分散式系統里節點通常分為三大類：

第一類主要功能是為了接受應用發過來的請求，把請求分發到集群節點處理，這稱之為協調節點，這基本上是無狀態節點；第二類主要是保存原數據、關鍵信息等，並不負責保存真正的數據，在巨杉資料庫內稱之為編目節點，；第三類是真正保存數據節點，在數據節點中，我們可以採取多副本機制，默認三副本，本身多副本之間有負載均衡、高可用的特徵，如果某一個編目節點掛掉，保證其他節點可以快速接管服務，我們在這三個節點間實施了數據強制。

這是巨杉資料庫的總體架構，在數據節點每一個節點都實施三副本，一主兩從的方式，從節點保證數據冗餘，保證數據不會丟失，另一組是高可用，平時寫請求主要是由主數據節點完成，我們要保證兩個從數據節點快速啟動，使應用不受影響。我們在主數據節點發生故障，從數據節點會自動接管服務，不需要用戶干預。

2）分區：

進入巨杉資料庫的關鍵技術——分區概念，我們支持兩種分區，一種是水平分區，另一種是垂直分區。

水平分區： 這裡提到兩個概念，一是集合空間（CS），二是集合（CL），我們基本數據存儲單元是集合，可以等同於傳統關係型資料庫里的表，水平分區的概念是在集合里，可以選定一個欄位或者多個欄位作為水平分區的鍵（key）。

巨杉資料庫會根據你選定的鍵或者鍵值，把數據對應到集合對應的所有分區。水平分區最大的好處是可以把多個節點組成複製組，你可以把數據均勻的分布到多個數據節點或者多個複製組，避免單一存儲或者單一節點帶來的瓶頸，對於分散式資料庫來講是必不可少的特性。

垂直分區： 垂直分區更多的跟業務邏輯相關，常見信息是流水表，如果你想保存銀行過去10年甚至20年的交易流水表，這是海量天文數字的數據。因此，我們可以將龐大的數據從邏輯意義上區分開，按時間戳作為分隔的欄位。

多維分區：

多維分區機制，把水平分區和垂直分區兩種方式結合在一起使用。這跟垂直分區的圖類似，在每一個子集合內部可以用水平分區，均勻打散到多個不同的物理存儲上。

2. 加速實時查詢

1） 分區：主子集合，分區等等的機制對數據查詢能夠起到什麼作用和好處。通過分區方式，熱點數據保存在單獨的節點和單獨的存儲上。

好處是由於數據平台的訪問和其他的數據不相關，有限的熱點數據很容易被直接裝在你的內存里，他被交換出去的概率非常小。針對熱點數據的查詢會有很大可能走緩存，而不是實際的物聯，這對性能提升是非常關鍵的。

2）索引

針對查詢的第二個基礎手段，我們提供高性能索引，傳統關係型資料庫一直在用的。巨杉資料庫用的單欄位索引，也支持多欄位索引，每一個索引都可以自己定製。

針對索引我推薦用戶把索引數據單獨創建在指定的高性能存儲上，比如SSD。在SSD上，它的性能會好很多。

3）讀寫分離

此外針對高並發查詢的特性，我們有讀寫分離的策略，可以自定製數據的分散式策略。我們的數據節點默認三副本（一主兩從），主節點是用來寫的，從節點跟主節點之間通過最終一致性實現數據的一致。這時候如果有一個主請求剛好落在複製組上，巨杉資料庫會把它自動分布到兩個從節點中的一個，過程中完全不需要用戶干預，這是我們內部自動實現的。

4）域

巨杉資料庫有域的概念，可以把一部分節點定義成域，將來的結合建設在指定的域上。

這裡建立了三個域，每個都有不同的節點和數據組，可以根據你的特徵分布在不同的域上。有冷熱數據的分離，通過主子結合的方式，你也可以通過這種方式實現冷熱數據分離。這個域里針對冷數據，是相對低端的硬體、配置，另一個是熱數據，可以用相對性能好一點的硬體。有些業務是強一致性的需求，有些業務是弱一致性的需求。有些是並發查詢比較多，有些批量分析比較多，如果把兩個放在一起，可以分別建在不同的域里，形成互不影響的效果。

5）壓縮

巨杉資料庫支持兩種壓縮模式，用戶可以自己指定。大家說壓縮更多的可能跟磁碟容量相關，為什麼跟查詢也相關。在IO吞吐量非常高的場景下，比如複雜的聚合查詢，經常看見系統CPU非常高，意味著你的CPU很大一部分時間在等你IO的返回，一個查詢下去要有100G甚至500G的吞吐量，如果採用壓縮，數據吞吐量會減少，查詢性能會有非常大的提升。

6）SQL

巨杉資料庫引擎特點，我們面對更多的是企業用戶，對企業用戶來說，SQL是所有企業用戶必不可少的需求，針對這種需求，我們提供了兩種不同的SQL引擎，一種針對查詢，另一種針對分析。針對查詢，它幾乎提供所有的SQL功能。如何實現巨杉資料庫和Spark SQL之間的關聯，只要部署連接企就可以在這裡訪問。在我們官網上都有介紹。

性能對比

這是實際性能對比，這是獨立的評測機構，在2014年時，當時用的是巨杉資料庫比較老的版本，可能是1版本，當時針對分散式資料庫做了評測，橘色是巨杉資料庫，綠色是MongoDB，這是他們搭建、寫測試，整個過程沒有原廠商的參與。結果在我們巨杉的官網上也有，我們也提供鏈接。這個鏈接有關於搭建過程的建模、數據測試過程。我們在個別領域跟其他兩種相差無幾，這是我們完全自己寫的資料庫，這是讓我們非常自豪的性能。大家可以上網找這個材料。

3.應用案例

1）金融高並發查詢

這個系統要保留中國有股市以來，所有股民和股票的歷史交易記錄。最終目標是讓所有股民在任何時刻通過自助的方式（網頁或者APP）的方式查詢數據，這是天文級數據存儲平台。一旦上線，它未來的目標所面臨的並發查詢量是很恐怖的數據。在中國，像我這樣完全不炒股非常少，大家總會偶爾看一下股票。下面有數據量級，都是非常恐怖的。

我們以及MySQL一起做評測，這是真實數據，我們基本上是MySQL的10倍左右，帶數據的錄入以及查詢。我不記得具體的數據，在很多場景下，基本在並發查詢方面，應該是5-10萬筆的數量級，包括比較混合的產品，讀寫、更新全有；

2）銀行歷史數據管理

對於歷史數據，我們舉個例子可能會有直觀的體會。如果你想拿一張卡或者存摺，你去櫃檯查詢過去5-10年的查詢記錄，大家沒有關注過，但的確有這種需求。銀行在線系統通常可以查3個月的數據，多的可以查1年的數據，更久之前的很難查到。原來銀行用的在線系統是昂貴的商業資料庫的架構，比如小型機加DB2或者Oracle，這些資料庫非常貴，擴容也非常貴。即使有這個錢，當數據達到一定量的時候，查詢性能會有直線下降的表現。在線系統不會存那麼多東西的，沒有存的數據放在備份庫，更久一點的數據可能放在磁帶機上，作為冷數據保存。儘管數據沒有丟，但也不能用，這讓銀行很苦惱。利用我們資料庫產品，很大股份制銀行。我們用數據的分散式存儲以及在分散式存儲的情況下有很好查詢性能的特點，幫助他們搭建歷史數據平台，他可以把過去10年甚至20年的歷史數據全部放在巨杉資料庫的平台上，實現原來不能訪問的冷數據激活了，不僅放在庫里，而且變得可以用了。我們這個庫並不是跟銀行原有的核心交易庫放在一起，這是兩個獨立的系統。目的是我們不會影響原有在線系統的使用，我們可以做單獨的數據規劃，利用我們的特點為銀行提供更多的服務。銀行櫃面查詢、ECIF查詢，面向的對象有櫃面、網銀、手機等渠道。這兩個案例是典型的海量數據存儲，以及海量數據存儲高並發下的使用案例，這是對巨杉資料庫真實的檢驗，並且得到很好的效果。

3）政府數據湖

這是廣州市政府政務通的案例，他希望把過去市民各個部門要重複提交的數據，比如身份證照片、證件掃描件，放在統一的平台里，既方便市民不用去各個部門分別提交，也方便政府各個部門，因為他可以共享同一個數據。面臨的問題是數據量比較大，它有1000萬家市民。不僅存儲結構數據，也要存儲非結構數據。我們還有另一種數據引擎是快存儲引擎，非常類似傳統資料庫的二進位對象的存儲，這兩種引擎無縫銜接在同一個資料庫里，使用起來非常方便。我們最終成為了這個項目的底層存儲資料庫，這個項目去年上線，在廣州市政府微信號有發布，他們的底層資料庫是我們巨杉資料庫。

4）交通大數據管理

這是結構化和非結構化聯合使用的案例，數據量非常大，本身具有結構化數據，特別耗時間。也有非結構化數據，車流量拍攝下來的照片等等。這個數據量比想像的要大很多，大家平常不會關注這個。它本身是典型的海量存儲的應用場景，而且是非結構化數據和結構化數據結合，它還有很多應用，公安部門要通過這些數據做很多查詢、檢索功能。巨杉資料庫在數據量非常大的城市，作為公安系統底層數據存儲，已經運行了大概一年多，目前效果非常好。

除了傳統的商業用戶，在互聯網也有成功的案例。資源系統以及套餐推薦，本身數據量非常大，後台使用的是巨杉資料庫，使用了好幾年，目前運行效果良好。

提問

1）問：系統最大支持多少TB的數據，設計上支持多少節點？

喬國治：沒有節點限制，我們在邏輯上沒有限制，數據量也沒有限制，只要你有資源、磁碟、機器都可以支持。實際中，在銀行里現在做到歷史數據平台達到2PB以上了。

2）提問：跟MPP和Hadoop之間是怎樣的？

喬國治：它不是某一種產品，而是某一種技術。至於跟Hadoop，Hadoop本身是橋樑數據存儲非常好的平台，它有很高的數據吞吐量，用在數據檢索方面很困難。你可以用Hbase來做檢索，但是它不支持多索引，你可以通過其他方式支持，使用起來不太方便。在並發性能上，我們可以很自信的說我們絕對比Hbase好很多。

3）問：MPP有網路風暴的問題？

喬國治：對，這並不是哪家技術限制的問題，而是大家都會面臨的問題，因為數據之間有複製、網路之間的交換，肯定會面對網路問題。我們建議用戶在實際使用中至少使用千兆之上的網卡，最好能使用萬兆網卡，這樣網路就不是問題。

現場提問：之間關於水平和垂直劃分，能否理解為時分和子分，在地方和地址上。

喬國治：時間劃分是最典型的分析案例，可以這麼理解，但是垂直分區並不是只有時間可以，你有全國幾百個城市的數據，如果城市數據是均勻的，你可以用代碼做分區。你可以這樣理解，可以幫助你很好的利用。水平分區，它的本質是哈希值的均勻分布。關於查詢索引，有沒有什麼更好的方法，當用戶輸入的數據不夠用，並不是用戶自己想的。

4）問：在你們開發過程中只展示了優點，我想知道缺點有什麼？

喬國治：缺點大家都有的。我覺得這個問題更多的是一種擔心，每個廠商、產品都有自己的特別和不足，相對我們來講，我覺得很多人的疑問，我們跟很多用戶交流，我們本身是從頭到尾自己開發的資料庫產品，都是中國團隊自己做的，這有一定的難度，意味著產品的成熟和完善需要時間，過程中一定會遇到大家的質疑。

很多人認為「中國人不可能自己做資料庫，你才做了幾年就可以用了。」我們研發資料庫確實有挑戰，這肯定是需要時間完善的，我們產品從開始做到最終向傳統商業資料庫似的成熟完善，肯定需要時間，目前還沒到這個階段，我們肯定會越做越好，我們的目標是達到傳統成熟商業資料庫的使用水平，過程中肯定會面對很多困難，希望得到大家對國產資料庫的支持，謝謝！

5）問：我很早之前了解這個資料庫，對於中國人來說，這個資料庫絕對是比較先進的。包括阿里的，感覺這個資料庫在技術上比較優秀。你的資料庫底層有三部分存儲，包括讀寫分離、冷熱分離，如何保證在數據的一致性和性能，為了保證一致性，某種程度會犧牲性能。

喬國治：感謝您對我們產品的認可，你談到非常典型的CAP的問題，在P發生的時候，你是取C還是取A？這個理論被證實，不可能二者兼得。你保證了一致性，可用性就會降低，你提到多副本，三副本的情況下，我們是一組兩從，在這種情況下有最終一致性，不是強一致。你可以理解為更偏向A，在C上有某種程度的降低，在一些非常極端的情況下。這只是默認的模式。本身我們的產品也提供針對C的技術手段，我們還是以三副本為例，我們可以支持寫操作、寫一副本，我們也可以支持寫兩副本、三副本，這可以自定義。每次寫操作都是三副本，三個都寫完再返回，這是一致，任何一個節點掛了都沒有關係，除非三個都掛了。在這種情況下付出的代價是什麼？A會有很大的下降，每次寫入的性能會有很大的降低。你指定三副本，你的網路斷掉，其中一個節點不能連通，這個寫可能永遠都不能完成，為了保證C，可能永遠失去A，沒有人可以C和A兼得。如果你想在某一方面達到這家，必然犧牲另一方面。

6）問：簡單談談你在哪些方面做的優化？

喬國治：對於HBase我理解它為一個列存資料庫，所以作為行存資料庫里有很大天然的問題，一旦與查詢相關，它會比較差，這是列存資料庫天然的弱勢。我們公司研發團隊都有企業級產品的基因，寫代碼的時候會把性能和企業級的性能放在第一位，這是固化在他腦袋裡的東西，所以他每寫一行代碼，自主不自主的會考慮這個問題。關於MongoDB，我覺得Mongo做得比較好的是他對使用者的應用型很好，但是性能一開始不會那麼好，但他們在不斷改進，不斷推新版本，性能在逐漸改進，但有一些天然的差距。也許未來某一天會改變，我們跟Mongo相比不相上下，我覺得這是好事，大家互相競爭，共同成長。

SequoiaDB巨杉資料庫2.6最新版下載

SequoiaDB巨杉資料庫技術博客

SequoiaDB巨杉資料庫社區
推薦閱讀：