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

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

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

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

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

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

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

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

現在，您可能已經注意到我們一直在談論“存儲解決方案”而不是“數據庫”。現在讓我們看看數據庫 。

SQL？NoSQL？這里發生了什么？

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

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

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

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

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

附注：Elasticsearch是文檔數據庫的一種特例。

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

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

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

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

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

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

　　讓我們開始吧，一個數據庫夠了嗎？

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

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

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