使用静态字典

时间:2018-04-12 02:29:53

标签: java performance compression latency throughput

这将是一个抽象的问题,因为我甚至不知道是否有这样的发展。

鉴于我们有一个应用程序试图将文本数据从A点传递到B. A和B距离很远,因此数据大小对我们想要优化的所有重要指标(速度,延迟和吞吐量)有显着影响。首先想到的是压缩,但是当我们必须压缩许多小消息时,压缩并不是那么有效,但是当压缩数据的大小很大时,压缩非常有效。

我没有使用压缩算法的经验,但我的理解是输入越大,压缩率越高,因为重复块和可以优化的事物的可能性更大。

我们可以采用的另一种方式是批处理,等待N段时间并收集所有微小的消息并创建一个压缩的大消息,我们可以获得良好的压缩率,但我们会牺牲延迟,首先到达的消息将采取N的不必要的延迟。

我正在寻找的解决方案是这样的,当压缩算法遍历数据集时,它可能有一些它知道可以优化的事物字典。每次我们完成压缩时都会丢弃此字典,并且始终将消息发送给B.

rawMsg -> [dictionary|compressedPayload] -> send to B

然而,如果我们可以将这个字典保存在内存中,并且仅在它发生变化时发送,这意味着我们可以有效地压缩甚至小的消息并避免每次都将字典发送到另一端。 ..

rawMsg -> compress(existingDictrionaryOfSomeVersion, rawMsg) -> [dictionaryVersion|compressedPayload] -> send to B

现在很明显,这里的假设是B还会保留字典的实例,并在新版本到货时不断更新。

请注意,protobuffix等协议(在财务应用程序中)已经发生了这种情况。 对于任何消息,您都有架构(字典),并且它在两端都可用,然后您只需发送原始二进制数据,高效且快速,但您的架构是固定不变的。

我正在寻找可用于自由格式文本的内容。

是否有任何技术可以执行此操作(没有固定架构)?

1 个答案:

答案 0 :(得分:1)

您只需在单个压缩流中发送许多小消息即可。然后他们将能够利用以前的小消息历史。使用zlib,您可以清除每条消息,这样可以避免在传输之前等待整个块的建立。这会降低压缩率,但不会像尝试单独压缩每个字符串那样多(这可能最终会扩展它们)。对于zlib,您的字典始终是您发送的最后32K消息。