bpmn js 生成json_序列化方案选型对比 - JSON/ProtocolBuffer/FlatBuffer/DIMBIN

4千字长文预警！！

背景

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都使用了这种理念来优化数据存储性能。在JS环境中，通过建立DataView或者TypedArray来从内存段中提取数据的耗时基本上可以忽略不计。

二进制方案中存储字符串需要额外的逻辑进行UTF8编解码，性能和体积不如JSON这样的字符串格式。

DIMBIN是什么？

我们的数据可视化场景中经常涉及百万甚至千万条数据的实时更新，为解决JSON的性能问题，我们使用内存偏移量操作的思路，开发了DIMBIN作为序列化方案，并基于其上设计了许多针对web端数据处理的传输格式。

作为一种简单直白的优化思路，DIMBIN已经成为我们数据传输的标准方案，保持绝对的精简与高效。

我们刚刚将DIMBIN开源，贡献给社区，希望能为大家带来一个比 JSON/protocol/flatbuffers 更轻、更快、对Web更友好的解决方案。

方案对比

针对Web/JS环境中的使用，我们选择 JSON、protocol buffers、flat buffers、DIMBIN 四种方案，从七个方面进行对比。

工程化

Protocolbuffers 和 flatbuffers 代表Google所倡导的完整的workflow。严格、规范、统一、面向IDL，为多端协作所设计，针对python/java/c++。通过IDL生成代码，多平台/多语言使用一致的开发流程。如果团队采用这种工作流，那么这种方案更便于管理，多端协作和接口更迭都更可控。

但是如果离开了这套工程结构，则显得相对繁杂。

JSON/XML 和 DIMBIN 是中立的，不需要IDL，不对工程化方案和技术选型作假设或限制。可以只通过文档规范接口，也可以自行添加schema约束。

部署/编码复杂度

Protocolbuffers 和 flatbuffers 须在项目设计的早期阶段加入，并作为工作流中的关键环节。如果出于性能优化目的而加入，会对项目架构造成较大影响。

JSON基本是所有平台的基础设施，无部署成本。

DIMBIN只需要安装一个软件包，但是需要数据结构扁平化，如果数据结构无法被扁平化&