我們公司有五個億的用戶，我們存儲用戶的代碼文件，用戶可以編輯和添加自己的文件，就像網絡IDE，網絡IDE列表中的用戶的文件。我們使用PHP函數來實現這些操作，如READDIR，和的file_get_contents file_put_contents，我們使用了MooseFS，但是當我們在程序中讀取文件，特別是緩慢的加載速度。速度快的分佈式文件系統對於小文件
所以我們需要替換文件系統，希望有人能給我一些建議，我們有大量的小文件，這些文件系統應該使用分佈式文件系統。
五個百萬條目是小到關係數據庫。我不知道爲什麼你覺得需要將它們存儲在文件系統中。
是否每個用戶需要的所有文件將在啓動時加載？如果是的話，我想知道系統的設計。無論您如何設計，該操作都是O(N)。
如果您將這500萬個小文件放入關係數據庫或NoSQL數據庫中，然後讓每個用戶連接並查詢他們想要的特定數據，那麼您就不必在啓動時反覆加載它們。問題解決了。
在任何分佈式文件系統，當我們考慮對小文件操作的最關鍵的一個方面就是網絡延遲 - 它應該這樣的分佈式文件系統組件之間（如0.1毫秒）儘可能小。實現它的最好方法是使用可靠的開關，並將所有機器連接到同一個開關。另外，在分佈式文件系統中（尤其是在MooseFS中）最好的是可擴展性 - 這意味着，你擁有的節點越多（並且計算的分佈越多，即在多個安裝平臺上同時完成），集羣越快。
如果使用MooseFS，請查看MooseFS 3.0，因爲在小文件操作，因爲3.0版本的改進。目前這是一個簡單的方法，因爲您不必進行「革命」（升級前請記住備份主服務器上的/ var/lib/mfs - 即元數據）。 MooseFS可以很好地處理小文件，所以配置中可能會出現問題？另外在MooseFS（仍然考慮小文件操作）中，最重要的事情之一是在主服務器的BIOS中具有較少CPU核心的高CPU時鐘（例如3.7 GHz）和禁用節能選項因爲主服務器是單線程進程）。對於大塊服務器和客戶端來說，情況是不同的 - 它們是多線程的，所以在使用多核CPU時可以獲得更好的結果。
此外，在第4款 「虛擬機和MooseFS」 在MooseFS Best practices說：
[...]我們不建議在虛擬機上運行MooseFS成分（特別是主服務器（S）） 。
所以，如果你在虛擬機上運行MFS，你實際上可能會有很差的結果。