大型SQL Server数据库中的Blob数据
我们每年生成20.000.000个文本文件，每个文件的平均大小约为250 Kb (压缩后的大小为35 Kb )。
我们必须把这些文件归档10年。不需要在文本文件内部搜索，但我们必须能够通过搜索5-10个元数据字段找到一个文本文件，如"productname"，"creationdate“等。
我正在考虑压缩每个文件，并将它们存储在SQL Server数据库中，该数据库具有5-10个可搜索(索引)列和一个用于压缩文件数据的varbinary(MAX)列。
随着时间的推移，数据库将变得越来越大；5-10 Tb。因此，我认为我们需要对数据进行分区，例如，每年保留一个数据库。
我一直在研究在SQL Server中为保存数据的varbinary列使用FILESTREAM，但似乎这更适合大于1Mb的blobs？
关于如何管理这些数据量，有什么其他建议吗？
回答 3
Stack Overflow用户
发布于 2011-06-23 20:36:42
我想说的是，将文件保存在文件系统中会更好。你可以将文件名和路径保存在数据库中。这是a similar question。
Stack Overflow用户
发布于 2011-06-24 01:57:31
文件流肯定更适合较大的blob (750kB-1MB)，因为打开外部文件所需的开销开始影响读写性能，而不是小文件的blob存储。如果这不是一个大问题(即，在初始写入之后读取blob数据的频率很低，并且blob实际上是不可变的)，那么它肯定是一种选择。
我可能会建议直接将文件保存在vb(max)列中，如果您可以保证它们不会变得太大，但使用TEXTIMAGE_ON选项将此表存储在单独的文件组中，这将允许您在必要时将其移动到与其余元数据不同的存储中。此外，请确保设计您的模式，以便可以使用分区或通过某些多表方案将blobs的实际存储拆分到多个文件组中，以便将来在必要时可以扩展到不同的磁盘。
与处理文件系统/ SQL不一致相比，通过文件流或直接vb(max)存储将blobs直接与SQL元数据相关联具有许多优势，不仅限于备份和其他管理操作的简易性。
Stack Overflow用户
发布于 2011-06-23 20:48:40
我猜想你所谓的“生成”是指像数据一样的东西被注入到文档模板中，因此有很多重复的文本内容，即“样板”？
每年有2000万个这样的“生成”文件，相当于每天约55,000个，每小时约2300个！
我会在一开始就不生成文本文件，而是创建包含注入到生成的文本中的数据的数据库摘要，以便您可以在必要时重新构建完整的文档。
如果您所说的“生成”指的是其他东西，您能详细说明一下吗？
https://stackoverflow.com/questions/6453602
复制相似问题
腾讯云开发者
