我的应用程序每秒接收大约2000个字符串消息，每条消息长约300个字符。
我需要将所有消息存储在数据库中。我正在使用 SQL Express 2008 和。 NET 。
我正在考虑将所有数据保存在内存中，直到达到一定限度（例如10000条消息= 5秒），然后一次性将其全部写下来。
这样，数据将每5秒写入硬盘，而不是每秒。
我的方法是否足够好？我应该使用什么方法来获得以下结果？
注意：不需要解析字符串，唯一的方法是按照它们到达的顺序存储它们。
答案 0 :(得分：3)
如果您更全面地描述了在存储这些大量数据后您想要做些什么，那么就更明确地建议如何处理它。
从表面上看，这听起来像关系数据库要处理的数据太多了。如果你想要的只是存储，我宁愿设计一个基于纯文本文件的解决方案。如果您希望能够搜索文本文件，可以使用服务或控制台应用程序在后台慢慢索引它们。
索引可以使用Lucene.NET构建，并且您的索引可以保持在最低限度，因为我希望您不需要能够搜索存储在这些文本文件中的所有内容。
答案 1 :(得分：2)
快速计算表明您每天最多可能会遇到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等答案 2 :(得分：1)
在你的情况下，我不会这样做。 假设：
（2000 * 300）/ 1024（kb）/ 1024（mb）=每秒约0.54 MB。
一天有：60（秒）* 60（分钟）* 24（小时）= 86400秒。
0.54 * 86400 =每天43200 MB。
如果你使用UTF-8编码，那么大小会大两倍！ （varchar与nvarchar）
这意味着你每天会得到 40 GB 。即使您每隔5秒甚至10秒或20秒写入插入查询，您的快速服务器也无法生存。考虑索引重建以获得良好的查询性能，在特定时间段内备份数据库以及您必须携带的其他数据库内容。您的数据库不会处理请求。
我建议您将字符串存储在文本文件中（如果您的文本很少被最终用户阅读，否则我建议使用一些索引引擎（可能是Lucene））和在应用程序服务器中缓存。仅存储这些文件在数据库中的路径。
请注意。基于一些事实和经验，这只是我自己的解决方案。
修改
使用应用程序，您可以更好地控制数据。您可以通过HTTP将文件发送到其他服务器，您可以压缩文件等。