在構建系統時要進行設計考慮和權衡，
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/286039.html
標籤：大數據