致力于新項(xiàng)目總是超級(jí)令人興奮 - 我們有自由設(shè)計(jì)和建立任何我們想要的東西的東西。但是，這個(gè)規(guī)劃，當(dāng)沒(méi)有正確完成時(shí)，將來(lái)會(huì)導(dǎo)致我們很多痛苦。

選擇您的應(yīng)用程序數(shù)據(jù)庫(kù)是您必須制作的重要決策之一，并且隨著本文，我打算向您介紹各種數(shù)據(jù)庫(kù)選項(xiàng) - 以及列出一些優(yōu)點(diǎn)和缺點(diǎn)，以幫助您制作更明智的數(shù)據(jù)庫(kù)決策。

內(nèi)存數(shù)據(jù)庫(kù) Redis

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

它保留了內(nèi)存中的數(shù)據(jù)，這非常快，但具有容量限制，因此您無(wú)法存儲(chǔ)大量數(shù)據(jù)。并且由于沒(méi)有涉及的磁盤(pán)，一切都快速燃燒。

無(wú)需查詢或聯(lián)接，因此無(wú)需擔(dān)心太多數(shù)據(jù)建模。由于沒(méi)有架構(gòu)，因此開(kāi)發(fā)人員始終可以根據(jù)自己的需要靈活地更改數(shù)據(jù)。

何時(shí)使用這種技術(shù)

• 該技術(shù)主要用作緩存機(jī)制，用于某些時(shí)候非常頻繁地獲取和觀察部分?jǐn)?shù)據(jù)
• 因此，關(guān)鍵值技術(shù)與其他數(shù)據(jù)庫(kù)一起廣泛使用作為緩存機(jī)制

寬列數(shù)據(jù)庫(kù) Cassandra

這就像鑰匙值，但在類固醇上。修改該值以存儲(chǔ)一組列，而不是簡(jiǎn)單數(shù)據(jù)。

通過(guò)引入列，您現(xiàn)在可以對(duì)相關(guān)數(shù)據(jù)進(jìn)行分組，但是仍然沒(méi)有標(biāo)準(zhǔn)架構(gòu)。因此，每個(gè)鍵都可以指向不同的分組數(shù)據(jù)。

由于沒(méi)有模式，它可以處理非結(jié)構(gòu)化數(shù)據(jù)，并附上一個(gè)名為CQL的查詢語(yǔ)言，這類似于SQL，但方法不那么強(qiáng)大。

數(shù)據(jù)源源不斷，例如來(lái)自IoT設(shè)備，股票市場(chǎng)，金融交易或Netflix的觀看歷史記錄。

何時(shí)使用此技術(shù)

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

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

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

這是我們使用的最受歡迎的數(shù)據(jù)庫(kù)技巧之一。這顯然由文檔組成，每個(gè)文檔都是一組鍵值對(duì)。它們是非結(jié)構(gòu)化，不需要模式。

文檔將組合成集合，并且這些集合可以構(gòu)造成邏輯層次結(jié)構(gòu)。

這種邏輯集合允許您以更邏輯的方式對(duì)相關(guān)數(shù)據(jù)進(jìn)行分組，這似乎類似于關(guān)系數(shù)據(jù)庫(kù)。

由于我們的數(shù)據(jù)庫(kù)無(wú)法運(yùn)行聯(lián)接查詢，我們?cè)撊绾瘟⒓传@取所有相關(guān)數(shù)據(jù)?

我們將它全部存儲(chǔ)在一起!我們鼓勵(lì)數(shù)據(jù)庫(kù)的非規(guī)范化，數(shù)據(jù)復(fù)制/不一致是一種折衷，我們已準(zhǔn)備好。

讀取速度確實(shí)很快，但是在確保數(shù)據(jù)一致性的同時(shí)寫(xiě)入和更新數(shù)據(jù)可能會(huì)有些困難。

文檔數(shù)據(jù)庫(kù)非常適合通用應(yīng)用程序，并且可能適合大多數(shù)應(yīng)用程序，游戲和IoT。

