作者：馬超，溫柔的程式員爸爸
本文轉自公衆号CSDN（ID：CSDNnews） 
去“IOE”這個概念，最早由王堅院士在剛剛加入阿裡時提出，其目标是将IBM 的小型機、Oracle資料庫、EMC儲存設備從阿裡的IT體系中去除，代之以自主研發的系統。
而随着我國IT技術棧的不斷演進，去“IOE”已經由一個企業的目标，變成了整個行業的目标，也就是我國必須使資訊系統資料，運作在自研系統之上，以防止資料丢失造成的一系列嚴重後果。
作為一名長期在金融機構工作的IT人，提起對外核心技術依賴時，就不由得想起銀行業的心髒——支付系統（CNAPS），原本都是世界銀行的援建産物，直到2013年底我們才用自研的二代支付系統将其取代。
回想“IOE”這些年，我國的确在一些很多IT領域取得了長足的進步，比如目前我國移動支付水準就實作了對歐美國家的反超，足以獨步世界。
近日，金山辦公正式登陸科創版，也标志着雷軍夢圓國産Office的“英雄之路”。可以看到這種應用級别的自主掌控，對于我國IT業來說已不是難事。
而且随着國産雲計算服務水準的不斷發展，國外廠商的小型機和存儲，已經不多見，不過IOE中的O也就是Oracle、DB2等國外廠商的資料庫，還依舊在我國市場大行其道。
這也反映出，近年來我國IT的一個現象，那就是硬體內建與應用等領域強，但是基礎設施突破少。
01 支付寶的核心：OceanBase
OceanBase 是螞蟻金服自研的金融級分布式關系資料庫，号稱每一行代碼都是自主編寫的。
在十年前，阿裡的IT人，決定自主研發一款分布式金融級資料庫，曆經磨練後OceanBase已經能在普通硬體上，實作金融級高可用，并在業内首創“三地五中心”城市級故障自動無損容災新标準，同時具備線上水準擴充能力，并且勇奪TPC的冠軍。
02 深植于場景需求混布資料庫：Hubble
Hubble是天雲資料研發的HTAP資料庫。所謂HTAP其實就是混合了TP和AP兩種模式的資料庫。
坦率講，筆者在剛開始聽到一種産品，既能提供TP服務、又能提供AP服務時，感到非常驚訝。
因為，OLAP（On-Line Analytical Processing）是指聯機分析技術，打個比方，OLAP就像是私人飛機服務，不計較成本但是要求響應速度，主要用于使用者聯機交易的處理響應。
而OLTP（on-line transaction processing)，則是指聯機事務處理，OLTP的最大訴求就是低成本的處理海量資料，有點像海上運輸，雖然處理資料量大但是速度慢，适合于客戶曆史帳單查詢、客戶畫像分析等大資料方面的應用。
以前AP應用的流程比較固定，就像一個儀表盤，隻有一兩個數倉的管理者在看，但現在那些原本投在大屏的可視化項目，已經全部被推送到了移動端，這也就是TP+AP的個性化數字倉庫的需求。
比如一個營業廳應用有六萬多人，同時線上需要至少五百個并發/秒，理财經理要在某一時刻，看到大客戶的結息、淨值等一系列的資料服務，且都是個性化的。
這也就意味着，目前在應用領域，有強烈的需求把AP推到TP的場景裡，這兩者有機結合，對于大多數人來說，還隻是個想法。
不過這兩個看似沖突的目标，竟然真的被天雲資料，結合到一起了。其關鍵技術有以下幾個方面：
一是在KV資料，再加一層KV索引、以适應高并發的TP需求。
二是通過将全局事務向本地事務鎖進行轉換，來保證系統的分布式計算一緻性。
三是通過資源控制子產品，完成TP與AP的結合使用。
03 SQL引擎與NoSQL存儲的結合：巨杉資料庫
SequoiaDB 巨杉資料庫，是一款金融級分布式關系型資料庫，也是一款開源産品。筆者認為SequoiaDB最大的貢獻在于将标準SQL、事務與NoSQL的分布式存儲相結合。
Github位址：
https://github.com/SequoiaDB/SequoiaDB巨杉資料庫使用JSON為标準存儲格式，既可以描述關系型結構，能最大限度保留現有的應用資産；也可以描述非關系型結構。
這些使巨杉，可以把非結構化的檔案和結構化的描述項一起存儲，而不是索引+檔案存儲，進而實作适當降低範式次元和JOIN操作的複雜度。
而且，在分布式存儲的基礎上，其還添加了分布式SQL引擎，借此可以提供高并發、低延時和批量計算SQL能力以及ACID和事務支援。
其整體架構如下：
巨杉資料庫在金融領域應用案例很多，相信他們SQL引擎與NoSQL存儲的理念還會支撐他們越走越遠。
04 産品線齊全的資料庫：GBase和達夢
武漢達夢和天津南大通用，絕對算得上是國内資料庫廠商中産品線最齊全的兩家了。據筆者不完全統計，南大通用打造了GBase 8a、8t、8m、8s、8d、UP、InfiniData一體機等多款資料庫軟硬體産品，而達夢也不遑多讓他們産品線包括了達夢7、8、ETL、TDD、HS、MPP等等。下面挑重點向大家介紹。
GBase 8a：就是我們日常所熟知的用于大資料分析的系統庫。
GBase 8a能夠實作大資料存儲管理和高效分析，據測試，它能在PB級資料規模下，實作資料查詢的秒級響應；實作千億級文本條目全文檢索的秒級響應；并且提供全過程可視化的資料查詢分析及展現工具。
GBase 8t：一款對标Oracle的資料庫。據稱，其OLTP事務處理性能，已達到Oracle資料庫的水準，能夠在90%以上的場景中替代Oracle。
GBase 8t的關鍵技術有如下幾方面：
-
事務機制
完全支援傳統主流事務資料庫的事務機制鎖技術，有效支撐高度并發的事務密集型應用場景。
-
存儲技術
GBase 8t産品的存儲有實體的和邏輯的兩種結構。實體結構中包含資料卷（Chunk）、資料段（Extent）和資料頁（Page）；邏輯結構包含資料空間（DbSpace）和表空間（TableSpace）。
-
索引技術
GBase 8t産品提供了索引技術來提升資料查詢操作的性能。GBase 8t産品支援的索引包括B-Tree索引、R-Tree索引、函數索引和使用者自定義索引。
-
高可用技術
GBase 8t産品提供了高可用叢集技術，使用這些技術可以滿足資料複制、共享存儲、同城備份、遠端容災和兩地三中心的整體災備解決方案的要求。
目前，Gbase和達夢的産品均已經在金融、電信、電力等多個行業得到應用與驗證了，使用場景非常廣泛可謂我國國産資料庫的雙子星座了。
05 物聯網時代的資料庫TDengine、CTSDB
随着網際網路的高速發展、大資料的迅速膨脹和物聯網的飛速崛起，我們發現生活和工作中的大部分資料漸漸和時間産生了關聯。
比如，微信運動的實時步數、股票每天的收盤價格、共享單車的裝置狀态等等。為了存儲這些與時間相關的資料使用傳統資料庫其實問題很多。
比如，傳統關系型資料庫，在存儲海量的時序資料場景下，存在的問題：
- 存儲成本大：對于時序資料壓縮不佳，需占用大量機器資源；
- 維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；
- 寫入吞吐低：單機寫入吞吐低，很難滿足時序資料千萬級的寫入壓力；
而Hadoop等NoSQL資料庫也有問題：
- 資料延遲高：離線批處理系統，資料從産生到可分析，耗時數小時、甚至天級；
- 查詢性能差：不能很好的利用索引，依賴MapReduce任務，查詢耗時一般在分鐘級。
讓你以在物聯網時代需要與之特點相應的資料庫産品來提供服務，目前我國在時序資料庫方面主要有TDengine、CTSDB兩款産品。
這裡主要帶大家了解一下騰訊時序資料庫CTSDB：CTSDB（Cloud Time Series Database）是一種分布式、高性能、多分片、自均衡的時序資料庫，針對時序資料的高并發寫入、存在明顯的冷熱資料、IoT使用者場景等做了大量優化，同時也支援各行業的日志解析和存儲，其架構如下圖所示。
在CTSDB和磁盤之間有一層FileSystem Cache的系統緩存，以使得能夠更快地處理搜尋請求。
作為騰訊唯一的時序資料庫，CTSDB支撐了騰訊内部20多個核心業務（微信彩票、财付通、雲監控、雲資料庫、雲負載等）。
其中，雲監控系統的記錄了騰訊内部各種軟硬體系統的實時狀态，CTSDB承載了它所有的資料存儲，在每秒千萬級資料點的寫入壓力、每天20TB+資料量的寫入場景下穩定運作，足以證明CTSDB可以穩定支撐物聯網的海量資料場景。
06 互通有無，共同成長
除了上述這些資料庫之外，我國還有不少基于MySQL、PosgreSQL等開源資料庫核心研發的産品。
比如騰訊基于MySQL的TDSQL、華為基于PosgreSQL的GaussDB、中興同樣基于MySQL的GoldenDB，他們也都得到了相當廣泛的應用。
尤其是承載着微衆銀行和威富通等多個重量級金融應用的TDSQL，憑借遠超開源版MySQL的性能，真正做到了青出于藍而勝于藍。
可以說，我國自研資料庫在各個方面，都已取得極大進步，這裡也呼籲，國内資料庫廠商能盡量将社群版本開源，與業界互通有無，共同成長。