分析 Protobuf 与 JSON 并遇到数据大小问题答案

【问题标题】：Analyzing Protobuf vs JSON and ran into issues with data size分析 Protobuf 与 JSON 并遇到数据大小问题
【发布时间】：2020-07-29 21:17:44
【问题描述】：

我的任务是查看 JSON 格式的相等数据与 Java 中的 Protobuf 的数据大小和处理速度（创建数据的速度）。

对于 JSON，我使用的是 Jackson，并创建了一个带有 List<HashMap<String,String> 字段的 Subscriptions 类，称为 subscriptionList。每个 HashMap 将对应 1 个订阅。我正在从文件中读取，每一行都是“|”为字段分隔，有 523 个字段。我循环遍历分配给订阅HashMap 列名的每个字段，键名和值的列值。我遍历每一行以创建所有 1000 个订阅，我将它们放入 ArrayList<HashMap<String,String>>，然后我创建一个 Subscriptions，并将订阅列表设置为具有 1000 个订阅的 ArrayList。最后，我将Subscriptions对象转换为JSON格式的字符串，并将其写入文本文件，测量文本文件的大小，这就是我测量数据大小的方式。

对于 protobuf，.proto 文件看起来像，

message Subscriptions {
    repeated Subscription subscription = 1;
}
message Subscription {
    map<string, string> attr = 1;
}

我再次遍历每一行和每一列，创建 1000 条订阅消息，然后我反复将订阅消息添加到订阅消息中。然后我使用 .getSerializedSize 方法，这就是我测量 protobuf 消息数据大小的方法。

目前，我看到这两种格式给我的数据大小基本相同，我不明白为什么。 Protobuf 消息本身已经被压缩了一些，并且已知它们比原始 JSON 需要更少的空间。我不知道我做错了什么，而且我没有想法可以尝试。

【问题讨论】：

这个特定示例可能是 JSON 的最佳案例。当您有许多不同的字段并且都有自己的嵌套时，差异往往最为突出。
扩展@Louis 所说的：map<string,string> 可以说是 protobuf 的最差布局 - 它基本上没有优化的空间：它主要是 UTF8跨度>

标签： java json protocol-buffers

【解决方案1】：

在转换为 JSON 对象的映射和转换为 protobuf 消息的同一映射之间不会有太大区别。例如，在 protobuf 中，对象键周围没有引号，第一级消息周围没有大括号，但这并没有太大区别，特别是在大型数据集中。

在使用打包的重复字段（仅原始类型）时，您会看到 protobuf 中的一些差异，因为这些字段被转换为二进制值，因此与 JSON 中的 UTF8 编码相比，其大小大大减小。

【讨论】：