想象一下如果您正在接受系統(tǒng)設(shè)計(jì)面試，并且需要選擇一個(gè)數(shù)據(jù)庫(kù)來(lái)將與訂單相關(guān)的數(shù)據(jù)存儲(chǔ)在電子商務(wù)系統(tǒng)中。您的數(shù)據(jù)是結(jié)構(gòu)化的，需要保持一致，但是您的查詢模式與標(biāo)準(zhǔn)關(guān)系數(shù)據(jù)庫(kù)不匹配。您需要隔離事務(wù)，原子性和所有事物都是酸性的……但是，天哪，它需要像Cassandra一樣無(wú)限擴(kuò)展。那么您將如何決定選擇哪種存儲(chǔ)數(shù)據(jù)庫(kù)解決方案？

首先，我們正在處理哪種數(shù)據(jù)？它是記錄還是文件系統(tǒng)或音頻/視頻內(nèi)容？我們打算對(duì)該數(shù)據(jù)進(jìn)行什么樣的處理？我們是否需要搜索或運(yùn)行復(fù)雜的分析算法？

　　有哪些不同類型的存儲(chǔ)解決方案？

根據(jù)我們的要求以及我們要如何使用或訪問(wèn)我們的數(shù)據(jù)，我們可能正在尋找以下存儲(chǔ)解決方案：

· 緩存解決方案—如果我們正在設(shè)計(jì)諸如Twitter或Facebook這樣的讀取繁重的系統(tǒng)，我們可能最終會(huì)捕獲大量數(shù)據(jù)，甚至是完整的時(shí)間表，以滿足低延遲要求。這里的一些選項(xiàng)是Redis或Memcached。

· 文件系統(tǒng)存儲(chǔ)-如果我們正在設(shè)計(jì)某種資產(chǎn)交付服務(wù)，則可能需要在其中存儲(chǔ)圖像或音頻/視頻文件，則可能需要使用一種稱為Blob存儲(chǔ)的方法。一個(gè)非常受歡迎的示例是Amazon S3。

· 文本搜索引擎—如果我們正在設(shè)計(jì)像Amazon這樣的系統(tǒng)并且需要實(shí)現(xiàn)搜索功能，該怎么辦。關(guān)于搜索功能的問(wèn)題是，我們還需要考慮錯(cuò)別字。假設(shè)用戶要搜索“ 襯衫 ”，但鍵入“ shrt ”。現(xiàn)在，如果我們不顯示任何結(jié)果，那將是非常糟糕的用戶體驗(yàn)。我們的系統(tǒng)必須足夠聰明，才能顯示“ 襯衫 ”或“ 短褲 ”的結(jié)果。這被稱為模糊搜索，這是我們使用諸如Elasticsearch之類的文本搜索引擎的地方。

· 數(shù)據(jù)倉(cāng)庫(kù)-我知道!我們一直在討論數(shù)據(jù)和存儲(chǔ)，所以我們?cè)趺床豢紤]大數(shù)據(jù)!有時(shí)我們只需要將所有數(shù)據(jù)轉(zhuǎn)儲(chǔ)到一個(gè)存儲(chǔ)中，以后就可以執(zhí)行各種分析。這些系統(tǒng)更多地用于通常是交易的脫機(jī)報(bào)告。這是我們最終使用Hadoop等數(shù)據(jù)倉(cāng)庫(kù)解決方案的地方。

現(xiàn)在，您可能已經(jīng)注意到我們一直在談?wù)摗按鎯?chǔ)解決方案”而不是“數(shù)據(jù)庫(kù)”。現(xiàn)在讓我們看看數(shù)據(jù)庫(kù) 。

SQL？NoSQL？這里發(fā)生了什么？

好了，我們有幾個(gè)因素基礎(chǔ)可以決定要使用哪種數(shù)據(jù)庫(kù)，這些因素是數(shù)據(jù)的結(jié)構(gòu)，查詢模式和規(guī)模。

我知道有點(diǎn)困惑!這就是為什么我將鏈接添加到本文中提到的視頻中的原因。

他們已經(jīng)對(duì)它進(jìn)行了漂亮的解釋，但是我們還將在接下來(lái)的部分中對(duì)其進(jìn)行遍歷，因此請(qǐng)繼續(xù)閱讀。

現(xiàn)在，規(guī)模， 結(jié)構(gòu)和 查詢模式。對(duì)。如果信息是結(jié)構(gòu)化的并且可以表示為表，并且如果我們需要事務(wù)是原子的，一致的，隔離的和持久的(ACID)，則可以使用關(guān)系數(shù)據(jù)庫(kù)。最常用的是MySQL。

現(xiàn)在，如果不需要ACID屬性，那么您仍然可以使用關(guān)系數(shù)據(jù)庫(kù)，也可以使用NoSQL替代方法。但是，如果您的數(shù)據(jù)缺乏結(jié)構(gòu)，則無(wú)法將其表示為表，現(xiàn)在我們需要使用NoSQL DB，例如MongoDB，Cassandra，HBase，Couchbase等。這就是查詢模式成為決定因素的地方。

