我们每年生成20.000.000个文本文件，平均大小约为250 Kb（35 Kb压缩）。
我们必须将这些文件存放在某种存档中10年。无需在文本文件内搜索，但我们必须能够通过搜索5-10个元数据字段（例如“productname”，“creationdate”等）来找到一个texfile。
我正在考虑压缩每个文件并将它们存储在SQL Server数据库中，其中包含5-10个可搜索（索引）列和一个用于压缩文件数据的varbinary（MAX）列。
多年来，数据库将变得越来越大; 5-10 Tb。所以我认为我们需要对数据进行分区，例如每年保留一个数据库。
我一直在研究在SQL Server中使用FILESTREAM来获取保存数据的varbinary列，但它似乎更适合blob＆gt; 1 Mb？
有关如何管理此类数据卷的任何其他建议？
答案 0 :(得分：1)
我会说保存文件系统中的文件会更好。您可以在数据库中保留文件名和路径。这是a similar question。
答案 1 :(得分：1)
Filestream绝对更适合更大的blob（750kB-1MB），因为打开外部文件所需的开销会影响读取和写入性能与小文件的vb（max）blob存储。如果这不是一个问题（即在初始写入后很少读取blob数据，并且blob实际上是不可变的）那么它肯定是一个选项。
如果你可以保证它们不会变得更大，我建议你直接将这些文件保存在vb（max）列中，但是使用TEXTIMAGE_ON选项将这个表存储在一个单独的文件组中，这样你就可以如有必要，将其移动到与其余元数据不同的存储空间。此外，请确保设计您的架构，以便可以使用分区或通过多个表格方案将blob的实际存储分割为多个文件组，以便将来可以根据需要扩展到不同的磁盘。
通过文件流或直接vb（max）存储保持blob与SQL元数据直接关联，与处理文件系统/ SQL不一致性相比，具有许多优势，不仅限于备份和其他管理操作的简易性。
答案 2 :(得分：0)
我假设“生成”你的意思是数据被注入到文档模板中，所以文本内容重复很多，即“样板”？
每年有2000万这样的“生成”文件每天约55,000个，每小时约2300个！
我会通过不首先生成文本文件来管理这样的卷，而是创建数据库摘要，其中包含泵入生成的文本的数据，以便您可以重新构建完整的文本必要时提供文件。
如果你的意思是“生成”，那么你能详细说明吗？