本文轉(zhuǎn)載自公眾號“讀芯術”(ID：AI_Discovery)

從事新項目總是令人極度興奮——可以自由地以自己喜歡的方式設計和構建項目。但如果規(guī)劃得不合理，就會給未來帶來麻煩。需要作出的最關鍵的決定之一就是選擇APP數(shù)據(jù)庫，而此文的目的就是介紹數(shù)據(jù)庫的選擇方案——并列舉其優(yōu)勢和弊端以幫你明智地選擇數(shù)據(jù)庫。

[[390048]]

鍵值

數(shù)據(jù)庫的結構像JSON對象，每個鍵都是唯一的，每個鍵都指向某個值。

 

 

它把數(shù)據(jù)保存在內(nèi)存中，運行速度快，但有容量限制，所以難以存儲大量數(shù)據(jù)。由于沒用到硬盤，因而運行非常的快。因為不涉及查詢或連接，因此不需要擔心數(shù)據(jù)建模。由于沒有模式，開發(fā)人員總是可以靈活地根據(jù)自己的喜好更改數(shù)據(jù)。

 

 

使用條件：

• 這種技術主要用作緩存機制，頻繁獲取和觀察數(shù)據(jù)的某些部分時使用。
• 因此，鍵值技術作為緩存機制，普遍與其他數(shù)據(jù)庫結合使用。

 

 

寬立柱

寬立柱像注射了類固醇的鍵值。值被修改為存儲一組列，而不僅僅是普通數(shù)據(jù)。

 

 

引入一組列之后，現(xiàn)在可以給相關數(shù)據(jù)分組，但仍沒有標準的模式。因此，每個鍵可以指向不同分組的數(shù)據(jù)。

由于沒有模式，它可以處理非結構化數(shù)據(jù)，并附帶一種名為CQL的查詢語言，類似于SQL，但功能要弱得多。數(shù)據(jù)以連續(xù)的流形式出現(xiàn)，比如來自物聯(lián)網(wǎng)設備、股票市場、金融交易或Netflix觀看歷史。

 

 

使用條件：

• 寫頻
• 不經(jīng)常更新或讀取

它仍然不是通用的。因此，它可以用于存儲來自所有不同應用程序的歷史數(shù)據(jù)。

文檔型數(shù)據(jù)庫

它是我們使用的最流行的數(shù)據(jù)庫技術之一。很明顯，它包括文檔，每個文檔是一組鍵值對。它們是非結構化的、不需要模式。

 

 

文檔被分組到集合中，這些集合可以被構造成邏輯層次結構。邏輯數(shù)據(jù)集合以更有邏輯性的方式分組相關數(shù)據(jù)，它似乎與關系數(shù)據(jù)庫相似。

 

 

數(shù)據(jù)庫不能運行join查詢，怎么立刻獲得所有相關的數(shù)據(jù)呢?把它們?nèi)績Υ?。鼓勵非?guī)范化數(shù)據(jù)庫，已經(jīng)做好會出現(xiàn)數(shù)據(jù)復制/不一致的準備。

讀取數(shù)據(jù)非?？?，但編寫和更新數(shù)據(jù)的同時要保證一致性卻是一項挑戰(zhàn)。文檔數(shù)據(jù)庫非常適合通用應用程序，也可能非常適合大多數(shù)應用程序、游戲和物聯(lián)網(wǎng)。

若對數(shù)據(jù)庫模式不甚了解，則記錄數(shù)據(jù)庫是最佳啟動方式。

流行文檔型數(shù)據(jù)庫

 

 

數(shù)據(jù)量很多，而且數(shù)據(jù)之間有著直接或間接的關系時，文檔型數(shù)據(jù)庫無法容納。在這種情況下，必須運行多個復雜的查詢，然后在前端應用程序中合并所有接收到的數(shù)據(jù)，或者可以使用關系數(shù)據(jù)庫，其中這些復雜的查詢由數(shù)據(jù)庫管理。

關系數(shù)據(jù)庫

這類數(shù)據(jù)庫中，著名的一些包括MySQL, Postgres, and SQL Server。他們出現(xiàn)很長時間了，對于很對應用程序來說都是不錯的選擇。

想象一個汽車工廠，它有不同的輪轂來生產(chǎn)汽車部件。假設門是在一個地方制造的，而輪子、車身和內(nèi)部零件都是在各自不同的地方制造的。

 

 

假設的車廠藍圖

每個制造的部件都有一個唯一的ID。所以一旦汽車組裝完畢，就可以從不同的地方取來所有的零件，然后組裝汽車。

 

 

建造這樣一個工廠需要制定藍圖，以確保整個生產(chǎn)過程非常高效和優(yōu)化。這個藍圖在使用在數(shù)據(jù)庫中時稱為模式。因此，需要為數(shù)據(jù)庫規(guī)劃模式，以確保數(shù)據(jù)庫也有效性高，能滿足應用程序的數(shù)據(jù)需求。

