常見數據庫介紹和使用場景

在構建系統時要進行設計考慮和權衡。

1.介紹

要選擇正確的存儲解決方案，需要以下考慮。

關鍵因素

• 數據結構
• 查詢模式
• 您需要處理的數量或規模

2.緩存解決方案

• 如果您經常調用數據庫或遠程調用具有高延遲的獨立服務，則可能需要[緩存]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons / caching /）您本地的一些數據。
• 一些關鍵值緩存存儲解決方案是Memcached，Hazelcast，Redis等
• 大多數使用Redis，Memcache和Elasticache。

3.文件存儲解決方案

• 文件存儲用作圖像，視頻等的數據存儲。
• 數據庫旨在存儲可以查詢的信息，而您不需要查詢的文件，只需按原樣提供它們即可。這是當我們使用稱為Blob存儲的東西時。
• Amazon S3主要用於Blob存儲

4.CDN

• 通常，blob存儲與[內容交付網絡]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/content-distribution-network-cdn/）或[CDN]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/content-distribution-network-cdn/）。
• CDN是遍布全球的服務器網絡，可在不同地理位置提供內容並減少延遲。
• 如果您要從中獲取內容的服務器離您的地理位置更近，則將以更快的方式將內容傳遞給您。

5.文本搜索功能

5.1.文本搜索

• 假設您要構建搜索功能，用戶可以在其中按電影，流派，演員，女演員，導演等進行搜索。
• 在這里，您可以使用諸如Solr之類的搜索引擎
• 它建立在Apache Lucene之上

5.2.模糊搜索

• 如果您在搜索中搜索拼寫錯誤/不正確的單詞，並且搜索結果中包含正確的單詞結果，則稱為模糊搜索。
• 搜索引擎存儲臨時數據或索引數據，並且不保證長期數據，因此搜索存儲不用作主存儲。
• 例如，如果我們輸入“ intraviw”，它將根據“面試”進行搜索
• 我們可以從主數據庫中將數據加載到它們，以減少搜索延遲並提供基於模糊和相關性的文本搜索。
• 可以支持模糊搜索的Elasticsearch。
• 它也是基於Apache Lucene構建的

6.時間系列數據庫

• 假設我們正在嘗試建立度量跟蹤系統，或者在任何基於時間的數據庫中我們都需要一個時間序列數據庫。
• 與標准關系數據庫不同，時間序列數據庫永遠不會被隨機更新。
• 大部分會依序追加。
• 相對於隨機讀取，在特定時間范圍內會有更多的批量讀取。在過去1周，10天，1個月，1年等時間內，有多少人觀看了編解碼器視頻。
• 時間序列數據庫的一些示例是OpenTSDB，InfluxDB等。
• 我們還可以使用任何非關系時間序列數據庫。

7.分析和數據倉庫

• 我們需要一個大型數據庫來轉儲可供我們使用的所有數據，以執行分析。
• 主要用於離線報告，而非事務性
• 存儲所有數據，以便他們可以執行分析。
• HDFS通常用於存儲海量數據
• Hadoop和Spark是非常常用的數據倉庫和處理。

8.SQL與NoSQL

8.1.SQL

• 結構取決於我們用來確定將使用哪種類型的因素
• 如果您需要[ACID]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/acid-vs-base-property/）屬性，則需要使用關系DBMS。
• 一些示例是MySQL，Oracle，Postgres等
• 付款系統主要需要交易和原子性。
• [強一致性]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/database-consistency/）主要可以通過SQL數據庫來實現。

8.2.NoSQL

• 假設您正在嘗試為諸如Amazon之類的商品建立目錄，您想在其中存儲有關具有各種屬性的不同產品的信息。
• 例如，不同產品的這些屬性通常不同。葯品將有有效期，但冰箱將具有能量等級。
• 在這種情況下，我們的數據不能表示為表格。這意味着我們需要使用NoSQL數據庫。
• 如果您需要[BASE]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/acid-vs-base-property/）屬性，則可以使用非關系數據庫前進。
• 對於[最終一致性]（https://interviewdaemon.com/courses/design-concepts-a-to-z/lessons/database-consistency/），我們可以使用NoSQL數據庫
• 最常見的NoSQL DB是MongoDB，Cassandra，DynamoDB

8.2.1.基於文檔（基於查詢的數據）

• 如果我們擁有大量數據-不僅是數量，而且還有各種各樣的屬性-並且我們需要運行各種各樣的查詢，則需要使用一種稱為Document DB的東西。
• 使用文檔數據庫，隨機查詢或其他查詢最有效
• Couchbase或MongoDB是一些常用的文檔數據庫

8.2.2.圖形存儲

• 這些類型的數據庫使數據可視化更加容易。
• 它們非常善於在節點的幫助下存儲不同數據點之間的關系。
• 圖形存儲可能不是最可擴展的數據庫。
• 但是，它們在防止欺詐等使用案例方面效率很高。
• 圖形數據庫的常見示例是Neo4j 和 JanusGraph。

8.2.3.Key-value 存儲

• 這些都是非常簡單的數據庫管理系統，存儲關鍵值對。
• 最終目標是快速獲取基本數據。
• 這些類型的數據庫的常見用例是排行榜和購物車數據。
• redis是流行的key value 存儲。

8.2.4.柱狀數據庫（不斷增加的數據）

• 有限的查詢種類，但是數據庫的大小持續快速增加。例如訂單，目錄
• 現在，Uber司機的數量將逐日增加，即每天收集的數據也會逐日增加。這成為越來越多的數據。
• 在這種情況下，我們使用諸如Cassandra或HBase之類的列式數據庫。

9.不同數據庫的組合

示例：Amazon.com

• 對於一個我們只有一件庫存產品，但有多個用戶試圖購買它的產品，它應該只賣給一個用戶，這意味着我們在這里需要ACID。因此，一個明顯的選擇應該是像MySQL這樣的關系數據庫。
• 與亞馬遜產品相關的數據將會不斷增加，並且會有各種各樣的屬性。我們應該使用像Cassandra這樣的Columnar NoSQL數據庫。。
• 我們可以在MySQL數據庫中存儲尚未交付的訂單數據，一旦訂單完成，我們可以將其移到Cassandra永久存儲。。
• 用於報告系統有多少人購買了一個特定的項目。因此，報告不能針對單個產品，而應該針對產品的子集，這些產品可以在Cassandra或MySQL中。這樣的需求就是我們最好的選擇是像Mongo DB這樣的文檔DB的一個例子。
• 假設您想要查看上個月有多少人買了糖，您可以從Mongo DB獲取訂單id，並使用此訂單id從Cassandra或MySQL獲取其余數據。

資料來源：https://www.codekarle.com/system-design/Database-system-design.html
https://towardsdatascience.com/choosing-the-right-database-in-a-system-design-interview-b8af9c6dc525