我不從Google File Systems Paper爲什麼小文件會在Google文件系統中創建熱點？
一個小文件由少數塊，也許只是一個明白這一點。如果許多客戶端 正在訪問相同的文件，則存儲這些塊的大塊服務器可能會成爲熱點。
小文件有什麼區別？許多客戶訪問的大文件是否可能導致問題？
我想過/閱讀以下內容： -
一些後續文本可以幫助澄清：
然而，熱點做開發時，政府飛行服務隊首次使用 通過批處理隊列系統：一個可執行文件被寫入GFS 作爲一個單一的然後在數百臺機器 上同時啓動。存儲這個 可執行文件的少數大塊服務器被數百個併發請求超載。 我們通過存儲具有較高複製因子的此類可執行文件 以及通過使批處理隊列 系統錯開應用程序啓動時間來解決此問題。長期的解決方案是允許客戶在這種情況下從其他 客戶讀取數據。
如果1000個客戶端要同時讀取一個小文件，則擁有其唯一塊的N個塊服務器將同時接收1000個/ N個請求。這突如其來的負載是熱點意味着什麼。
大文件不會被給定客戶端一次全部讀取（畢竟它們很大）。相反，他們將加載文件的某些部分，對其進行處理，然後轉到下一部分。
在分片（MapReduce，Hadoop）方案中，工作人員可能根本就不會讀取相同的塊; N中的一個客戶端將讀取文件的1/N塊，與其他客戶端不同。
即使在非分片場景下，實際上客戶端也不會完全同步。他們可能最終都會讀取整個文件，但隨機訪問模式，以便統計上沒有熱點。或者，如果他們確實按順序讀取它們，由於工作負載的差異，它們會不同步（除非您有意地同步客戶機......但不這樣做）。
即使有很多客戶端，由於大型文件帶來的工作性質，大型文件的熱點也會減少。這不是保證，這是我認爲你在你的問題中說，但實際上分佈式客戶端不會在多塊文件的每個塊上串聯工作。
說大量的客戶訪問同一臺服務器上的不同文件，它會成爲一個熱點嗎？ （我基本上想知道訪問硬盤的相同區域是否會導致問題，還是由於負載增加） –
它從來沒有正式定義過，但術語熱點通常用於指任何導致高的單個對象加載。所以「這個文件/大塊/香蕉/鞋子是一個熱點」只是意味着「這件事導致了比平常更高的負荷」。因此，具有恰好位於同一塊服務器上的塊的不同文件不僅會被視爲熱點 - 這只是系統上的常規加載。 – GManNickG
熱點問題並不一定是一回事，也許機器的網絡接口過載，也許機器上的帶寬跟不上請求等等。記住，這個塊服務器正在所有想要它的塊的客戶機之間共享，所以熱點可能只是「這個塊遠離其他塊訪問需要太多的「
「在這種情況下，1000個客戶端訪問每個塊服務器的1/100的文件，因此每個塊服務器不可避免地最終獲得1000個請求。」你能更多地在這裏擴展你的想法嗎？如果客戶端訪問文件的1/100，則每個客戶端只會聯繫百分之一的大塊服務器。這篇論文的想法是，對於大文件，訪問模式實際上是跨塊服務器的隨機分佈*，但不是一次全部*。 – GManNickG
@GManNickG一個大文件存儲在100個塊服務器中。 1000個客戶端需要該特定文件。他們最終都將需要來自100個大塊服務器的數據。所以每個chunkserver都會最終爲1000個客戶提供服務。即使有一個隨機分佈，每個文件所做的單個請求都不會等於一個小文件產生的負載嗎？ 更重要的是大文件的部分存儲在不同的塊服務器？ –
Gotcha。在你的場景中，所有的塊服務器最終都會服務1000次，是的，但是瞬時負載會更低。 1000個客戶端同時向單個服務器請求數據是一個熱點，如果客戶端不僅僅是同時連接每個數據塊服務器，而是超過100個數據塊服務器的1000個客戶端意味着您的任何服務器上的即時負載更低。然而，我相信這篇論文的重點是，在實際應用中，並不是所有的客戶端都會讀完整個文件，在這種情況下，chunkserver只處理（例如）一個請求。 – GManNickG