資料庫的選型一直是一個困擾着采購人員和DBA的問題，既需要立足于當下，提供高可用的服務，又需要着眼于未來，給予足夠的擴充空間以适應項目的發展壯大。針對這個問題，本文嘗試着從資料庫類型的角度談一談資料庫選型的最佳實踐。
一、引言
如前所述，為項目進行資料庫選型着實是一件頭疼的事，不同的角色在選型時可能會有不同的考量。采購人員會更關注于成本及供應商資質，而DBA則會更多考慮資料庫本身的性能、穩定性、擴充性等。不可否認的是，很多情況下我們可能會遇到下面這種情境。
如果你曾經使用過某類資料庫，你可能會說“我隻會選擇 X，那是我所知道并使用過的資料庫”，當然，如果性能不是重要考量标準的話，這是完全可以的。否則，當項目規模發展時，錯誤的資料庫可能會成為項目的障礙，并且有時還很難修複。即使你正在負責一個已經使用某個特定的資料庫一段時間的成熟項目，了解其局限性并清楚何時應在堆棧中添加另一種類型的資料庫（多個資料組合工作是很常見的）也是很重要的。
了解不同資料庫及其屬性的另一個加分原因是，它是面試中的一個常考題！
在下文的内容中，我們将會讨論兩種主要的資料庫類型：
- 關系型資料庫（基于 SQL）
- NoSQL 資料庫
我們将讨論不同類型的 NoSQL 資料庫以及何時使用它們。最後，我們還會讨論關系型資料庫與 NoSQL 資料庫的優缺點。這篇文章将不會涉及對同類型資料庫的不同産品之間的比較。
二、關系型資料庫（基于 SQL）
關系型資料庫由一組連接配接起來的表（比如 CSV 表）組成。表中的每一行代表一條記錄。
為什麼叫關系型? 在這種資料庫中存在的“關系”是什麼？假設你有一個學生資訊表和一張課程成績表（課程，成績，學生證），每個成績行都與學生資訊表的一條記錄相關。參見下圖，課程成績表中 “Student ID” 列的值通過 “ID” 列的值指向 “Students” 表中的行。
所有關系型資料庫都使用類似 SQL 的語言進行查詢，這些語言很常用，并且自帶 JOIN 操作（即連接配接操作，用于把來自兩個或多個表的行結合起來，如上文的學生資訊表和課程成績表）。這種資料庫支援對列進行索引，使得基于這些列能進行更快的查詢。
由于其結構化的特性，關系型資料庫的 schema（schema 指資料庫中資料的組織和結構）是在插入資料之前确定好的。
常見的關系型資料庫： MySQL、PostgreSQL、Oracle、MS SQL Server。
三、NoSQL 資料庫
雖然在關系型資料庫中，所有内容都是按行和列進行結構化好的，但在 NoSQL 資料庫中，并沒有針對所有記錄通用的結構化的 schema。大多數 NoSQL 資料庫存儲的是 JSON 記錄，不同的記錄可以包含不同的字段。
實際上，應将 NoSQL 資料庫稱為“not only SQL” —— 因為許多 NoSQL 資料庫支援使用 SQL 進行查詢。
NoSQL 資料庫按照存儲結構主要分為 4 種類型：
1.文檔存儲資料庫
文檔存儲資料庫的原子機關是一個文檔（document）。每個文檔都是一個 JSON，不同文檔可以有不同的 schema，包含不同的字段。文檔存儲資料庫允許對文檔中的某些字段建立索引，進而能夠基于這些字段進行更快的查詢（這将會強制所有文檔都具有該字段）。
文檔型資料庫适用于資料分析，由于不同的記錄之間并不互相依賴（在邏輯和結構方面），是以這種資料庫支援并行計算。我們可以借助它來輕松地對資料進行大資料分析。
常見的文檔存儲資料庫： MongoDB、CouchDB、DocumentDB。
2.列存儲資料庫
列存儲資料庫的原子機關是表中的一列，這意味着資料是按列存儲的。它的列存儲特點使得基于列的查詢非常高效，并且由于每列上的資料幾乎擁有相同的結構，是以可以更好地壓縮資料。
列存儲資料庫傾向于查詢資料中的一個列子集時（每次查詢的資料不需要都是相同的子集！）。列存儲資料庫執行此類查詢的速度非常快，因為它隻需要讀取這些特定的列（而基于行存儲的資料庫則必須讀取整個資料）。
- 這在資料科學中很常見，其中每一列代表一個特征。作為一名資料科學家，我經常使用特征子集來訓練我的模型，并且通常還會檢查特征和得分之間的關系（相關性、方差、顯著性）。
- 這在日志中也很常見 —— 我們通常在日志資料庫中存儲很多字段，但在每個查詢中隻使用幾個字段。
常見的列存儲資料庫： Cassandra。
3.key-value 存儲資料庫
查詢僅基于鍵 —— 當你請求一個鍵，便會拿到對應的值。不支援跨不同記錄值之間的查詢，比如 “select all records where city == New York”。這種資料庫中一個有用的特性是 TTL 字段（time to live），當記錄将要從資料庫中删除時，這個字段可以為每個記錄和狀态設定不同的值。
key-value資料庫的優勢在于其處理速度很快。首先是因為使用唯一鍵，其次是因為大多數 key-value 存儲資料庫将資料存儲在記憶體（RAM）中，進而可以快速通路。 它的缺點是需要定義唯一的鍵，這些鍵是很好的辨別符，是在查詢時根據您所已知的資料建立的。通常比其他類型的資料庫更加昂貴（因為它是在記憶體上運作的）。
key-value資料庫主要用于緩存，因為它非常快，并且不需要複雜的查詢，而且 TTL 特性對緩存非常有用。它還可以用于需要快速查詢并滿足 key-value 格式的任何其他類型的資料。
常見的 key-value 存儲資料庫： Redis、Memcached。
4.圖存儲資料庫
圖存儲資料庫包含代表實體的節點和代表實體之間關系的邊。如果資料是類似于知識圖譜和社交網絡這種圖時适合選擇圖資料庫。
常見的圖存儲資料庫： Neo4j、InfiniteGraph。
四、關系型資料庫 VS 文檔存儲資料庫
鑒于文檔型資料庫，尤其是MongoDB近年來的火熱，我們簡要分析一下關系型資料庫和文檔型資料庫各自的優劣勢。當然，這兩者之間不存在優勝劣汰的關系，沒有一個資料庫能夠解決所有問題，選擇适合自身需求的資料庫才是上上之選。
關系型資料庫的優點
- 資料結構簡單，可以比對項目中常見的大多數類型的資料
- 使用 SQL。SQL 很常用，并且天生支援連接配接操作
- 允許資料的快速更新。所有資料庫都儲存在一台機器上，記錄之間的關系用作指針，這意味着您可以一次更新一條記錄，而它的所有相關記錄也将立即更新
- 關系型資料庫也支援原子事務。什麼是原子事務：假設我想把 X 美元從 Alice 賬戶轉移到 Bob賬戶。我想執行 3 個操作：減少 Alice 賬戶 X 刀，增加 Bob 賬戶 X 刀，最後記錄下這個交易事務。我想把這些動作當作一個原子機關 —— 要麼所有的動作發生要麼一個都不發生
關系型資料庫的缺點
- 由于每個查詢都在表上完成 —— 查詢執行時間取決于表的大小。這是一個重要的限制，要求我們保持表相對較小，并在我們的資料庫上進行優化以實作可伸縮性
- 在關系型資料庫的擴充中，可以通過向運作資料庫的計算機增加更多的計算能力來進行擴充，這種方法稱為“縱向擴充”。為什麼這是一個缺點呢？這是由于計算機能夠提供的計算能力有限，而且向計算機擴充資源可能需要一些停機時間
- 關系型資料庫 不支援 OOP，不支援面向對象，即使表示簡單的清單也是非常複雜的
文檔存儲資料庫的優點
- 可以儲存具有不同結構的對象
- 可以使用 JSON 表示幾乎所有的資料結構，包括基于對象的 OOP、清單以及字典
- 雖然 NoSQL 本質上是無模式的（指不需要像關系型資料庫一樣将預定義的結構，即 schema ，向資料庫說明），但它通常支援模式驗證，這意味着您可以使一個資料集合模式化，此模式不會像表那麼簡單，它是一個帶有特定字段的JSON schema。（譯者注：這裡所說的模式就是 schema）
- NoSQL 查詢非常快，每條記錄都是獨立的，是以查詢時間與資料庫大小無關，并且支援并行性
- 在 NoSQL 中，通過添加更多的機器并在它們之間配置設定資料來擴充資料庫，這種方法稱為“水準擴充”。這允許我們在需要時自動向資料庫擴充資源，并且不會導緻任何停機
文檔存儲資料庫的缺點
- 在文檔存儲資料庫中更新資料是一個緩慢的過程，因為資料會在不同的機器之間進行劃分、複制。
- 大部分文檔資料庫不支援原子事務。可以通過使用驗證和恢複機制将其添加到代碼中，但是由于記錄是在機器之間劃分的，是以它不可能是一個原子過程，并且可能會出現競争狀況（注：MongoDB 4.0 版本已經提供了原生的事務操作）
五、總結
總的來說，資料庫的選型是一個較為複雜的過程，除了考慮項目本身的需求以确定合适的資料庫類型之外，還要結合資料庫的運維成本、性能、穩定性、擴充性、安全等因素進行綜合研判。從資料庫機構方面，我們對于資料庫的選型提供如下參考：
- 對于緩存 —— 使用 key-value 資料庫
- 對于類似圖形的資料 —— 使用圖資料庫
- 如果傾向于查詢列子集以及查詢特征 —— 使用列存資料庫
- 對于所有的其他用例 —— 使用關系型資料庫或者文檔存儲資料庫
文章來源：錄信數軟_https://zhuanlan.zhihu.com/p/402635688