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

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

[[390048]]

鍵值

數(shù)據(jù)庫(kù)的結(jié)構(gòu)像JSON對(duì)象，每個(gè)鍵都是唯一的，每個(gè)鍵都指向某個(gè)值。

它把數(shù)據(jù)保存在內(nèi)存中，運(yùn)行速度快，但有容量限制，所以難以存儲(chǔ)大量數(shù)據(jù)。由于沒(méi)用到硬盤(pán)，因而運(yùn)行非常的快。因?yàn)椴簧婕安樵兓蜻B接，因此不需要擔(dān)心數(shù)據(jù)建模。由于沒(méi)有模式，開(kāi)發(fā)人員總是可以靈活地根據(jù)自己的喜好更改數(shù)據(jù)。

使用條件：

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

寬立柱

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

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

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

使用條件：

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

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

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

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

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

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

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

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

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

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

關(guān)系數(shù)據(jù)庫(kù)

這類(lèi)數(shù)據(jù)庫(kù)中，著名的一些包括MySQL, Postgres, and SQL Server。他們出現(xiàn)很長(zhǎng)時(shí)間了，對(duì)于很對(duì)應(yīng)用程序來(lái)說(shuō)都是不錯(cuò)的選擇。

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

假設(shè)的車(chē)廠藍(lán)圖

每個(gè)制造的部件都有一個(gè)唯一的ID。所以一旦汽車(chē)組裝完畢，就可以從不同的地方取來(lái)所有的零件，然后組裝汽車(chē)。

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

缺點(diǎn)：

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

優(yōu)點(diǎn)：

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

哪個(gè)最適合你?

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

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

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

數(shù)據(jù)存儲(chǔ)在節(jié)點(diǎn)中，關(guān)系被定義為邊。一起來(lái)看看怎么做。

要想在SQL數(shù)據(jù)庫(kù)里查找所有學(xué)習(xí)計(jì)算機(jī)科學(xué)的學(xué)生，則需要一個(gè)查找/中間人表，該表單獨(dú)存儲(chǔ)所有學(xué)習(xí)計(jì)算機(jī)科學(xué)的學(xué)生的記錄。

圖表更加簡(jiǎn)單明了，因?yàn)椴槐胤謩e存儲(chǔ)數(shù)據(jù)中的關(guān)系部分，而自動(dòng)帶有新式數(shù)據(jù)。

關(guān)系更易于記錄和保持在圖表里

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

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

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

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

當(dāng)你查詢某項(xiàng)內(nèi)容時(shí)，數(shù)據(jù)庫(kù)只會(huì)檢查反向索引，這使得整個(gè)過(guò)程看起來(lái)異常迅速，即使對(duì)于大型數(shù)據(jù)庫(kù)也是如此。

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

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

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

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

優(yōu)點(diǎn)：

• 它符合ACID標(biāo)準(zhǔn)、運(yùn)行速度極快。
• 不必?fù)?dān)心基礎(chǔ)設(shè)施。只需定義對(duì)數(shù)據(jù)的需求，云端會(huì)解決其余的問(wèn)題。

缺點(diǎn)：

• 價(jià)格明顯是個(gè)缺點(diǎn)。好的東西不是免費(fèi)的，但是對(duì)于想要學(xué)習(xí)的開(kāi)發(fā)人員以及小型創(chuàng)業(yè)公司，它們確實(shí)提供了慷慨的計(jì)劃/開(kāi)源選項(xiàng)。

以下是Fauna列出的值得注意的重要特點(diǎn)：

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