8月5日，深信服首席算法技術專家章博在信服云《云集技術學社》系列直播課上進行了《數(shù)據(jù)庫概念、分類和未來》的分享，對數(shù)據(jù)庫基礎概念、常見數(shù)據(jù)庫種類和使用場景進行介紹，詳細解釋不同數(shù)據(jù)架構的優(yōu)劣，破除常見誤區(qū)。

看點一：數(shù)據(jù)庫是什么？

數(shù)據(jù)庫定義

大家可能對數(shù)據(jù)庫這個詞都不陌生，我們最常說的數(shù)據(jù)庫，也就是Database這個詞，原則上它指的是按照一定格式存儲數(shù)據(jù)的文件的組合，也就是說硬盤上的數(shù)據(jù)庫的文件和數(shù)據(jù)，要按照某種特定的格式去組織，這個就是所謂的數(shù)據(jù)庫。

為了去使用數(shù)據(jù)庫，我們一般需要一整套的數(shù)據(jù)庫管理系統(tǒng)，也就是Database Management System （DBMS），即科學的對數(shù)據(jù)庫文件進行組織、索引、查詢、修改的一套管理軟件，常見的數(shù)據(jù)庫管理系統(tǒng)有MySQL、Oracle、SQL Server、DB2等。

但是僅僅DBMS本身并不能提供各種各樣的能力，我們還需要圍繞DBMS去構造由硬件操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)，乃至包括數(shù)據(jù)庫管理員以及相關的機制配套組成的一整套數(shù)據(jù)庫系統(tǒng)，才能順利的執(zhí)行工作。這一套系統(tǒng)一般稱之為Database System。

與常見的數(shù)據(jù)管理軟件Excel相比，數(shù)據(jù)庫會管理一些更大量的數(shù)據(jù)，比如說千萬行以上的甚至億萬行以上的數(shù)據(jù)。一般Excel是單人使用的，數(shù)據(jù)庫是很多的用戶同時使用，而且可以進行高并發(fā)的訪問。此外，數(shù)據(jù)庫也有更豐富更復雜的數(shù)據(jù)處理能力，在安全機制的保障上，Excel作為一個辦公軟件只能提供密碼的基礎管理能力，而數(shù)據(jù)庫能夠提供完整的安全機制，比如說像是權限的校驗（表級別的、行級別的、列級別的權限控制），以及我們可以做一些數(shù)據(jù)備份來更好的保證數(shù)據(jù)的安全，這就是數(shù)據(jù)庫管理系統(tǒng)一個主要的好處。

數(shù)據(jù)庫的四個重要概念

（1）索引

數(shù)據(jù)庫經(jīng)常有上百/千萬條記錄，單條查詢會很慢，而索引的功能就像新華字典的前幾頁“索引”目錄靠拼音或偏旁排序來查詢字詞，能大幅度提高查詢速度。

（2）事務

數(shù)據(jù)庫提供了一種機制，就是一件事，必須做完，如果中間出了差錯，他會清理掉一切痕跡，回到最初狀態(tài)，這對于保持數(shù)據(jù)的一致性和完整性有功不可沒的作用。

（3）聯(lián)合查詢

一份數(shù)據(jù)通常解決不了實際問題。比如有兩份數(shù)據(jù)，一份是《員工基本信息》，另一份是《工資表》，這個時候，要查詢某某員工的工資，就要結合起來做“聯(lián)合查詢”。

（4）SQL

SQL就是用來操作數(shù)據(jù)庫里數(shù)據(jù)的工具，類似吃飯時使用“筷子”獲取食物。

看點二：數(shù)據(jù)庫的分類

數(shù)據(jù)庫可以分為三個維度來分類：第一個維度是按照模型分類，可以分為關系型和非關系型的數(shù)據(jù)庫。第二個維度是根據(jù)數(shù)據(jù)庫的使用場景進行分類，主要分為事務性OLTP和分析型OLAP兩類。第三種是從數(shù)據(jù)庫架構進行分類，可以分為單點數(shù)據(jù)庫和數(shù)據(jù)庫集群。

按模型分類

按照模型劃分，一般把數(shù)據(jù)庫分成關系型和非關系型兩個類型。關系型模型由于其優(yōu)秀的表達能力、嚴格的數(shù)學定義和良好的執(zhí)行效率被廣泛采用，而采用關系型模型組織數(shù)據(jù)的數(shù)據(jù)庫就被稱之為關系型數(shù)據(jù)庫，如 Oracle，MySQL 等。關系型數(shù)據(jù)庫也成為了現(xiàn)在最主流的數(shù)據(jù)庫模型。

