我有一千五百萬個簡單的鍵/值記錄。密鑰大小都是單個單詞，它們包含的值的大小範圍從幾個字節到每個10MB。使用文件系統作爲15M文件的數據庫 - 效率如何？
隨機密鑰將需要經常訪問。
我在想，將這些文件作爲文件存儲在目錄而不是數據庫中會更有效率。所以我不需要擁有所有這些條目的大量表，而是需要一個文件名作爲鍵和文件內的值的目錄。
這意味着如果我想要鍵值azpdk我只需要file_get_contents('/my/directory/azpdk')在PHP中，而不是麻煩MySQL與這樣的請求。
在我的腦海中，這是有道理的，我期望它能更有效地使用文件系統而不是數據庫。我在這個假設中糾正了嗎？這仍然是快速和有效的，在一個目錄中有1500萬個文件嗎？
僅供參考文件系統是xfs。
有你可能想看看一個數據庫（不一定MySQL的）有幾個原因，而不是這樣的事情的文件系統：在一個目錄下放慢改革的步伐
更多文件
雖然XFS在分配資源方面應該非常聰明，但大多數文件系統在單個目錄中擁有的文件越多，性能就會越差。在命令行上處理它們也是一件令人頭痛的事情。看看這個（http://oss.sgi.com/projects/xfs/datasheet.pdf），有一張關於查找的圖表，每個目錄只有50k，並且正在下降。
架空
沒有每個文件的文件系統額外開銷的某一量。如果你有很多小文件，你可能會發現最終的商店因此而膨脹。
重點清潔
全都是你的話安全地放在一個文件名？你確定？那裏有一兩刀，真的會毀了你的一天。
的NoSQL可能是一個不錯的選擇
喜歡的東西的MongoDB/Redis的可能是一個很好的選擇。 MongoDB可以存儲多達16MB的單個文檔，並且使用將文件放在文件系統上並不困難。如果你存儲了15MB的文件，那麼你可能會因爲這個限制而過於接近舒適度，但還有其他的選擇。
關於這一點的好處是，查找性能可能會非常好，如果你以後發現它不是你可以通過創建一個集羣來擴展性能等任何這樣的系統也將做好管理智能磁盤上的文件以獲得良好性能的好工作。
如果你要使用的磁盤
考慮採取要存儲單詞的MD5哈希值，並在此基礎上的文件名。例如azpdk的MD5是：
1c58fb66d5a4d6a1ebe5ec9e217fbbf9
你可以使用它來創建一個文件名如：
my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9
這有幾個不錯的功能：
希望有所幫助。
我曾在一個基因組學研究中心工作，其中bioinfomraticins不是特別有經驗的程序員。
與其使用數據庫，它們中的少數幾個會生成數百萬個小文件，直到文件系統停止運行。
謝謝，我結束了使用前兩個字符作爲目錄，因爲所有的鍵都是a-z最少3個字符。由於xfs無論如何都使用btree索引......而且這幾乎就是數據庫本身。 – Alasdair