处理大量文本字符串

发布于 2024-08-25 10:01:21 字数 641 浏览 4 评论 0原文

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

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

我应该在将文本存储到数据库之前压缩文本吗？或者让 SQL Server 担心压缩存储？
您知道在这种情况下使用哪种最佳压缩算法/库可以为我提供最佳性能吗？目前我只在 .NET 框架中使用标准 GZip
你知道处理这个问题的最佳实践吗？我欢迎开箱即用的建议，只要它可以在 .NET 框架中实现？（这是一个大项目，这个要求只是其中的一小部分）

编辑：我将继续添加此内容以澄清提出的观点，

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

毅然前行 2024-09-01 10:01:21

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

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

这不到 60 MB 的存储空间。坦率地说，在数据库领域，这只是微不足道的事情。 60 GB 存储空间是我所说的“中型”数据库。

此时，即使考虑压缩也是不成熟的优化。 SQL Server 可以毫不费力地处理如此大量的文本。除非您没有提到任何系统限制，否则我不会关心任何这些问题，除非您确实开始看到性能问题 - 即使这样，它也可能是其他原因造成的，例如糟糕的索引策略。

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

SQL Server 2008 可以执行页级压缩，这将是一种更有用的优化，但您使用的是 SQL Server 2005。所以不，绝对不要费心尝试压缩单个值或< em>行，这不值得付出努力，而且实际上可能会让事情变得更糟。

回复收藏 0 原文

も让我眼熟你 2024-09-01 10:01:21

如果您可以升级到 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 之类的内容进行压缩。不过我想你可以尝试一下。

If you can upgrade to SQL Server 2008, I would recommend just turning on page compression, as detailed here: http://msdn.microsoft.com/en-us/library/cc280449.aspx

As an example, you can create a compressed table like this:

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

If you can't use compression in the database, unfortunately your strings (no more than 300 chars) are not going to be worthwhile to compress using something like System.IO.Compression. I suppose you could try it, though.

回复收藏 0 原文

迷荒 2024-09-01 10:01:21

压缩会消耗资源，并且通常会损害性能，因为大量时间只是本地通信和处理。

回复收藏 0 原文

桃扇骨 2024-09-01 10:01:21

不完全清楚你在问什么。

关于性能 - 如果您在将字符串存储到数据库之前先压缩内存中的字符串，那么您的程序将会比直接将数据填充到表中并让 SQL 稍后处理的情况慢。代价是 SQL 数据库会更大，但 1Tb 硬盘很便宜，那么存储真的有那么重要吗？

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

这将是使用 EF 等生成 200K 插入语句的替代方案。

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

回复收藏 0 原文

眼泪淡了忧伤 2024-09-01 10:01:21

我不担心压缩它们。对于这种大小的字符串（300 个字符左右），它会让人头疼，而不是值得。压缩字符串需要时间（无论多短），并且 SQL Server 2005 没有执行此操作的本机方法，这意味着您必须编写一些东西来执行此操作。如果在应用程序中执行此操作会损害性能，则可以编写一个 CLR 例程在数据库中执行此操作，但在应用程序中实际使用压缩字符串（或任何其他使用它的人）。

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

回复收藏 0 原文