數據庫不只是Mysql，你需要知道這些才能拿到offer

有大半年的時間沒有跟新微信公衆號了。上半年疫情的影響，過年之後一直在家辦公。直到快4月纔開始去公司辦公。疫情期間在線教育快速發展，7-9月教育行業暑期大戰，持續忙了3個多月，因此也把公衆號丟了下來。很欣慰的看到參與的項目快速發展，慢慢走向正軌。自己也逐漸把公衆號撿了起來。

今天想跟大家聊一聊，數據庫相關的話題。

數據庫全景圖

提到數據庫，大多數人腦海中浮現都是mysql，sqlserver，oracle。其實，數據庫不只是這些。它還包括例如MongoDB，Cassandra，Es等其他的存儲形式。那麼，常見的數據庫有哪些？並且怎麼分類這些數據，以及該怎麼在不同場景下選擇不同數據庫呢?

首先，放一張"451Group"分析報告中的數據庫的全景圖

從圖中，可以看出，數據庫行業保羅萬象。包括了很多不同分類的產品。

數據庫分類

數據庫總的來看可以分爲三類：

關係型數據庫：例如mysql，sqlserver，oracle等
NoSql（非關係型數據庫）: 例如Redis,MongoDB,HBase等
NewSql：是對各種新的可擴展/高性能數據庫的簡稱，這類數據庫不僅具有NoSQL對海量數據的存儲管理能力，還保持了傳統數據庫支持ACID和SQL等特性。包括例如：lustrix、GenieDB、ScalArc、Schooner等。

下面分別介紹這三種類型的數據庫。

傳統的關係型數據庫

首先給出關係型數據庫一個官方定義：關係型數據庫：指採用了關係模型來組織數據的數據庫。關係模型指的就是二維表格模型，而一個關係型數據庫就是由二維表及其之間的聯繫所組成的一個數據組織。

關係型數據庫的優點：

1.容易理解：二維表結構是非常貼近邏輯世界的一個概念，關係模型相對網狀、層次等其他模型來說更容易理解

2.使用方便：通用的SQL語言使得操作關係型數據庫非常方便

3.易於維護：豐富的完整性(實體完整性、參照完整性和用戶定義的完整性)大大減低了數據冗餘和數據不一致的概率

關係型數據庫存在的問題:

高併發支持不夠：網站的用戶併發性非常高，往往達到每秒上萬次讀寫請求，對於傳統關係型數據庫來說，硬盤I/O是一個很大的瓶頸。
海量數據的挑戰：網站每天產生的數據量是巨大的，對於關係型數據庫來說，在一張包含海量數據的表中查詢，效率是非常低的
橫向擴展困難：在基於web的結構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。當需要對數據庫系統進行升級和擴展時，往往需要停機維護和數據遷移。
性能欠佳：在關係型數據庫中，導致性能欠佳的最主要原因是多表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢。爲了保證數據庫的ACID特性，必須儘量按照其要求的範式進行設計，關係型數據庫中的表都是存儲一個格式化的數據結構。

數據庫事務必須具備ACID特性，ACID分別代表Atomic(原子性)，Consistency(一致性)， Isolation(隔離性)，Durability(持久性)。

當今十大主流的關係型數據庫 Oracle，Microsoft SQL Server，MySQL，PostgreSQL，DB2， Microsoft Access， SQLite，Teradata，MariaDB(MySQL的一個分支)，SAP。

NoSQL

針對傳統關係型數據庫的缺點，爲了更好的適應現代互聯網高併發，高性能，高可用以及海量數據的挑戰的需要，出現了不同的NoSQL數據庫。 NoSQL放棄了傳統SQL的強事務保證和關係模型，重點放在數據庫的高可用性和可擴展性。

NoSQL 的主要優勢：

高可用性和可擴展性，自動分區，輕鬆擴展
不保證強一致性，性能大幅提升
沒有關係模型的限制，極其靈活 NoSQL主要的劣勢：
不保證強一致性：對於普通應用沒問題，但還是有不少像金融一樣的企業級應用有強一致性的需求。
NoSQL不支持SQL語句：兼容性是個大問題，不同的 NoSQL 數據庫都有自己的 api 操作數據，學習起來比較繁瑣。

