合理規劃：如何為APP選擇正確的數據庫？
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)
從事新項目總是令人極度興奮——可以自由地以自己喜歡的方式設計和構建項目。但如果規劃得不合理，就會給未來帶來麻煩。需要作出的最關鍵的決定之一就是選擇APP數據庫，而此文的目的就是介紹數據庫的選擇方案——并列舉其優勢和弊端以幫你明智地選擇數據庫。
鍵值
數據庫的結構像JSON對象，每個鍵都是唯一的，每個鍵都指向某個值。
它把數據保存在內存中，運行速度快，但有容量限制，所以難以存儲大量數據。由于沒用到硬盤，因而運行非常的快。因為不涉及查詢或連接，因此不需要擔心數據建模。由于沒有模式，開發人員總是可以靈活地根據自己的喜好更改數據。
使用條件：
- 這種技術主要用作緩存機制，頻繁獲取和觀察數據的某些部分時使用。
- 因此，鍵值技術作為緩存機制，普遍與其他數據庫結合使用。
寬立柱
寬立柱像注射了類固醇的鍵值。值被修改為存儲一組列，而不僅僅是普通數據。
引入一組列之后，現在可以給相關數據分組，但仍沒有標準的模式。因此，每個鍵可以指向不同分組的數據。
由于沒有模式，它可以處理非結構化數據，并附帶一種名為CQL的查詢語言，類似于SQL，但功能要弱得多。數據以連續的流形式出現，比如來自物聯網設備、股票市場、金融交易或Netflix觀看歷史。
使用條件：
- 寫頻
- 不經常更新或讀取
它仍然不是通用的。因此，它可以用于存儲來自所有不同應用程序的歷史數據。
文檔型數據庫
它是我們使用的最流行的數據庫技術之一。很明顯，它包括文檔，每個文檔是一組鍵值對。它們是非結構化的、不需要模式。
文檔被分組到集合中，這些集合可以被構造成邏輯層次結構。邏輯數據集合以更有邏輯性的方式分組相關數據，它似乎與關系數據庫相似。
數據庫不能運行join查詢，怎么立刻獲得所有相關的數據呢?把它們全部儲存。鼓勵非規范化數據庫，已經做好會出現數據復制/不一致的準備。
讀取數據非常快，但編寫和更新數據的同時要保證一致性卻是一項挑戰。文檔數據庫非常適合通用應用程序，也可能非常適合大多數應用程序、游戲和物聯網。
若對數據庫模式不甚了解，則記錄數據庫是最佳啟動方式。
流行文檔型數據庫
數據量很多，而且數據之間有著直接或間接的關系時，文檔型數據庫無法容納。在這種情況下，必須運行多個復雜的查詢，然后在前端應用程序中合并所有接收到的數據，或者可以使用關系數據庫，其中這些復雜的查詢由數據庫管理。
關系數據庫
這類數據庫中，著名的一些包括MySQL, Postgres, and SQL Server。他們出現很長時間了，對于很對應用程序來說都是不錯的選擇。
想象一個汽車工廠，它有不同的輪轂來生產汽車部件。假設門是在一個地方制造的，而輪子、車身和內部零件都是在各自不同的地方制造的。
假設的車廠藍圖
每個制造的部件都有一個唯一的ID。所以一旦汽車組裝完畢，就可以從不同的地方取來所有的零件，然后組裝汽車。
建造這樣一個工廠需要制定藍圖，以確保整個生產過程非常高效和優化。這個藍圖在使用在數據庫中時稱為模式。因此，需要為數據庫規劃模式，以確保數據庫也有效性高，能滿足應用程序的數據需求。
缺點：
- 久而久之，改變車廠的布局就像改變要求一樣，會浪費汽車公司的時間和金錢。大型應用程序也面臨相似的情況。確保在要求清晰的情況下使用關系數據庫。
- 而且，一旦建立一個每月能制造30輛車的工廠，那么就很難把產量提升到90。同理，關系數據庫很難擴大規模，但也有例外，如Cockroach DB 和 PostgreSQL，在設計時添加了擴大規模的功能。
優點：
- SQL數據庫符合ACID標準，這意味著即使讀寫操作之間可能會失敗，數據有效性和完整性也不會受到損害-這使其非常適合與銀行/金融相關的數據。
- 一旦有了合適的模式，就可以確保存儲的數據將始終存儲在一組驗證之后的固定結構中，這些驗證先模式中得以定義。
哪個最適合你?
- 若要求清晰，不需要大幅改變要求，選擇這個。
- 若對需求不是很確定，并且處于某種試驗階段，那么最好使用NoSQL數據庫。
要是不需要建立模式，直接把關系存成數據，該用哪個呢?
圖表數據庫
數據存儲在節點中，關系被定義為邊。一起來看看怎么做。
要想在SQL數據庫里查找所有學習計算機科學的學生，則需要一個查找/中間人表，該表單獨存儲所有學習計算機科學的學生的記錄。
圖表更加簡單明了，因為不必分別存儲數據中的關系部分，而自動帶有新式數據。
關系更易于記錄和保持在圖表里
有了這個直接顯示兩個節點間的關系的新方式，復雜的聯接查詢變得更簡單，與SQL相比，極大地提高了數據的性能。因此，因依賴大量聯接操作而降低數據的性能時，可以使用這種數據庫。
可搜索數據庫
如果你正在構建一個像谷歌這樣的應用程序，在小字符串查詢搜索中，你必須快速返回所有匹配的記錄，那么這就是一個全文搜索引擎。這些數據庫基于始于1999年的Apache Lucene項目。
Algolia和MeiliSearch是全文搜索引擎。它們看起來類似于文檔類型的數據庫。有一個索引，并向它添加數據對象。搜索數據庫引擎將分析文檔中的所有文本，并創建稱為倒排索引的東西。
當你查詢某項內容時，數據庫只會檢查反向索引，這使得整個過程看起來異常迅速，即使對于大型數據庫也是如此。
多模式數據庫
可供選擇的數據庫有很多，但最流行的似乎是Fauna。作為應用開發者，我們通常只關心JSON，我們可以在應用前端使用它。有了Fauna，不必擔心數據建模、模式、縮放、復制或規范化過程，只需獲取JSON數據即可。使用GraphQL定義訪問數據的方式。
以一個類似instagram的應用程序的場景為例。將使用JSON為用戶、發布和查詢定義規則。
我們剛剛上傳了GraphQL模式，它會自動創建一個集合來存儲數據和查詢數據的索引。在幕后，它將考慮如何利用基于您提供的GraphQL模式的不同范例，如關系、圖表和文檔。只是簡單地以與在文檔數據庫中相同的方式添加數據，而且不會受到數據建模的限制。
優點：
- 它符合ACID標準、運行速度極快。
- 不必擔心基礎設施。只需定義對數據的需求，云端會解決其余的問題。
缺點：
- 價格明顯是個缺點。好的東西不是免費的，但是對于想要學習的開發人員以及小型創業公司，它們確實提供了慷慨的計劃/開源選項。
以下是Fauna列出的值得注意的重要特點：
這些并不是全部!要學習的不同的數據庫還有很多，但我希望本文的介紹能幫你在設計應用程序時思路清晰有方向。
