什麼是從數據庫生成500,000個靜態html文件的最快方法（算法）？快速生成500,000個html文件的算法
而且它是一個很好的做法，把所有這些文件中的一個文件夾？或爲這些文件分層創建？
我們要處理大約600萬個併發命中，所以靜態文件將是一個很好的解決方案。 源數據庫將是沒有連接的簡單平坦表。
我們想從單個表中生成這個文件包含500k條記錄。 文件名將是該表的第一個字段。該HTML文件將包含 以顯示約900字節的數據。
有一個文件限制（ATLEAST在Linux中，around 32k items），所以沒有我不認爲這是明智的做。
NTFS擁有4,294,967,295 files in a folder.
的限制，即使你的文件系統在同一個目錄可以「應付」 50萬頁的文件，這是不太可能能夠表現良好。即使可以表現良好，人類可能很難管理這些文件。
我肯定會把它們放在一個層次結構中。
至於生成它們最快的方式 - 你要求的算法，但沒有說明你要它做什麼。您可能想要使用的技術有多種 - 無論您最喜歡哪種技術都可能是最好的選擇 - 以及任何接近任務的方法，具體取決於它的實際組成。
分層次將性能最好，因爲許多應用程序將循環，雖然都在一個目錄中的文件。例如，Windows資源管理器。這會使應用程序變慢。
提取它們將使用數據庫的標題和fwrite（）等寫一個小的C程序，最快的方式...
F.Y.I.
NTFS可容納4,294,967,295文件：http://en.wikipedia.org/wiki/NTFS EXT3可容納VolumeByteSize/2^13個文件：http://en.wikipedia.org/wiki/Ext3#cite_note-0
爲什麼不直接存儲在數據庫中生成的HTML？看起來好像你將有效地將文件系統視爲一個數據庫 - 至少如果你將HTML存儲在數據庫中，你可以依靠DBMS來優化查找性能（例如通過緩存最近查詢的HTML），並且你可以添加索引並分析查詢性能。否則，你只需要敲擊文件系統;即在其他地方移動問題。
另外，我建議退後一步，看到瓶頸在哪裏目前所在。存儲HTML（表示層數據）並不是一個優雅的解決方案 - 如果真正的問題是由於查詢性能造成的，那麼可以考慮在包含中間結果的模式中引入非規範化表格，從中可以快速生成HTML。
如果我這樣做，我會根據文件名（IFF的文件名分佈充分）將生成的文件存儲在層次結構中，因此「onefile.html」存儲在「o/n /e/onefile.html「和」anotherfile.html「作爲」a/n/o/anotherfile.html「。使用三個級別的存儲空間不是必需的，您可能需要四個。此外，根據每個字符分塊路徑名稱可能不是最好的分佈，根據分佈的外觀，最好使用兩個或三個字符。
過去我使用類似的存儲方案接收傳真用於電子傳真服務（使用目的地傳真號碼的更長和更長的前綴作爲路徑名組件）。
我想你正在尋找生成平面文件的原因是爲了攤銷生成HTML的成本？
他們每個500.000條目大小約1k？所以我們正在談論500兆字節的數據。如果可能的話，我會簡單地把整個東西放在一個虛擬硬盤上，如果你需要文件系統的功能，把它作爲一個有序的結構（hastable，某種數組）存儲在內存中。是否有特定的原因，爲什麼不將結果存儲在臨時數據庫表中？ （SQLite）
好的，如果我們使用NTFS呢？ – Ammroff 2009-06-30 21:56:56
那不是「linux」，那是EXT3。 Linux支持其他沒有限制的文件系統（例如XFS）。 – andri 2009-06-30 22:01:42
我的意思是在Windows 2003或2008下使用NTFS。 – Ammroff 2009-06-30 22:04:05