附注：Elasticsearch是文檔數(shù)據(jù)庫(kù)的一種特例。

如果我們?cè)跀?shù)據(jù)中具有各種各樣的屬性和各種各樣的查詢，則可以使用 諸如MongoDB或Couchbase之類的Document DB。但是，如果我們必須進(jìn)行大規(guī)模的工作，但需要運(yùn)行的查詢類型很少，那么我們就選擇 像Cassandra或HBase這樣的列型數(shù)據(jù)庫(kù)。您可能已經(jīng)知道，甚至在列式數(shù)據(jù)庫(kù)之間，HBase還是基于Hadoop構(gòu)建的。

因此，在設(shè)置HBase時(shí)，我們首先需要設(shè)置Hadoop及其相關(guān)組件，然后在其之上設(shè)置HBase。這在設(shè)置系統(tǒng)時(shí)增加了一定程度的復(fù)雜性，因此，如果只是為了簡(jiǎn)單起見(jiàn)，我個(gè)人會(huì)選擇Cassandra。在性能方面，兩者都給出相似的結(jié)果。

現(xiàn)在，像Cassandra這樣的Columnar數(shù)據(jù)庫(kù)的事情是，它們主要通過(guò)分區(qū)和復(fù)制數(shù)據(jù)來(lái)工作。因此，如果您可以選擇分區(qū)鍵，以便所有查詢都使用where子句中的公共分區(qū)鍵，那么Cassandra就是您的最佳選擇。

我碰到了這篇有關(guān)如何通過(guò)“ codekarle” 選擇最佳存儲(chǔ)解決方案的文章，它以Uber如何與他們的駕駛員和騎車人進(jìn)行交互的示例很好地解釋了使用列式數(shù)據(jù)庫(kù)還是文檔數(shù)據(jù)庫(kù)的合理性。系統(tǒng)。讓我嘗試使用相同的場(chǎng)景對(duì)此進(jìn)行解釋。

假設(shè)Uber將與乘車相關(guān)的信息保存在Cassandra中，駕駛員ID為分區(qū)鍵。現(xiàn)在，當(dāng)我們運(yùn)行查詢以每天獲取特定驅(qū)動(dòng)程序的所有數(shù)據(jù)時(shí)，它會(huì)基于分區(qū)鍵驅(qū)動(dòng)程序ID來(lái)獲取數(shù)據(jù)。這是Cassandra解決方案的分區(qū)方面。現(xiàn)在，如果我們嘗試通過(guò)客戶ID查詢特定日期的客戶游樂(lè)設(shè)施，該怎么辦？現(xiàn)在，查詢將發(fā)送到所有分區(qū)，效率得到提高。這是解決方案的復(fù)制端出現(xiàn)的地方。

我們可以簡(jiǎn)單地復(fù)制整個(gè)數(shù)據(jù)，現(xiàn)在使用客戶ID作為分區(qū)鍵。現(xiàn)在，當(dāng)基于客戶ID的查詢進(jìn)入時(shí)，它將使用客戶ID作為分區(qū)鍵定向到實(shí)例。這就是為什么Cassandra可以無(wú)限擴(kuò)展的原因。還記得Cassandra的查詢模式嗎？我們提到只有在查詢種類有限的情況下它才有用。那是因?yàn)槲覀冎荒軐?shù)據(jù)復(fù)制很多次。

　　讓我們開(kāi)始吧，一個(gè)數(shù)據(jù)庫(kù)夠了嗎？

現(xiàn)在，我們已經(jīng)看到了各種存儲(chǔ)解決方案，以及如何根據(jù)我們的需求和需要存儲(chǔ)的信息類型在各種數(shù)據(jù)庫(kù)之間進(jìn)行選擇。

例如，對(duì)于Amazon，訂單數(shù)據(jù)需要遵循ACID屬性，但它需要像Columnar DB一樣可無(wú)限擴(kuò)展。在這種情況下，我們將使用MySQL + Cassandra等數(shù)據(jù)庫(kù)的組合。現(xiàn)在，所有需要遵循ACID屬性的有關(guān)正在進(jìn)行中的訂單的信息都將存儲(chǔ)在MySQL數(shù)據(jù)庫(kù)中，一旦完成，我們就可以將它們移至Cassandra，用作永久存儲(chǔ)。因此，只要我們需要ACID屬性，數(shù)據(jù)就會(huì)保留在關(guān)系數(shù)據(jù)庫(kù)中，然后被移到可以根據(jù)數(shù)據(jù)大小進(jìn)行縮放的柱狀數(shù)據(jù)庫(kù)中。現(xiàn)在這個(gè)問(wèn)題就解決了。

上述就是關(guān)于如何選擇適合您需求的數(shù)據(jù)庫(kù)全部?jī)?nèi)容介紹，想了解更多關(guān)于數(shù)據(jù)庫(kù)的信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。