開発者がJSONのデータ量を減らすスキーマ言語を構築

ある独立系開発者が、JSON形式のデータが占める容量を減らすための独自のバイナリシリアライザーとスキーマ言語を構築し、その過程を記録した。基本的な値をよりコンパクトに表す実験として始まったプロジェクトは、エンコーダーとデコーダーを生成できる型付きの形式へと発展した。開発者は、試した例ではデータ量を約80％削減できたと報告している。ただし、これはプロジェクト内の結果であり、独立したベンチマークではない。

設計の出発点は、よく知られた非効率性だ。数値としては1バイトに収まる数でも、文字列で書くと数バイトを要することがある。しかし、値を小さく格納するだけでは十分ではない。デコーダーは、その型と次のフィールドの開始位置も知る必要があるからだ。このプロジェクトでは、型と長さの情報を持つヘッダーでこの問題に対処する。より大きな長さを表すためには、各バイトの7ビットをデータに使い、残る1ビットでヘッダーが続くかどうかを示す可変長整数方式を採用している。

この土台により、すべての値に固定幅の付加データを付けることなく、文字列と整数を一つのストリームに混在させられる。開発者はさらに、正と負の整数を符号なしの数列に対応させることで、この方式を符号付き数値へと拡張した。これはジグザグ符号化で知られる一般的な手法だ。通常のJSONではフィールド名の繰り返しも無駄の原因となるため、この形式は再利用可能なスキーマを個々のレコードから分離する。送信側と受信側がスキーマを共有すれば、符号化したデータは文字列のキーを繰り返す代わりに、宣言済みの構造を通じてフィールドを特定できる。

実験は、基本的な型と、より複雑な構造を扱う小さなスキーマ言語へと成長した。開発者は、配列、省略可能な値、列挙型、ユニオン型を追加し、それらの宣言からシリアライズ用のコードを生成する過程を説明している。これは複雑さをツール側へ移すことでもある。コンパクトなバイト表現を使うには、両側でスキーマについて厳密に合意する必要があり、新旧の読み取り側で気付かないまま解釈が食い違わないよう、変更を管理しなければならない。通信時の表現を小さくする代わりに、人間にとっての読みやすさやJSONの幅広い互換性も手放すことになる。

このプロジェクトは、万能な代替手段の推奨ではなく、技術的な探究として捉えるのが適切だ。JSONは、デバッグ、相互運用性、データ量が二次的な問題であるシステムでは、依然として便利だ。独自のバイナリ形式を導入すると、既存の形式やライブラリが長年取り組んできた保守、互換性、セキュリティ上の責務を負うことになる。公表された記録には、複数のプラットフォームにまたがる性能試験、独立した検証、成熟した代替手段との比較は示されていない。

それでも、この取り組みは、なぜバイナリシリアライズが複雑になるのかを具体的にたどれる内容になっている。バイト数を節約するには、単に区切り記号を除けばよいわけではない。形式は、曖昧さなく復号できるようにしながら、型、長さ、符号、コレクション、形式の進化に関するルールを表現する必要がある。この実験の主な貢献は、コンパクトな表現が言語とツールチェーンへと発展するにつれ、こうした要件が一つずつ現れる様子を示したことにある。