而在一個關系型的數(shù)據(jù)模型上，提供的查詢語言就是結構化查詢語言（Structured Query Language）。這樣的語言是整個數(shù)據(jù)庫現(xiàn)在能蓬勃發(fā)展的一個關鍵所在，因為它是高級的非過程化的編程語言，比如常見的C語言或者Python編程語言，它都是所謂的過程化編程語言，當需要它做什么的時候，需要一步一步把過程的每一個階段全部編寫好，才能夠順利的進行。但SQL是一個高級的非過程化語言，只需要用戶描述需要取得什么樣的數(shù)據(jù)，具體的執(zhí)行流程就由優(yōu)化器由甚至系統(tǒng)自動去完成了。所以整個SQL語言的學習和使用非常簡單，用戶不需要了解具體的數(shù)據(jù)組織和處理的細節(jié)，也不需要去了解如何能讓它高效的執(zhí)行，所有的事情全部都是自動的。

非關系型數(shù)據(jù)庫是通過關系型以外的數(shù)據(jù)模型對數(shù)據(jù)進行組織的數(shù)據(jù)庫，通常在特定場景下具有較高的性能和可擴展性。典型 NoSQL 數(shù)據(jù)庫有：（1）鍵指數(shù)據(jù)庫：Redis、Memcache ——常用于緩存；（2）列族數(shù)據(jù)庫：HBase，Cassandra——常用于 Schema 頻繁變更的大寬表數(shù)據(jù)；（3）文檔數(shù)據(jù)庫：MongoDB —— 常用于存儲JSON文件；（4）圖數(shù)據(jù)庫：Neo4j——常用于知識圖譜等圖數(shù)據(jù)組織。

按場景分類

數(shù)據(jù)庫還可以按照不同場景進行分類，主要的兩個場景是OLTP和OLAP。OLTP是比較常見的業(yè)務系統(tǒng)，比如銀行的交易系統(tǒng)、零售交易系統(tǒng)、企業(yè)中的ERP系統(tǒng)、醫(yī)療的CASE系統(tǒng)等。這些數(shù)據(jù)庫系統(tǒng)里面的數(shù)據(jù)基本上都是OLTP類型的，支持實時交易數(shù)據(jù)的存儲、更新、共享。

這類系統(tǒng)下，數(shù)據(jù)不斷發(fā)生，不斷更新，可能有很多人在同時去訪問，因此需要的并發(fā)也比較高，每次更新都希望反饋的延遲非常低，比如說毫秒級的場景，就是OLTP的場景。

OLAP與我們主要做數(shù)據(jù)分析和現(xiàn)在的所謂的大數(shù)據(jù)，也有很多的相似之處，比如BI系統(tǒng)或者說建設數(shù)據(jù)倉庫，會把很多的歷史數(shù)據(jù)匯聚過來，然后做一些綜合的分析，希望從中提取一些數(shù)據(jù)規(guī)律，或者做一些數(shù)據(jù)挖掘。這一類的需求基本上對數(shù)據(jù)沒有很大頻繁的修改，但是一次要訪問的數(shù)據(jù)量非常的大，所以不太看重系統(tǒng)的延期，但很看重數(shù)據(jù)庫的吞吐。這樣的場景其實就是OLAP場景下常見的數(shù)據(jù)庫。

按架構分類

數(shù)據(jù)庫也可以按照不同架構進行分類。常見的數(shù)據(jù)庫是單節(jié)點的數(shù)據(jù)庫，因為單節(jié)點可能有一些單點故障的問題。如果有更大的數(shù)據(jù)量的需求，單節(jié)點的數(shù)據(jù)庫沒有辦法承載，或者需要更大的并發(fā)，而此時單點數(shù)據(jù)庫也沒有辦法承載。這個時候在單節(jié)點基礎上就發(fā)展了一系列的數(shù)據(jù)庫集群架構。

數(shù)據(jù)庫集群架構主要分成三類模式，第一個需要更高的可用性，比如基于組成復制的數(shù)據(jù)庫集群架構或者基于一致性協(xié)議的多活數(shù)據(jù)庫集群?；趶椭频臄?shù)據(jù)庫集群是最常用的多節(jié)點數(shù)據(jù)庫架構，它能夠消除單點故障，同時通過讀寫分離提升性能?；谝恢滦詤f(xié)議的多活數(shù)據(jù)庫集群則是無需第三方仲裁，自維護的多活集群架構，它可以在多數(shù)派存活條件下可提供服務。

