Question

我的项目在运行时，会在很短的时间内收集大量的字符串文本块（大约20K，最大的我看到的大约是200K）并将它们存储在关系数据库中。每个字符串文本相对较小，平均值约为15个短行（约300个字符）。目前的实现是在C＃（VS2008），.NET 3.5和后端DBMS是SQL Server 2005女士

性能和存储都是项目的重要关注点，但优先级将是性能优先，然后是存储。我正在寻找这些答案：

我应该在将文本存储到数据库之前压缩文本吗？或者让SQL Server担心压缩存储？
你知道什么是最好的压缩算法/库用于这个上下文，给我最好的性能？目前我只使用.NET框架中的标准GZip
你知道处理这个问题的最佳做法吗？只要它可以在.NET框架中实现，我欢迎在框外提出建议吗？（这是一个很大的项目，这个要求只是其中的一小部分）

编辑：我会继续加上这一点来澄清提出的观点

我不需要文本索引或搜索这些文本。我只需要能够在以后的阶段检索它们，以便使用其主键显示为文本块。
我有一个如上所述实现的工作解决方案，SQL Server完全没有问题处理它。该程序将经常运行并需要处理大型数据上下文，因此您可以想象大小将会非常快速地增长，因此我可以做的每项优化都会有所帮助。

Answer 1

如果您可以升级到SQL Server 2008，我建议您打开页面压缩，详见此处：http://msdn.microsoft.com/en-us/library/cc280449.aspx

例如，您可以创建如下压缩表：

CREATE TABLE T1 
(c1 int, c2 nvarchar(50) )
WITH (DATA_COMPRESSION = PAGE);

如果你不能在数据库中使用压缩，遗憾的是你的字符串（不超过300个字符）不值得用System.IO.Compression之类的东西进行压缩。我想你可以尝试一下。

Answer 2

字符串平均每个300个字符。这可能是300或600字节，具体取决于Unicode设置。假设您使用varchar(4000)列并使用（平均）每个300字节。

然后，您最多可以将200,000个这些存储在数据库中。

这不到60 MB的存储空间。在数据库的土地上，坦率地说，就是花生。 60 GB 的存储空间就是我所说的“中等”数据库。

此时，即使思考关于压缩也是过早的优化。 SQL Server可以轻松处理这一数量的文本。除非你没有提到任何系统限制，否则我不会关注任何这些，除非你真的开始看到性能问题 - 即使这样，它也可能是其他东西的结果，比如糟糕的索引策略。

压缩某些类型的数据，尤其是小数据量（以及300字节肯定很小），实际上有时会产生更糟糕的结果。您最终可能会得到实际上比原始数据大的“压缩”数据。我猜大多数时候，压缩的大小可能非常接近原始大小。

SQL Server 2008可以执行页面级压缩，这将是一个更有用的优化，但是你在SQL Server 2005上。所以不，绝对不要试图压缩单个值或行，它不值得付出努力，实际上可能会让事情变得更糟。

Answer 3

不完全清楚你在问什么。

关于性能 - 如果你在将数据库存储到数据库之前压缩内存中的字符串，那么程序将比将数据直接填充到表中并让SQL稍后担心它的速度慢。权衡的是，sql数据库会更大，但是1Tb的硬盘很便宜，那么存储真的很重要吗？

根据您的数字（200K乘300字节），您只需要大约60Megs。那不是一个非常大的数据集。您是否考虑过在ADO.NET中使用批量复制功能（http://msdn.microsoft.com/en-us/library/7ek5da1a.aspx）。如果您的所有数据都放在一个表中，这应该很有趣。

这可以替代像EF一样生成基本上200K的插入语句。

UPDATE 这是另一个例子：http://weblogs.sqlteam.com/mladenp/archive/2006/08/26/11368.aspx

Answer 4

压缩将消耗资源，并且通常会损害性能，而重要的时间只是本地通信和处理。

Answer 5

听起来好像使用Large-Value Data Types

会受益匪浅

这些数据类型最多可存储2 ^ 31-1个字节的数据

如果你的所有字符串都很小，那么压缩它们的回报就会减少。如果没有自然的SQL压缩，如果你压缩它们，它们将无法搜索。

Answer 6

我不担心压缩它们。对于这样大小的字符串（大约300个字符），它将比它的价值更令人头疼。压缩字符串需要花费时间（无论多小），并且SQL Server 2005没有本地方式来执行此操作，这意味着您将不得不编写一些内容来执行此操作。如果你在应用程序中这样做会损害你的性能，你可以编写一个CLR例程来在数据库中执行它，但它仍然是在你的应用程序中实际使用压缩字符串的额外步骤（或任何其他用它来解决这个问题）。

数据库中的空间很便宜，因此压缩所有字符串并不能节省太多。您最大的问题是在应用程序的内存中保留大量字符串。如果你经常回到数据库加载其中的一些而不是试图同时缓存所有这些，我不会担心它，除非你实际上看到问题。

Answer 7

听起来您正在尝试使用关系数据库来解决明确的非关系问题。你为什么要使用数据库？它当然可以完成，但有些问题并不合适。 TFS表明，一旦你在它上面放了足够的硬件就可以强行解决使用RDBS的问题，但这并不是一个好主意。

处理大量文本字符串

7 个答案: