我的應用程序每秒接收大約2000條字符串消息，每條消息約300個字符長。在SQL Server中存儲大量字符串消息的最有效方法？
我需要將所有消息存儲在數據庫中。我正在使用SQL Express 2008和。 NET。
我在想內存中的所有數據，直到它達到一定的限制（例如10000條消息= 5秒），然後一次寫下來。
這樣數據將每5秒寫入硬盤，而不是每秒。
我的方法是否足夠好？我應該使用什麼方法來獲得以下結果？
注：沒有必要解析字符串，唯一的事情是將它們存儲他們到達的順序。
快速計算表明您每天可能會遇到高達50 GB的數據。如果沒有對這些數據進行SQL特定的處理，那麼將其存儲在數據庫中似乎不可行。
下一個解決方案將是磁盤上的文件，並且由於您處理簡單文本（而非二進制文件），因此也許快速壓縮也會有所幫助。然而，由於文件會很小（300字節），壓縮不會產生任何明顯的結果。數據需要分組到更大的文件中，例如每行一個數據和每天一個這樣的文件。這個文件將會足夠大，這樣如果磁盤空間成爲問題，壓縮會得到滿意的結果。
如果空間不是一個問題，和/或該數據的頻繁處理，甚至來自不同天的數據同時處理是可以預期的那麼一塊每個文件的數據將是一個更好的選擇。該解決方案，進而將帶來具有非常大的號碼的文件夾，這將不僅撞到文件系統的限制，但也創造了性能問題與這些文件時，裏面的文件的問題，而這些問題將影響整個機器的性能。
以更好的方式存儲和訪問大量文件是使用分區文件夾存儲。那就是每個文件都必須有一個唯一的名稱，然後根據其名稱將其放置在特定的文件夾層次結構中。這種方法有以下幾個優點：
樣品分區：
yyyymmddhhss-<counter>.txt（如：201104252345-1.txt，201104252345-2.txt等）\yyyy\mm\dd\或yyyy\mm\dd\hh\等（如多層次的解決方案將需要保留的文件管理的數量）201104252345-1.txt存儲爲2011\04\25\201104252345-1.txt等如果您更詳細地描述了在存儲這些海量數據後想要處理的內容，可以更輕鬆地就如何處理這些數據提出明確的建議。
表面看來，它聽起來像是關係數據庫處理的數據太多。如果你想要的只是存儲，我寧願設計一個基於純文本文件的解決方案。如果您希望能夠搜索文本文件，則可以在後臺使用服務或控制檯應用程序爲其緩慢編制索引。
該索引可以用Lucene.NET構建，您可以將索引保持在最小值，因爲我希望您不需要能夠絕對搜索這些文本文件中存儲的所有內容。
我不會那樣做你的情況。 假設：
（2000 * 300）/ 1024（kb）/ 1024（mb）=大約0.54MB每秒。一天有60（秒）* 60（最小）* 24（小時）= 86400秒。
0.54 * 86400 = 43200MB每天。
如果您使用UTF-8編碼，尺寸將會增大兩倍！ （VARCHAR與nvarchar的）
這意味着你會得到每天約格羅斯40 GB。即使你每5秒甚至10或20秒寫插入查詢，你的快遞服務器也不會存活。考慮索引重建以實現良好的查詢性能，在特定的時間段內備份數據庫以及您必須攜帶的其他數據庫內容。你的數據庫不會處理請求。
我會建議你將字符串存儲在文本文件中（如果你的文本將通過最終用戶很少看，否則我建議使用一些索引引擎（Lucene的可能））和緩存他們的應用程序服務器。將這些文件的唯一路徑存儲在數據庫中。
注意。這只是我自己的解決方案，基於一些事實和經驗。
編輯
使用的應用程序，你會得到你的數據更多的控制。您可以通過HTTP發送文件到其他服務器，您可以壓縮文件等。
這聽起來像一個大量的數據。快速計算告訴我，您需要每天存儲大約50 GB的數據，我認爲將其存儲在數據庫中並不可行。這些數據是無限期存儲還是被處理並逐漸刪除？ – CyberDude
我們不要忘記每個數據庫的（IIRC）10GB的Express限制。您將在大約5個小時內達到此限制。 – SWeko
@CyberDude：感謝您的快速回復。我更喜歡儘可能地存儲。但由於數據量很大，一旦達到存儲限制，我將刪除一些舊數據，以便爲新數據騰出空間。 – MichaelS