第二個是很多時候在高可用的情況下，遇到面臨單節(jié)點的數(shù)據(jù)庫性能不夠、并發(fā)不夠的問題，這個時候就需要橫向擴展技術。最經(jīng)典的橫向擴展技術就是基于 Shared Disk 的數(shù)據(jù)庫集群，它是基于Shared Disk的共享存儲，然后上面可能會有多個節(jié)點來共同執(zhí)行數(shù)據(jù)庫操作的Oracle RAC 的經(jīng)典架構。它的特點是存儲計算分離，通過高速網(wǎng)絡和分布式存儲替換傳統(tǒng)陣列來提升性能。

但基于Shared Disk的數(shù)據(jù)庫集群的擴展能力存在限制，難以擴展到百節(jié)點以上的超大規(guī)模集群，因此就有了基于Share-Nothing的數(shù)據(jù)庫集群。它的每個節(jié)點獨立，具有最強的擴展能力，可擴展至數(shù)百甚至數(shù)千節(jié)點規(guī)模。能支持超大規(guī)模并發(fā)的基于Share-Nothing數(shù)據(jù)庫集群一般以更高和更不穩(wěn)定的時延為代價，但是由于和Shared Disk并非完全互斥關系，Share-Nothing集群的每一個節(jié)點本身可以是一個Shared Disk 多活集群，從而可以結合兩種架構的優(yōu)勢。

OLTP 場景下的 Share-Nothing 分布式數(shù)據(jù)庫雖然數(shù)據(jù)是分布式存儲和管理的但是單一 SQL 語句的執(zhí)行大多還是由單一節(jié)點執(zhí)行。相對的，第三類架構就是在OLAP場景下我們需要更大的吞吐時，計算也需要多個節(jié)點進行分布式處理，這一架構被稱之為 MPP (Massively Parallel Processing)。

看點三：數(shù)據(jù)庫發(fā)展趨勢

李國良教授的《數(shù)據(jù)庫發(fā)展趨勢》中介紹，新一代的數(shù)據(jù)庫其實有4個主要的發(fā)展方向，一是隨著硬件的發(fā)展有更多的新的硬件技術被利用下來；二是隨著數(shù)據(jù)模型的發(fā)展，會支撐更多的數(shù)據(jù)模型；三是Scalability進一步提升，最后還有Deployment的種類會變得更加的豐富。

針對種類更加豐富的發(fā)展趨勢，章博在此介紹了幾個比較廣泛認知的數(shù)據(jù)庫。一個是現(xiàn)在常見的一個詞叫做HTAP，就是既要有TP的特性，又要有AP的特性。在傳統(tǒng)的架構下，一般通過ETL把TP的數(shù)據(jù)按照天或者周的周期去導入到一個AP的系統(tǒng)，用兩個不同的系統(tǒng)去承載它，但是傳統(tǒng)架構的時效性不足。當需要實時分析時，HTAP就派上用場了，HTAP通過復制或者在同一個引擎里同時做行列混合存儲，既能支持實時的數(shù)據(jù)更新，又可以支持比較高的數(shù)據(jù)吞吐。但是HTAP系統(tǒng)不會用來去直接替代TP系統(tǒng)，一般來說它還是更偏向用于實時分析的補充。

AI也是非?；馃岬囊粋€詞，在數(shù)據(jù)庫領域的話就有兩大的分支，一個是AI4DB，就是如何使用AI技術讓數(shù)據(jù)庫的可維護性變得更強。另外一個是DB4AI，DB4AI就是如何對AI的數(shù)據(jù)進行管理，通過一個很完善的數(shù)據(jù)庫管理系統(tǒng)管理AI的數(shù)據(jù)，讓 AI的開發(fā)和迭代更有效。

最后，這幾年新的硬件技術發(fā)展得也非常的快，對整個數(shù)據(jù)庫系統(tǒng)的優(yōu)化起著非常大的效果。一個是利用Intel SPDK將NVME SSD性能發(fā)揮到極限，另一個是支持RDMA高速網(wǎng)絡。

本期回放鏈接：http://sangfor.bizconf.cn/live/watch/?id=oygey64o