文件系統尋求與很多小文件的性能

Question

我正在尋找建立一個服務器與大量的XML API提供的小文件。它不會對目錄或順序文件塊進行大量迭代 - 我們正在談論很多和尋找不連續數據的問題。

在BSD上尋找時間UFS會隨着時間的推移而降低個別文件的請求嗎？我知道文件系統的inode限制是基於分區/分區的大小，但是硬盤驅動器必須在每次文件請求之前遍歷inode表，才能發現數據的位置。什麼文件系統可以獲得最佳搜尋性能？

另一種方法是設置2-4GB的「blob」文件，並有一個單獨的系統從軟件中查找其中包含的文件。該軟件的「inode表」可以根據當前登錄的用戶等進行優化以供交付......這些「inode表」可能會被緩存在RAM中，並且只會涉及當前登錄的用戶，從而減少浪費的資源。

從可擴展性和維護的角度來看，這兩種解決方案在哪裏進行評估？通過使用第二種解決方案，我可以期待什麼樣的性能提升（如果有的話）？

Answer 1

最明顯且經過時間驗證的緩解技術是對目錄（和路徑名搜索策略）使用良好的分層設計，並且每個目錄中包含的文件較少。

Answer 2

我不知道我是否正確理解你的問題，但是如果你想查找大量文件，爲什麼不使用在RAID0或VFS文件系統上佈置的分區mysql表？

編輯：據我所知，一個文件夾中的大量文件將降低FS的速度，因爲它必須維護更大的文件列表，權限和名稱，數據庫旨在將數據列表保存在內存中並通過它尋求一種非常優化的方式。

Answer 3

您的情況的更多細節將有所幫助，文件是否存在或將由您的應用程序創建？如果您需要一種方法來存儲任意數據，而無需使用關係數據庫的結構，您可以看看object databases

Answer 4

如果您的對象應該或可以通過HTTP訪問，另一個選擇是在緩存前使用一個varnish緩存小型Web服務器。最初對象將存儲在磁盤上，但清漆會在第一次訪問給定對象後從內存中存儲和提供對象。

Answer 5

對於最近的FreeBSD版本和dirhash和softupdates我沒有看到每個目錄有幾萬個文件沒有問題。你可能不想在500.000左右的檔案北邊。例如。用2.500.000個文件刪除一個目錄花了我三天。