@levinzhang
2016-08-31T06:03:20.000000Z
字数 2200
阅读 579
by Abel Avram on Aug 27, 2016
Shape Security开源了一个新的无模式二进制序列化格式,名为SuperPack。
Shape Security开源了一个新的无模式二进制序列化格式,名为SuperPack。
SuperPack使用了二进制的序列化模式,这意味着会减少负载的大小。按照Shape Security的说法,对于一个给定的4.48 KB的样例信息,相对于多个其他的无模式格式,SuperPack的负载是最小的:
原始信息 | YAML | BSON | JSON | Sereal | SuperPack | |
---|---|---|---|---|---|---|
非压缩 | 4.769 B | 134% | 111% | 69% | 40% | 28% |
压缩 | 4.769 B | 14% | 20% | 12% | 16% | 13% |
YAML和BSON非常冗长,会增加消息的负载。JSON比YAML要好得多,但是因为它基于文本编码格式,所以它的大小依然会远远超过SuperPack。在gzip
压缩之后,它们的值会出现比较大的差异,YAML、JSON和SuperPack的值非常接近,是原始消息的12-14%。
采用SuperPack编码格式的一个主要优势在于,与客户端通信的时候不需要预先交换消息的模式。数据类型的信息会包含在负载之中。SuperPack有36个预先定义的数据类型,包括常见的true、false、uint16、uint32、float32
,也包括不那么常见的类型,如 uint6
、nint4
和array5
等,这些类型能够代表消息中很可能出现的值。
SuperPack还包含了针对数组、字符串以及map的类型。其中还有个类型是 extension
,它能够让用户添加新的类型。SuperPack还有两个可选的优化选项,能够减少特定场景下的负载:重复字符串优化(repeated string optimization)以及重复keyset优化(repeated keyset optimization)。
我们采访到了Michael Ficarra,他是一名研究工程师和自由/开源软件协调人员(FOSS Coordinator),了解到了SuperPack的更多细节。
InfoQ:在编码后,你们的负载会更小,相对于其他的无模式格式,你们的做法有何不同呢?
MF: SuperPack有其背后的哲学,那就是即便我们不能预先推测出数据的模式,但数据中的结构或值很可能会重复出现很多次。举个例子,假设有个名为“cats”的数据结构,它将每个人与他的猫关联在了一起。我们不是直接进行编码,考虑到每只猫都有名称、生日以及喜欢的食物,我们只对其编码一次,稍后会对其进行引用,对这些值采用了非常高效的protobuff风格的打包方式。
另外,有些值比其他的值更为通用,应该有更为高效的表述形式。如果你看一下格式的详细描述的话,你会发现所有的值都由一个单字节的指示符打头,它用来表明值的类型,我们将其称之为“类型标签(type tag)”。在类型标签域中,我们预留了一部分区域范围,这样的话,值的全部或部分内容就可以在标签本身中进行编码。举个简单的例子,有两个boolean类型标签:一个用于值true,另一个用于值false。类似的,还有64个“uint6”类型标签,允许我们使用一个字节就能表示0到63之间的每个数字,另外,对于条目长度小于32的数组(必须要同时对它的长度和条目进行编码),可以将它的长度编码到标签中。回到前面的例子中,猫的胡须通常不会多于64根并且大多数人所养的猫不会超过32只,因此这些值能够非常高效地进行存储。
InfoQ:你们将SuperPack与模式驱动的二进制格式进行过对比吗,比如Protocol Buffers?Protobuf的负载会明显更小吗?
MF:我们没有进行过这种类型的对比。我认为,在大多数场景下,Protobuf的负载会更小,除非SuperPack的字符串去重功能能够特别有效。当你的需求允许你使用模式驱动格式的话,尤其是能够与某种无损数据压缩算法(如LZW或Deflate)结合使用时,那么你就应该采用这种方案。
InfoQ:在消息的编码/解码上所消耗的时间是怎样的?
MF:根据编码器是否启用可选的keyset和字符串去重优化功能,编码时间会有所差异。在实现语言层面,也会有一些遗留的性能难题,比如JavaScript针对所有的数字都使用了IEEE 754的双精度形式。
InfoQ:你们有支持其他语言的计划吗?
MF:当然!我们已经有了一个Java实现,目前,这个实现我们在Shape Security内部使用。它还没有为开源做好准备,但是如果我们听到有这种需求的话,就会加快这一进程。如果社区希望为另外的生态系统启动新实现的话,我也是非常乐意提供帮助的。我觉得Rust实现将是非常令人兴奋的!
另外,值得一提的是,SuperPack依然非常年轻,如果读者对于它的提升有什么建议的话,我们非常乐意倾听,只需在规范的issue tracker上开启一个issue即可。我们希望将来版本的SuperPack会更棒!
目前,SuperPack自带了一个JavaScript转码器,但是其他的转码器可以基于它来进行开发。SuperPack是开源的,并且采用了非常宽容的许可证协议。
查看英文原文:SuperPack, a New Serialization Format with a Smaller Payload