标签: data-compression

我想知道我们可以在多大程度上进行无损数据压缩；我无法找到无损算法的在线模拟器来执行一些经验测试。我可以自己做一个，但不幸的是我这段时间没有足够的时间；我仍然对我的直觉很好奇，我将对此进行解释。

让我们仅采用两种更流行的算法：Huffman Coding和Run-lenght Enconding。

假设我们有一个数字A符号的字母表和来自该字母表的任意长的符号序列：例如：

Alphabet  = {A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, X, W, Y, Z}
Sequence1 =  SFBJNERUSNJGSDKKDEIJGNMSDJDDSUSJNF
Sequence2 =  MNMNMNREGUHSDFJUF
Sequence3 =  MMMMMNNNNNASDUERJGASIUJMMMNNNUNS

现在，如果我们只用一个固定长度的n比特字对每个符号进行编码，我们就会得到未压缩的序列，即长N比特。

如果我们使用 Huffman 编码一个序列，我们将使用H位而不是N位，从而节省(1-H/N)*100%位空间。

如果我们使用 RLE 编码相同的序列，我们将使用R位，节省(1-R/N)*100%.

我想知道，如果我们申请RLE + Huffman或者Huffman + RLE我们可以比仅使用其中之一节省更多空间会发生什么。

对我来说，这似乎是一个非常基本的想法，但是在谷歌上搜索我没有找到关于这个主题的任何有趣的东西。

编辑： …

假设我有以字节存储的任何数据.例如:

0110001100010101100101110101101

如何将其存储为可打印文本？显而易见的方法是将每个0转换为字符"0",将每个1转换为字符"1".事实上,这正是我目前正在做的事情.我想知道如何在不丢失信息的情况下更紧密地打包它们.

我想过将8位组中的位转换为ASCII,但是该格式不接受某些位组合.还有其他想法吗？

我在其中创建了一个用于文档存储的键空间和表.我用的代码是

CREATE KEYSPACE space WITH replication = {'class':'SimpleStrategy', 'replication_factor' : 3};

USE space;

CREATE TABLE documents (
              doc_id text,
              path text,
          content text,
              metadata_id text,
              PRIMARY KEY (doc_id)
            )
            WITH compression = { 'sstable_compression' : 'LZ4Compressor' };

然后我将一些数据推入其中并使用命令nodetool cfstats orpd.documents我想检查压缩率.

$ nodetool cfstats space.documents
Keyspace: space
        Read Count: 0
        Read Latency: NaN ms.
        Write Count: 2005
        Write Latency: 0.050547132169576056 ms.
        Pending Flushes: 0
                Table: documents
                SSTable count: 0
                Space used (live): 0
                Space used (total): 0
                Space used …

长Ascii字符串文本可能会或可能不会被压缩并压缩成ascii"校验和"的哈希类型,使用复杂的数学公式/算法.就像可以压缩的空气一样.

为了将兆字节的ascii文本压缩成128个左右的字节,通过混洗,然后将单个"字节"的新"模式"从第一个转到最后一个.当我们解压缩它时,首先提取最后一个字符,然后我们继续使用公式和从最后一个到第一个的顺序键进行解压缩.必须准确知道顺序键以及最后和第一个字节,包括完全更新的最终编译字符串以及压缩的总字节数.

这是我正在思考的terra压缩.这可能吗？你能解释一下这些例子 我正在研究这个理论,这是我自己的想法.