如果您真的不確定數(shù)據(jù)庫(kù)架構(gòu)，那么文檔數(shù)據(jù)庫(kù)是最佳啟動(dòng)方式。

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

當(dāng)您有大量數(shù)據(jù)時(shí)，文檔風(fēng)格的數(shù)據(jù)庫(kù)就不夠用了，它們可能直接或間接地相互關(guān)聯(lián)。

對(duì)于這些情況，您將必須運(yùn)行多個(gè)復(fù)雜查詢，然后在前端應(yīng)用程序中合并所有接收到的數(shù)據(jù)，或者可以使用關(guān)系數(shù)據(jù)庫(kù)，其中這些復(fù)雜查詢由數(shù)據(jù)庫(kù)管理。

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

我們都聽(tīng)說(shuō)過(guò)這些數(shù)據(jù)庫(kù)，最受歡迎的是MySQL，Postgres和SQL Server。他們?cè)谶@里一直在這里，仍然是許多應(yīng)用程序的熱門(mén)選擇。

我們使用結(jié)構(gòu)化查詢語(yǔ)言(SQL)。

“關(guān)系”的意義

想象一下一家汽車(chē)工廠，那里有制造汽車(chē)零件的不同輪轂。

假設(shè)門(mén)是在一個(gè)地方制造的，而輪子，車(chē)身和內(nèi)飾都是在各自不同的位置制造的。

> Imaginary car-factory blueprint

每個(gè)制造的零件都有一個(gè)唯一的ID分配給它。

因此，一旦必須組裝汽車(chē)，您就可以從所有這些不同的位置提取所有零件并組裝汽車(chē)。

對(duì)于這樣一個(gè)工廠建立建立，我們會(huì)為這樣的工廠創(chuàng)建藍(lán)圖，這使得制造汽車(chē)的整體過(guò)程非常有效和最佳。當(dāng)它在數(shù)據(jù)庫(kù)中使用時(shí)，此藍(lán)圖稱為模式。

因此，我們需要規(guī)劃數(shù)據(jù)庫(kù)的模式，以確保我們的數(shù)據(jù)庫(kù)對(duì)應(yīng)用程序的數(shù)據(jù)需求非常有效。

不足之處

• 就像如何隨著時(shí)間的推移，改變汽車(chē)工廠的布局與改變要求一致，將花費(fèi)汽車(chē)公司一大堆時(shí)間和金錢(qián)，這是一個(gè)類似的情況，當(dāng)大規(guī)模的應(yīng)用程序必須這樣做時(shí)。當(dāng)您的要求清晰時(shí)，請(qǐng)務(wù)必使用關(guān)系數(shù)據(jù)庫(kù)。
• 此外，一旦您每月建造一個(gè)具有制造30輛汽車(chē)的工廠，您就無(wú)法輕易擴(kuò)展您的工廠，每月制造90輛汽車(chē)。同樣，我們的關(guān)系數(shù)據(jù)庫(kù)可能更加努力，但蟑螂DB和PostgreSQL有一些例外，旨在以比例為準(zhǔn)。

好的方面

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

最適合您的是什么?

• 如果您的要求很明確，并且確定您不需要對(duì)要求進(jìn)行任何大的更改，請(qǐng)繼續(xù)執(zhí)行此操作
• 如果您不太確定需求并處于實(shí)驗(yàn)階段，最好使用NoSQL數(shù)據(jù)庫(kù)

但是，如果我們不需要?jiǎng)?chuàng)建架構(gòu)并可以將關(guān)系直接存儲(chǔ)為數(shù)據(jù)怎么辦?

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

這里我們的數(shù)據(jù)存儲(chǔ)在節(jié)點(diǎn)中，并且關(guān)系定義為邊。非常漂亮!讓我們看看如何。