NoSQL數據庫的分類

1. key-value存儲

以key-value對的形式存儲數據。value可以是自定義的不用的數據結構。這個類型的數據庫主要包括： | 數據庫 | 分類 | 特點 | | --- | --- | --- | | Redis | Key-value store,Document store,Graph DBMS,Search engine,Time Series DBMS | | | Amazon DynamoDB | Document Store，Key-value store | | | Couchbase | Document Store，Key-value store | | | etcd | Key-value store | | | Memcached | Key-value store | | | Ehcache | Key-value store | | | LevelDB | Key-value store| |

2. 文檔存儲

以比較自由的格式(通常爲JSON）的方式存儲文檔內容。這意味着：

記錄不需要具有統一的結構，即不同的記錄可以具有不同的列。
每個記錄的各個列的值類型可以不同。
列可以具有多個值（數組）。
記錄可以具有嵌套結構。常見的文檔存儲有： MongoDB，Amazon DynamoDB，Couchbase,CouchDB。

3. 寬列存儲

寬列存儲（也稱爲可擴展記錄存儲）將數據存儲在記錄中，並且能夠容納大量動態列。由於列名和記錄鍵不是固定的，並且一條記錄可以包含數十億列，因此寬列存儲可以看作是二維鍵值存儲。

寬列存儲與文檔存儲共享無模式的特性，但是實現卻大不相同。

在某些關係系統中，不能將寬列存儲與面向列存儲相混淆。這是一個內部概念，用於提高RDBMS針對OLAP工作負載的性能，並存儲表中的數據，而不是逐條記錄，而是逐列存儲。

列存儲使用場景：

行式存儲對於 OLTP 場景是很自然的：大多數操作都以實體（entity）爲單位，即大多爲增刪改查一整行記錄，顯然把一行數據存在物理上相鄰的位置是個很好的選擇。

然而，對於 OLAP 場景，一個典型的查詢需要遍歷整個表，進行分組、排序、聚合等操作，這樣一來按行存儲的優勢就不復存在了。更糟糕的是，分析型 SQL 常常不會用到所有的列，而僅僅對其中某些感興趣的列做運算，那一行中那些無關的列也不得不參與掃描。

列式存儲就是爲這樣的需求設計的。如下圖所示，同一列的數據被一個接一個緊挨着存放在一起，表的每列構成一個長數組。

常見的寬列存儲數據包括：Cassandra和HBase。

4. 圖存儲

圖DBMS，也稱爲面向圖的DBMS或圖數據庫，將圖結構中的數據表示爲節點和邊，即節點之間的關係。它們允許輕鬆處理該形式的數據，並且可以簡單地計算圖形的特定屬性，例如從一個節點到另一個節點所需的步驟數。

圖形DBMS通常不會在所有節點上提供索引，在這種情況下，無法基於屬性值直接訪問節點。常見的圖存儲包括：Neo4j，Microsoft Azure Cosmos DB 。

NewSQL

NewSQL提供了與NoSQL 相同的可擴展性，而且仍基於關係模型，還保留了極其成熟的SQL 作爲查詢語言，保證了ACID事務特性。簡單來講，NewSQL 就是在傳統關係型數據庫上集成了NoSQL 強大的可擴展性。

NewSQL 的主要特性：

SQL 支持，支持複雜查詢和大數據分析。
支持 ACID 事務，支持隔離級別。
彈性伸縮，擴容縮容對於業務層完全透明。
高可用，自動容災。主流NewSQL包括：TiDB,VoltDB,ClustrixDB等。上面介紹了三種類型數據庫（關係型數據庫，NoSQL，NewSQL），處了這些分類之外還有針對特定場景存儲的選型。比如可以用作搜索引擎的ES,Solar等，時間序列數據庫OpenTSDB，InfluxDB等。更加詳細的信息以及數據庫排名參見：DB-Engines。