# バイナリエンコーディング ## 定義 バイナリエンコーディングとは、メモリ上のデータ構造をネットワーク送信やディスク保存に適したバイト列へ変換する際に、テキスト形式(JSON・XML・CSV)よりも高密度に符号化する手法の総称である。JSON をそのままバイナリ化した「JSON のバイナリ変種」(MessagePack、CBOR、BSON 等)と、事前に定義したスキーマを前提とする「バイナリスキーマ駆動エンコーディング」([[Protocol Buffers]]、[[Apache Avro]])の2系統に大別される。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "JSON, XML, and Binary Variants", "Protocol Buffers", "Avro") ## JSON のバイナリ変種とスキーマ駆動形式の違い `{"userName": "Martin", "favoriteNumber": 1337, "interests": ["daydreaming", "hacking"]}` という例示レコードで比較すると、テキスト JSON は81バイト、MessagePack は66バイトとわずかな削減にとどまる。これは MessagePack がスキーマを前提としないため、`userName` のようなフィールド名の文字列そのものを符号化データ中に含める必要があるからである。対して Protocol Buffers(33バイト)・Avro(32バイト)はスキーマ側にフィールド情報を持つため、符号化データからフィールド名を完全に省略でき、約半分のサイズで済む。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "JSON, XML, and Binary Variants", "Protocol Buffers") ## スキーマ駆動エンコーディングの利点 - 「binary JSON」変種よりも大幅にコンパクト(フィールド名を省略できるため)。 - スキーマ自体が常に最新であることが保証されたドキュメントになる(デコードに必須なので陳腐化しない)。 - スキーマのデータベースを持てば、デプロイ前に前方・後方互換性を機械的にチェックできる。 - 静的型付け言語ではスキーマからコード生成でき、コンパイル時型検査が効く。 これらのアイデアの起源は 1984 年に標準化された ASN.1 に遡り、その規則は現在も X.509 証明書のバイナリエンコーディング(DER)に使われているが、ASN.1 自体は複雑で文書が乏しく新規採用には向かないとされる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "The Merits of Schemas") ## Protocol Buffers と Avro の設計対比 両者ともスキーマを要求する点は共通だが、フィールド識別の方式が異なる。[[Protocol Buffers]] はスキーマで割り当てたタグ番号を符号化データに埋め込み、デコード側はそのタグ番号だけを頼りに読む(reader's schema のみで完結)。[[Apache Avro]] はタグ番号を持たず、符号化データはフィールドの値だけを記載順に連結したもので、デコードには符号化時に使った writer's schema と読み手が期待する reader's schema の両方が必要になり、両者をフィールド名で突き合わせて差分解決する。この違いにより、Avro はリレーショナルスキーマ等からの動的スキーマ生成に向き、Protocol Buffers はタグ番号の一意性を人手で管理しやすい静的なスキーマ運用に向く。→ [[スキーマ発展]] ## 横断的知見 - **「サイズ接頭辞+バイト列」という可変長データの符号化パターンは、ネットワーク/RPC層とディスクページ層の双方で独立に採用される基本語彙である**: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] が扱う Protocol Buffers・Avro はいずれも文字列やバイト列のフィールドを長さ情報とペイロードで符号化する。[[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] は同じパターンをディスク上のページ/セルレベルで「Pascal文字列(UCSD文字列)」として提示する(`String { size uint_16; data byte[size] }`)。両者は対象レイヤー(前者はプロセス間通信・保存レコード、後者はページ内の物理バイト配置)が異なるにもかかわらず同一の符号化語彙に収束しており、Database Internals 第3章自身も「同様のガイドラインを使用して、ファイルおよびシリアライズのフォーマット、または通信プロトコルを作成できる」と明言する。これは本 concept の定義が指す「バイナリエンコーディングの一般原則」が、レイヤーを問わず再利用可能であることを2ソースの突き合わせで裏付ける。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "JSON, XML, and Binary Variants", [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] §3.2.2, §3.3) - **DDIA第5章はフィールド識別(タグ番号)とスキーマ発展の互換性に焦点を当てるのに対し、Database Internals第3章はバイト配置そのもの(エンディアンネス・ビットパック化・固定長ヘッダのオフセット計算)に焦点を当てる**: 前者が扱う Protocol Buffers のタグ番号や Avro の writer/reader スキーマ突き合わせは「どのフィールドか」を識別する問題であるのに対し、後者が扱うビッグ/リトルエンディアンの選択やフラグのビットマスク設計は「同じフィールドをどう並べるか」という一段低いレイヤーの問題である。両者は排他的ではなく積み重なる関係にあり、実際のストレージエンジン(RocksDBのエンディアンネス変換等)はDatabase Internals層の問題を解いた上でスキーマ発展の互換性を別途設計する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] "Protocol Buffers", [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] §3.2.1, §3.2.3) ## 未解決の問い - Cap'n Proto や FlatBuffers のような zero-copy 形式(エンコード/デコード変換を省略できる)は、Protocol Buffers/Avro とスキーマ発展規則をどこまで共有するか。 - ASN.1 の DER が X.509 証明書で今も使われ続けている理由(相互運用性の慣性)は、現代の新規プロトコル設計でどう回避・軽減されているか。 - 列指向ストレージにおける Protocol Buffers のネストデータモデル([[ネスト型カラムナストレージ]]、Dremel)は、Avro のスキーマ発展規則とどう相互作用するか。 - ディスク上のスロット化ページ([[スロット化ページ]])が使うページID間接参照(実オフセットをルックアップテーブル経由で解決する設計)は、ネットワークプロトコルのバイナリエンコーディングに類似の間接参照パターンが存在するか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] - 概念: [[スキーマ発展]] / [[ネスト型カラムナストレージ]] / [[スロット化ページ]] - エンティティ: [[Protocol Buffers]] / [[Apache Avro]] / [[RocksDB]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 5 Encoding and Evolution]]("JSON, XML, and Binary Variants", "Protocol Buffers", "Avro", "The Merits of Schemas") - [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]](§3.2 バイナリエンコーディング — プリミティブ型・エンディアンネス・Pascal文字列・ビットパック化データ)