如果您必須在SQL數(shù)據(jù)庫(kù)中找出所有學(xué)習(xí)計(jì)算機(jī)科學(xué)的學(xué)生，您需要一個(gè)查找/中間商表，該表將所有學(xué)生的記錄分開(kāi)地存儲(chǔ)了學(xué)習(xí)計(jì)算機(jī)科學(xué)的所有學(xué)生。

在圖形中，這將更加簡(jiǎn)單明了，因?yàn)槲覀儾槐胤謩e存儲(chǔ)數(shù)據(jù)中的關(guān)系部分，而它本能地是這種新樣式。

> Relationships are easier to record and maintain in graphs

通過(guò)這種直接顯示兩個(gè)節(jié)點(diǎn)之間關(guān)系的新方法，我們復(fù)雜的聯(lián)接查詢變得更加簡(jiǎn)單，與SQL相比，極大地提高了數(shù)據(jù)庫(kù)的性能。

因此，當(dāng)您依賴于大量加入操作時(shí)使用此類數(shù)據(jù)庫(kù)，并且由于該依賴于性能劣化。

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

如果您要構(gòu)建Google之類的應(yīng)用程序，那么在小字符串查詢搜索中，您必須快速返回所有匹配的記錄-您所說(shuō)的是全文搜索引擎。

這些數(shù)據(jù)庫(kù)基于1999年開(kāi)始的Apache Lucene項(xiàng)目。

Algolia和Meilisearch是全文搜索引擎。

它們看起來(lái)類似于文檔類型的數(shù)據(jù)庫(kù)。我們有一個(gè)索引，并向其中添加了數(shù)據(jù)對(duì)象。搜索數(shù)據(jù)庫(kù)引擎將分析文檔中的所有文本，并創(chuàng)建稱為反向索引的內(nèi)容。

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

我把最激動(dòng)人心的一個(gè)保存下來(lái)。

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

那里有多種選擇，但最受歡迎的選擇似乎是動(dòng)物區(qū)系。

作為應(yīng)用程序開(kāi)發(fā)，我們通常只關(guān)心JSON，我們可以在我們的應(yīng)用程序的前端中消耗。

通過(guò)Fauna，我們不必?fù)?dān)心數(shù)據(jù)建模，架構(gòu)，縮放，復(fù)制或歸一化，并且只需獲取我們的JSON數(shù)據(jù)。我們定義了如何使用GraphQL訪問(wèn)我們的數(shù)據(jù)。

讓我們拍攝類似instagram的應(yīng)用程序的示例。我們將使用JSON定義我們的規(guī)則，用于用戶，帖子和查詢。

我們剛上傳了我們的GraphQL架構(gòu) - 它會(huì)自動(dòng)創(chuàng)建一個(gè)存儲(chǔ)數(shù)據(jù)和索引來(lái)查詢數(shù)據(jù)的集合。

在幕后，它是如何利用基于您提供的GraphQL模式的關(guān)系，圖形和文檔等不同的范例。

我們只是以與文檔數(shù)據(jù)庫(kù)中的相同方式添加我們的數(shù)據(jù)，并且我們并不遇到數(shù)據(jù)建模的局限性。

最好的部分 - 這是符合酸性的，非常快。

您無(wú)需擔(dān)心基礎(chǔ)架構(gòu)。只需定義您如何需要數(shù)據(jù)，云將為您處理其余的工作。

缺點(diǎn)

顯然，定價(jià)是不利的。偉大的事物不是免費(fèi)的，但是對(duì)于想要學(xué)習(xí)的開(kāi)發(fā)人員以及小型創(chuàng)業(yè)公司，它們確實(shí)提供了慷慨的計(jì)劃/開(kāi)源選項(xiàng)。

以下是Fauna列出的一些重要功能：

我們還沒(méi)有完成!有很多東西可以學(xué)習(xí)不同的數(shù)據(jù)庫(kù)，但是我希望這是對(duì)我們開(kāi)發(fā)人員可以在我們的應(yīng)用程序中使用的各種選項(xiàng)的很好的介紹。