序列化方案选型对比

原文：https://www.sohu.com/a/325019687_612370

序列化方案选型对比 - JSON/ProtocolBuffer/FlatBuffer/DIMBIN

 

背景

JSON/XML不好吗？

好，再没有一种序列化方案能像JSON和XML一样流行，自由、方便，拥有强大的表达力和跨平台能力。是通用数据传输格式的默认首选。不过随着数据量的增加和性能要求的提升，这种自由与通用带来的性能问题也不容忽视。

JSON和XML使用字符串表示所有的数据，对于非字符数据来说，字面量表达会占用很多额外的存储空间，并且会严重受到数值大小和精度的影响。 一个32位浮点数 1234.5678 在内存中占用 4 bytes 空间，如果存储为 utf8 ，则需要占用 9 bytes空间，在JS这样使用utf16表达字符串的环境中，需要占用 18 bytes空间。 使用正则表达式进行数据解析，在面对非字符数据时显得十分低效，不仅要耗费大量的运算解析数据结构，还要将字面量转换成对应的数据类型。

在面对海量数据时，这种格式本身就能够成为整个系统的IO与计算瓶颈，甚至直接overflow。

JSON/XML之外还有什么?

众多的序列化方案中，按照存储方案，可分为字符串存储和二进制存储，字符串存储是可读的，但是由于以上问题，这里只考虑二进制存储。二进制存储中可分为需要IDL和不需要IDL，或分为自描述与非自描述（反序列化是否需要IDL）。

需要IDL的使用过程：

• 使用该方案所定义的IDL语法编写schema
• 使用该方案提供的编译器将schema编译成生产方和消费方所用语言的代码（类或者模块）
• 数据生产方引用该代码，根据其接口，构建数据，并序列化
• 消费方引用该代码，根据其接口读取数据

不需要IDL的使用过程：

• 生产方与消费方通过文档约定数据结构
• 生产方序列化
• 消费方反序列化

etc.

• protocol buffers
• gRPC所用的传输协议，二进制存储，需要IDL，非自描述
• 高压缩率，表达性极强，在Google系产品中使用广泛
• flat buffers
• Google推出序列化方案，二进制存储，需要IDL，非自描述（自描述方案不跨平台）
• 高性能，体积小，支持string、number、boolean
• avro
• Hadoop使用的序列化方案，将二进制方案和字符串方案的优势结合起来，仅序列化过程需要IDL，自描述
• 然而场景受限，没有成熟的JS实现，不适合Web环境，这里不做对比
• Thrift
• Facebook的方案，二进制存储，需要IDL，非自描述
• 基本上只集成在RPC中使用，这里不做对比
• DIMBIN
• 针对多维数组设计的序列化方案，二进制存储，不需要IDL，自描述
• 高性能，体积小，支持string、number、boolean

优化原理

空间优化原理

使用数值类型而非字面量来保存数值，本身就能节约一笔十分可观的空间。 protocol buffer为了实现更高的压缩率，使用varint去压缩数值。（不过下面的测试表明，可以使用gzip的环境中，这种方案没有帮助）

时间优化原理

二进制格式用通过特定位置来记录数据结构以及每个节点数据的偏移量，省去了从字符串中解析数据结构所耗费的时间，避免了长字符串带来的性能问题，在GC语言中，也大大减少了中间垃圾的产生。

在可以进行内存直接操作的环境中(包括JS)，还可以通过内存偏移量直接读取数据，而避免进行复制操作，也避免开辟额外的内存空间。DIMBIN和flatbuffers都使用了这种理念来优化数据