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

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

　　有哪些不同類型的存儲解決方案？

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

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

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

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

· 數(shù)據(jù)倉庫-我知道!我們一直在討論數(shù)據(jù)和存儲，所以我們怎么不考慮大數(shù)據(jù)!有時我們只需要將所有數(shù)據(jù)轉儲到一個存儲中，以后就可以執(zhí)行各種分析。這些系統(tǒng)更多地用于通常是交易的脫機報告。這是我們最終使用Hadoop等數(shù)據(jù)倉庫解決方案的地方。

現(xiàn)在，您可能已經(jīng)注意到我們一直在談論“存儲解決方案”而不是“數(shù)據(jù)庫”。現(xiàn)在讓我們看看數(shù)據(jù)庫 。

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

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

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

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

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

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

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

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

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

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

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

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

我們可以簡單地復制整個數(shù)據(jù)，現(xiàn)在使用客戶ID作為分區(qū)鍵。現(xiàn)在，當基于客戶ID的查詢進入時，它將使用客戶ID作為分區(qū)鍵定向到實例。這就是為什么Cassandra可以無限擴展的原因。還記得Cassandra的查詢模式嗎？我們提到只有在查詢種類有限的情況下它才有用。那是因為我們只能將數(shù)據(jù)復制很多次。

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

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

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

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