需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 7

新评论
 
YuraZ:

想法很清楚...

而这种方法（通过快速搜索）在行业基础上却无法得到。

一定有原因的

因为数据库已经完美地应对了搜索的任务，无需将所有数据加载到RAM中。
 
Integer:

没有人在谈论在压缩数据中搜索的问题。我们谈论的是比较两个压缩序列的情况。

假设一个数组，"aaa"，"bbb"，"vvv"。三个阵列元素 中的每一个都是独立于其他元素而被压缩的。假设我们压缩并得到数组 "a"、"b"、"c"。

我们有一个寻求的字符串 "bbb"，我们需要在数组中找到它。在搜索之前，我们对其进行压缩，得到 "b"。现在我们搜索并找到它。

我们要清楚，在你的情况下，应该是3a、3b和3c的压缩形式，因为你省略了重复的次数。

如果你认为这样的算法会带来70-80%的压缩率，你就错了。即使在俄语文本上（更不用说数字），这种方法也只会使数据膨胀。

例如，单词 "Expert "将被重新编码为 "1E1k1с1п1е1р1t"，并且不会被压缩哪怕一个比特，但会被膨胀两次。如果你省略 "1"，仍然不会有压缩。

日期和时间2014.08.18 13:45:45不会给压缩你的方式。

更不用说引言了...所以在这种情况下，这种转码的效率接近于0。这就是PCX格式中使用的所谓的RLE算法。

 
elugovoy:

1.我们要清楚，在你的情况下，应该是3a、3b和3c的压缩形式，因为你省略了重复的次数。

如果你认为这样的算法会带来70-80%的压缩率，你就错了。即使在俄语文本上（更不用说数字），这种方法也只会使数据膨胀。

例如，单词 "Expert "将被重新编码为 "1E1k1с1п1е1р1t"，并且不会被压缩哪怕一个比特，但会被膨胀两次。如果你省略 "1"，仍然不会有压缩。

日期和时间2014.08.18 13:45:45不会给压缩你的方式。

更不用说引言了...所以在这种情况下，这种转码的效率接近于0。这就是PCX格式中使用的所谓的RLE算法。

1.不是一个事实。也许数据是这样的，所有的东西都要去三次，这就是为什么它是一个如此简单的压缩算法。

其余的...哦，谢谢你，你让我大开眼界，我不知道压缩短序列的数据会增加它们的大小。

 
Integer:
因为数据库已经在做很好的搜索工作了，不需要把所有的数据加载到RAM中。

事实上，一个好的和正确设置的SQL服务器（如果你的硬件有64g和128zu，例如）

扣除操作系统的需要，几乎占据了64克的全部空间......。128г

而搜索20G的数据（预先缓存的数据）--实际上是在内存中进行的...。

这就是为什么压缩它没有意义。

--

 
Integer:

你有点暗示了。

如何搜索，我之前 写过。

首先，"暗示 "和 "断言 "是不同的概念。

第二，我的话里根本没有一丝一毫，我再说一遍对于一个源文件，会有一棵树，而对于要找到的一部分数据，会有另一棵树

而使用或多或少严重的压缩算法（任何经典的，甚至是Huffman的），你将无法进行搜索。理论上也不行。

 
Integer:
因为数据库已经在做很好的搜索工作了，不需要把所有的数据加载到RAM中。
这就是为什么在SQL数据库中放置20G的意义所在。
 
elugovoy:

首先，"提示 "和 "论断 "是不同的概念。

第二，我的话里根本没有一丝一毫，我再说一遍源文件将有一棵树，但要找到的数据部分将有自己的树。

而使用一个或多或少严重的压缩算法（任何经典的，甚至是Huffman的），你将无法进行搜索。理论上也不行。

如果你在压缩相同的数据，为什么一部分数据会有不同的树形？如果数据不同，就让它有一个不同的树。重要的是当相同的数据被压缩时，要与之相匹配。
 
Integer:
如果同样的数据被压缩了，为什么会有一部分数据的不同树形？如果数据不同，那么就让它有一个不同的树。对我们来说，重要的是相同数据被压缩时的重合性。

迪米特里 - 如果有可能的话

很久以前，他们就已经创建了一个SQL工业数据库--在良好的（80%-90%）压缩数据中进行（快速）搜索。

也可以用插入更新删除

 
Integer:

1.这不是一个事实。也许数据是这样的，所有的东西都要走三次，因此要采用简单的压缩算法。

其余的...谢谢你让我大开眼界，我只是不知道压缩短序列的数据会增加它们的大小。

还有一个小论点，让我的眼睛睁开。任何编码都有一个目的。

有一种解压缩编码，目的是在只支持电传的通信渠道上传输二进制数据（例如通过电子邮件传输图片），通常使用基于Radix算法的Base64。

与数据校正相关的冗余编码，（如CD Aduio）其目的是尽可能地保护数据不受物理载体的损害。

压缩编码，目的 储存/归档 数据。

 
YuraZ:

德米特里 - 如果有可能的话

他们早就建立了一个工业化的SQL数据库--在良好的（80%-90%）压缩数据中进行（快速的）搜索......

要去参加第二轮比赛吗？从第5-6页开始重读。特别仔细地阅读该帖子。

不要把我的建议归咎于我。我建议比较相互独立压缩的浓缩序列。而不是一次次在单独压缩的巨大文件中寻找单独压缩的小文本。

1234567891011121314...21
新评论