存儲大量內容的建議方法是什麼？

我打算啓動一個基於文章的網站，用戶將在其中輸入文章並上傳圖片。存儲大量內容的建議方法是什麼？

現在我有點困惑，以什麼方式保存數據。無論是在數據庫中，還是使用文件系統作爲.txt文件或.html文件或以任何其他方式使用。將數據保存在數據庫中對我來說有點尷尬，因爲最初我打算在共享服務器上運行該站點。那麼共享服務器容量是否足以滿足龐大的內容呢？還是建議將內容保存爲單獨的.txt文件或.html文件？

注意事項：

搜索功能，只對文章標題中使用。文章標題將被保存在數據庫中。搜索功能不會擴展到文章的內容。
我已經計劃使用所見即所得的編輯器，並允許貢獻者格式化他們的內容。顯然，存儲的數據將包含HTML代碼。因此，將內容存儲在文件系統中是安全的，因爲它對數據庫的XSS攻擊是真實的？
圖像將存儲在文件系統中，而不是存儲在數據庫中。

a。在做這件事情時要集中什麼來防止XSS攻擊？

b。如果在數據庫中存儲是建議的解決方案，那麼應該是什麼數據類型？ TEXT還是LONGTEXT？

來源

2013-10-02 Viswalinga Surya S

MySQL中的「LONGTEXT」字段類型可以存儲高達4GB的字符。我懷疑你會有一篇文章，這是巨大的;） –

@Glavić：不是這樣:)但它變得必須重新考慮。因爲用戶也可能寫一篇冗長的文章。 –

@Surya - 如果你真的相信你的用戶會在__single article__中寫入4GB以上的字符，我會重新思考 - 4GB相當於大約3500個典型小說 –

這是兩種最常見的解決方案，我能想到的：

商店都在數據庫中。
在數據庫和文件系統數據庫外的所有附件（二進制文件，如JPEG和PDF）中存儲「小」數據。

這兩種解決方案都有優點和缺點。

解決方案＃1：輕鬆保存在數據庫中

優點：

某些（強大）數據庫，你甚至可以指數（SEACH）的常用文件格式，如PDF格式的內容（Oracle interMedia是一個例子）。
您可以輕鬆確保數據的完整性。
您可以輕鬆確保數據安全。

缺點：

使數據庫龐大，可以是痛苦的緩慢，如果你不會做你的數據庫/表的維護。
難以「瀏覽」二進制內容以進行調試。
如果您的項目有一個龐大的數據庫，並且有許多用戶正在讀/寫數據庫，您尤其需要運行數據庫/表維護。
數據庫備份可能難以執行和恢復。
在Web應用程序上提供文件可能有些棘手（需要知道正確提供文件的MIME類型）。

解決方案2 - 存儲在文件系統中

優勢，在數據庫中的「小」的數據和數據庫以外的所有附件：

文件

HTTP緩存是比較容易做。
更容易瀏覽文件（用於調試或任何其他）。
更容易維護快速的系統，沒有做任何特別的事情。

缺點：

需要創建和維護一個關係表誰就會在數據庫中的文件鏈接，在文件系統中的實體。
數據完整性無法真正做到（如果文件在文件系統上手動刪除但仍存在於數據庫中會發生什麼？）。
安全必須在許多層面上得到保證。

這是我能想到的一個快速概覽。兩種解決方案都可以很好，這取決於有多少用戶會使用您的項目以及您可以使用哪些硬件。

對於共享環境，我可能會去＃2，因爲共享環境通常不是很強大。

來源

2013-10-02 16:04:19 AlexV

謝謝Alex。我會選擇第二種解決方案。你能參考一些教程來了解安全措施嗎？ –

@Surya S我不知道任何具體的教程，但只是確保存儲在文件系統上的文件至少受到訪問限制（如果它們必須是）。將它們放在一個非公開的目錄中，並使用PHP提供它們（請記住這樣做時緩存）。 – AlexV

謝謝Alex。 –

我目前面臨同樣的問題。我有數百萬個配置文件，每個配置文件本身都包含大量數據不建議在關係數據庫中存儲大量數據，因爲它會降低網站性能。我推薦這個解決方案。

將數據存儲在數據庫中，這是搜索所必需的，並且是網站最初需要的。如ArticleTitle，標籤。
使用NoSQL數據庫（CouchDB），其中包含有關文章的所有信息。在將文檔保存在CouchDB中時，請將文章ID作爲文檔的名稱，以便您可以輕鬆地將文章ID映射到文檔文檔。

來源

2013-10-02 15:49:09

甚至Casandra（nosql）對於龐大的數據存儲和高擴展性都非常好 – sravis

是的，Facebook也在使用它。 –

存儲大量內容的建議方法是什麼？

回答

相關問題