使用NIO，我需要關心塊邊界上的R/W嗎？

Question

背景

很多工作已經進入優化數據庫的設計，特別是在最優化的方式來讀寫磁盤從數據（包括主軸和SSD）領域。

來自工作的知識表明，讀取和寫入塊邊界，匹配正在運行的文件系統的塊大小，是最理想的方法。

問題

說我是在一個相對較低的存儲環境中操作，並希望使用小32MB內存映射文件讀取和寫入一個巨大的500GB文件的內容。

如果我使用Java的NIO機制，特別是MappedByteBuffer（Java的內存映射文件機制），在配對數據之前，我需要注意在塊邊界（例如4KB）上執行READ和WRITE操作我需要，或者我可以在任何我想要的位置發佈R/W操作，並允許操作系統，VM分頁邏輯，文件系統和存儲固件處理操作的優化以及額外的塊數據的剔除，需要？

額外的細節

的原因的問題是在數據庫設計中，我看到這個強迫重點區塊優化到如此地步，似乎沒有存在的世界裏，你將永遠只是讀取和寫入數據而沒有塊的概念。

讓我感到困惑的是，文件系統是強制執行塊單位操作的文件系統，爲什麼我的高級應用程序需要擔心這個問題呢？如果我想要偏移71處的17,631個字節，我不能只抓住它們並讀入它們，或者確定 的讀取操作開始於塊0並且落在塊0， 1和2 ...將所有這3個塊讀入內部字節[]，然後剔除我想要的17,631個字節？

如果關於數據庫設計的文獻對這個塊想法沒有那麼虔誠，那麼這個問題就不會出現在我的腦海裏，但是因爲它，我在想，如果我在這裏丟失了關鍵細節WRT文件系統和優化塊設備I/O。

謝謝您的閱讀。

Answer 1

我認爲數據庫意識到塊大小（可能與fs塊大小不一樣，但當然應該對齊）的部分原因不僅僅是執行塊對齊的I/O，而是還管理如何將磁盤數據緩存到內存中，而不僅僅依賴於操作系統緩存。事實上，一些數據庫完全繞過操作系統文件系統緩存。讓數據庫管理緩存有時可以提供更多的有關如何使用緩存的信息，操作系統可能無法提供。

爲了比較不同的執行計劃，rdbms通常會考慮在查詢過程中可以讀取/寫入的塊的數量：以及從同一塊中獲取所有數據的可能性可能是有用的優化要注意。

我所熟悉的大多數數據庫都有塊緩存/緩衝區的概念，其中數據庫的某些部分工作集存在。管理完全由任意盤區組成的緩存可能會比較難以管理。另外許多數據庫實際上將它們存儲的數據作爲一系列塊排列，所以I/O模式增長得更快。當然，這可能只是最初爲那些沒有豐富操作系統緩存設施的平臺編寫的數據庫的遺留物...

試圖用你的問題回答一些問題......我的感覺會從映射文件中的任意盤區讀取數據，並讓操作系統處理額外的數據溢出應該沒問題。在性能方面，嘗試讓操作系統進行預讀可能更重要：例如，使用「advise」調用，以便操作系統可以在處理當前的磁盤時從磁盤讀取下一個盤區。當然，還有一種方法可以建議操作系統解鎖已完成的擴展盤區。

Answer 2

4KB塊很重要，因爲它通常是MMU的粒度，因此也是OS虛擬內存管理器。當項目經常一起使用時，設計數據庫佈局非常重要，以便這些項目最終位於同一頁面中。這樣，頁面錯誤將頁面中的所有項目頁面。