缺點：

• 久而久之，改變車廠的布局就像改變要求一樣，會浪費汽車公司的時間和金錢。大型應用程序也面臨相似的情況。確保在要求清晰的情況下使用關系數(shù)據(jù)庫。
• 而且，一旦建立一個每月能制造30輛車的工廠，那么就很難把產(chǎn)量提升到90。同理，關系數(shù)據(jù)庫很難擴大規(guī)模，但也有例外，如Cockroach DB 和 PostgreSQL，在設計時添加了擴大規(guī)模的功能。

優(yōu)點：

• SQL數(shù)據(jù)庫符合ACID標準，這意味著即使讀寫操作之間可能會失敗，數(shù)據(jù)有效性和完整性也不會受到損害-這使其非常適合與銀行/金融相關的數(shù)據(jù)。
• 一旦有了合適的模式，就可以確保存儲的數(shù)據(jù)將始終存儲在一組驗證之后的固定結構中，這些驗證先模式中得以定義。

哪個最適合你?

• 若要求清晰，不需要大幅改變要求，選擇這個。
• 若對需求不是很確定，并且處于某種試驗階段，那么最好使用NoSQL數(shù)據(jù)庫。

要是不需要建立模式，直接把關系存成數(shù)據(jù)，該用哪個呢?

圖表數(shù)據(jù)庫

數(shù)據(jù)存儲在節(jié)點中，關系被定義為邊。一起來看看怎么做。

要想在SQL數(shù)據(jù)庫里查找所有學習計算機科學的學生，則需要一個查找/中間人表，該表單獨存儲所有學習計算機科學的學生的記錄。

 

 

圖表更加簡單明了，因為不必分別存儲數(shù)據(jù)中的關系部分，而自動帶有新式數(shù)據(jù)。

 

 

關系更易于記錄和保持在圖表里

有了這個直接顯示兩個節(jié)點間的關系的新方式，復雜的聯(lián)接查詢變得更簡單，與SQL相比，極大地提高了數(shù)據(jù)的性能。因此，因依賴大量聯(lián)接操作而降低數(shù)據(jù)的性能時，可以使用這種數(shù)據(jù)庫。

可搜索數(shù)據(jù)庫

如果你正在構建一個像谷歌這樣的應用程序，在小字符串查詢搜索中，你必須快速返回所有匹配的記錄，那么這就是一個全文搜索引擎。這些數(shù)據(jù)庫基于始于1999年的Apache Lucene項目。

Algolia和MeiliSearch是全文搜索引擎。它們看起來類似于文檔類型的數(shù)據(jù)庫。有一個索引，并向它添加數(shù)據(jù)對象。搜索數(shù)據(jù)庫引擎將分析文檔中的所有文本，并創(chuàng)建稱為倒排索引的東西。

當你查詢某項內(nèi)容時，數(shù)據(jù)庫只會檢查反向索引，這使得整個過程看起來異常迅速，即使對于大型數(shù)據(jù)庫也是如此。

多模式數(shù)據(jù)庫

可供選擇的數(shù)據(jù)庫有很多，但最流行的似乎是Fauna。作為應用開發(fā)者，我們通常只關心JSON，我們可以在應用前端使用它。有了Fauna，不必擔心數(shù)據(jù)建模、模式、縮放、復制或規(guī)范化過程，只需獲取JSON數(shù)據(jù)即可。使用GraphQL定義訪問數(shù)據(jù)的方式。

以一個類似instagram的應用程序的場景為例。將使用JSON為用戶、發(fā)布和查詢定義規(guī)則。

 

 

我們剛剛上傳了GraphQL模式，它會自動創(chuàng)建一個集合來存儲數(shù)據(jù)和查詢數(shù)據(jù)的索引。在幕后，它將考慮如何利用基于您提供的GraphQL模式的不同范例，如關系、圖表和文檔。只是簡單地以與在文檔數(shù)據(jù)庫中相同的方式添加數(shù)據(jù)，而且不會受到數(shù)據(jù)建模的限制。

優(yōu)點：

• 它符合ACID標準、運行速度極快。
• 不必擔心基礎設施。只需定義對數(shù)據(jù)的需求，云端會解決其余的問題。

缺點：

• 價格明顯是個缺點。好的東西不是免費的，但是對于想要學習的開發(fā)人員以及小型創(chuàng)業(yè)公司，它們確實提供了慷慨的計劃/開源選項。

 

 

以下是Fauna列出的值得注意的重要特點：

 

 

這些并不是全部!要學習的不同的數(shù)據(jù)庫還有很多，但我希望本文的介紹能幫你在設計應用程序時思路清晰有方向。