在处理半结构化数据的场景中，JSON 因其人类可读性和灵活性而被广泛采用。然而，当业务系统需要对同一份 JSON 数据执行大量重复查询时，文本解析的开销便成为性能瓶颈。二进制编码通过重新组织数据布局，实现常数时间或对数时间的随机访问，将查询性能提升数个量级。本文从内存布局设计出发，量化压缩率提升，并剖析类型安全与存储开销之间的工程权衡。
为什么二进制编码是必要的
JSON 解析的开销远超出许多开发者的预期。使用业界最快的 JSON 解析库 simdjson，对一个典型的 twitter.json（617KB）执行单次嵌套查询（如doc["statuses"].at(75)["user"]["name"]）需要约 136,784 纳秒。这意味着在处理 100 万行数据时，仅解析开销就接近 2.5 分钟 —— 足以让任何现代分析数据库处理数十亿行数据的时间相形见绌。问题的根源在于纯文本 JSON 不具备随机访问能力：定位数组第 750 个元素必须先解码前 749 个元素，无论采用何种优化策略，这一基本限制始终存在。
二进制编码通过在数据中嵌入元信息来解决这一问题。一个典型的实现采用 4 位类型标签加 28 位长度字段的结构（VarNode），每个节点占用固定的 32 位空间。类型标签区分 null、object、array、bool_true、bool_false、string 和 number 七种基本类型；长度字段对容器类型表示元素数量，对叶子节点表示负载字节数。这种紧凑的元信息布局使得解析器可以直接跳过不需要的节点，无需逐字节扫描整个文档。
内存布局的核心设计
二进制编码的内存布局本质上是一种带索引的树结构。对于数组类型，每个元素通过一个相对偏移量（VarMetaEntry）引用，偏移量以当前元数据块起点为基准计算。这使得数组访问达到 O (1) 时间复杂度，无论查询第 0 个还是第 999 个元素，耗时基本一致。实际基准测试显示，数组查询耗时稳定在 6.5 至 6.7 纳秒之间，受缓存行局部性影响的波动远小于文本解析的线性增长开销。
对象类型的布局略有不同。为了支持高效的键查找，元数据条目中的键被预先排序，二分查找将 O (N) 的线性扫描降低到 O (log N)。实验数据表明，浅层键查询可低至 12.8 纳秒，深度查询（需要更多比较次数）约为 48.2 纳秒。相比之下，文本 JSON 的相同查询耗时从 2,267 纳秒（查询键 "000"）线性增长到 7,207 纳秒（查询键 "750"），差异超过 500 倍。这种性能差距并非来自解析器的实现缺陷，而是文本格式固有的线性扫描特性决定的。
一个值得注意的设计细节是叶子值的存储方式。数值类型通常保留其原始字符串表示，而非转换为二进制浮点数或整数。这一选择避免了数值转换的双重不确定性（字符串到二进制、再从二进制到目标类型），并将类型转换的决策权留给查询时处理。虽然增加了存储开销（字符串 "100" 占用 3 字节，而 32 位整数仅需 4 字节），但换取了更低的编码复杂度和更好的精度保证。
压缩率的量化分析
二进制编码带来的压缩效果源于多个因素的叠加。首先，类型标签用 1 个字节替代了文本 JSON 中冗长的类型关键字（如 "null"、"true"、"false"），每个布尔值节省 3 至 4 字节。其次，定长偏移量替代了文本中的分隔符（逗号、冒号、方括号），在深度嵌套的场景中节省效果尤为显著。第三，键的排序使得重复键可以采用更紧凑的表示方式。
在典型工作负载下，二进制编码的压缩率通常比纯文本 JSON 提升 40% 至 60%。对于高度结构化的数据（如日志、指标、事件流），由于键的基数较低且重复率高，压缩收益可进一步放大。更重要的是，二进制布局为后续的列式压缩创造了有利条件：当数据被部分展开（shredding）到列式存储格式（如 Parquet）时，同类型数值可以连续存放，从而启用更高效的压缩算法（如字典编码、位打包）。这种二级压缩的叠加效果可使整体存储体积降至原始文本的 20% 至 30%。
然而，压缩率的提升并非没有代价。二进制编码引入了显式的元数据开销 —— 每个数组元素需要 4 字节的偏移量，每个对象键需要额外的元数据条目。对于极度稀疏的 JSON（大量嵌套层级但每个对象仅含少量键值对），元数据开销可能抵消压缩收益，甚至导致二进制表示比文本更大。这一权衡需要在具体业务场景下进行实测评估。
类型安全的工程权衡
二进制编码在类型安全方面面临着两难选择。一种极端是完全保留 JSON 的动态类型系统，所有数值以字符串形式存储，仅在运行时进行类型推断。这种方式保证了与 JSON 的完全兼容，但放弃了数值类型的存储优化。另一种极端是静态类型化 —— 在编码时将数值确定转换为整数、浮点数或定点数，从而获得更小的存储体积和更快的计算速度，但失去了处理未知类型或 schema 演化的灵活性。
Parquet 的 VARIANT 类型在这一光谱上提供了一个务实的折中方案。它定义了 20 种原始类型（整数的不同宽度、浮点数、字符串、时间戳、UUID 等），并在头部使用 6 位空间编码短字符串（小于 64 字节）的长度信息。对于对象和数组，偏移量可以选用 1 字节或 4 字节表示，允许根据预期数据规模选择合适的精度。这种设计在保持足够表达力的同时，将元数据开销控制在可接受范围内。
另一个类型相关的权衡是字符串去重策略。全局字符串表（string dictionary）可以将所有出现的相同字符串合并为单一引用，显著降低存储开销，尤其是对于高基数的键（如 UUID、时间戳）。但这引入了额外的间接层：提取一个嵌套元素不仅需要定位目标节点，还需要查询全局表来获取实际的字符串内容。这种非自包含的设计增加了数据切分和并行处理的复杂度。实际工程中，常见的做法是仅对键进行去重（因为键的基数通常远低于值），而保留值的完整表示。
实践中的关键参数
在生产环境中部署二进制 JSON 编码时，以下参数值得特别关注。编码阶段应配置的最大文档大小决定了偏移量的位宽 —— 支持 16MB 文档使用 3 字节偏移，支持 256MB 使用 4 字节，超出此范围则需要更复杂的分段策略。元数据条目的排序选项应在编码时确定：排序键允许二分查找但增加了编码时间（需要额外排序步骤），不排序则只能支持线性扫描。
缓存策略方面，由于二进制 JSON 的随机访问特性，热点数据可以长期驻留于内存而无需重新解析。建议监控的指标包括：编码后数据大小与原始 JSON 的比率（目标应在 0.4 至 0.7 之间）、查询延迟的 P99 分位数（目标应低于 100 纳秒）、以及解码（反序列化）吞吐量（目标应超过 10GB / 秒）。当压缩率显著偏离预期范围时，往往表明数据结构中存在异常值（如超长字符串或深度嵌套），需要针对性优化。
对于需要与现有生态系统集成的场景，应优先选择支持广泛的文件格式 ——BSON 在 MongoDB 生态中有天然优势，JSONB 与 Postgres 的 TOAST 存储机制深度整合，而 Parquet VARIANT 则是数据湖仓的事实标准。如果业务需要在多种系统间迁移数据，跨格式的兼容性应作为选型的首要考量。
资料来源
本文核心技术与基准数据来源于 Jin Cong Ho 发表的技术博客《Designing Binary Encodings for JSON and VARIANT》，该文详细阐述了二进制编码的设计思路与性能对比实验。