# ネスト型カラムナストレージ ## 定義 ネスト型カラムナストレージとは、Protocol Buffers等のネスト(入れ子)構造を持つレコードを、フラットなリレーショナルデータと同様にカラム(列)単位で格納しつつ、レコードの構造情報を損失なく保持・復元できるようにする列指向ストレージ形式である。各フィールドの値に加え、「反復フィールドがどの階層で繰り返したか」を示す**repetition level(繰り返しレベル)**と、「オプショナル・反復フィールドのうちどこまでが実際に定義されているか」を示す**definition level(定義レベル)**という2つの整数を付与することで、値だけからは失われる木構造の情報を符号化する。この形式は[[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]](VLDB 2010)がGoogleのDremelシステム向けに提案したものであり、著者らはリレーショナルデータへの列指向ストレージ適用は既存研究があったが、ネストデータモデルへの拡張は本論文が最初であると主張する(Source: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] §9 Related Work)。 ## 横断的知見 - **オブザーバビリティ向け列指向ストア(Retriever)は、ネスト型カラムナストレージが解決する「任意深さの入れ子構造の保持」という問題設定を最初から回避している**: Dremelのrepetition/definition level符号化は、Protocol Buffers由来の反復・オプショナルフィールドを持つ真に木構造なレコードから、値だけでは失われる構造情報を損失なく復元することを目的とする。これに対しHoneycomb Retriever([[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]])が扱う構造化イベントは、`trace.trace_id`や`session.id`のようなドット区切りのフィールド名で疑似的な階層を表現するに留まり、各フィールドはその文字列全体をキーとする独立したフラット列として格納される(1イベント=1行、フィールドの反復や可変深さのネストを前提としない)。Retrieverはこの単純なフラット表現を貫くことで、repetition/definition levelのような構造復元コスト自体を発生させない設計を取る。これは、ネストデータモデルへの列指向拡張という2010年のDremelの問題設定が、オブザーバビリティの構造化イベント(仕様上ほぼフラットなキーバリュー集合)には適用されない——ワークロードのデータモデル(真の木構造 対 ドット区切りのフラットキー)によってネスト対応の要否が分かれる——ことを示す最初の対比事例である。(Source: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] §4, [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]] "Storing Data by Column Within Segments") - **ClickHouseは「未知の属性を含むイベント」への対応を、Dremelの構造符号化ともRetrieverのフラットキー規約とも異なる第3の手段——実行時の動的マテリアライゼーション——で解決する**: [[ClickHouse]]([[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]])はまず、頻出する少数の属性をトップレベルの固定カラムに、その他の任意属性を`Map(String, String)`型カラムに格納するハイブリッドモデルを提供する(ただしMap型はキーアクセス時に全キー・値の読み取りを要しI/O効率が悪く、主キーにも使えないという制約を持つ)。2025年に導入された`JSON`型はこの制約を緩和し、挿入時に頻出フィールドを自動的に具象カラムへ昇格させ、稀なフィールドは型ヒント付きの別blob構造へ格納する。DremelがPARSE時に木構造を静的スキーマ(Protocol Buffers定義)に基づき符号化し、Retrieverが命名規約でネストを最初から回避するのに対し、ClickHouseは「どのフィールドが頻出か」を実行時の挿入パターンから動的に判定してスキーマを合成する。3者はいずれも「未知・可変な構造をどう列指向ストレージに落とすか」という同じ問題への回答だが、静的スキーマ符号化(Dremel)・命名規約による構造回避(Retriever)・実行時マテリアライゼーション(ClickHouse)という異なる時点(スキーマ定義時・命名時・挿入時)で問題を解決している点が異なる。(Source: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] §4, [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]], [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]] "Balancing structure and flexibility with map") ## 未解決の問い - repetition level・definition levelの符号化方式は、Apache ParquetのDremel由来のネストカラム表現(shredding)とどこまで一致し、どこで異なるか。 - Dremel論文はジョイン・インデックス・更新を将来課題として明示的にスコープ外としているが(§6, §10)、これらをこの符号化方式に追加した後継システム(F1・Napa等)ではrepetition/definition levelの扱いはどう拡張されたか。 - 定義レベル・繰り返しレベルをビット列としてパックする際の圧縮効果は、フィールドのスパース性(数千フィールド中数百のみ使用というGoogleの実データ特性、Source: §4.2)にどの程度依存するか。他のワークロード(フィールド充填率が高いデータ)でも同様の利得が出るか。 - Retrieverのようなドット区切りフラットキー方式は、将来的に真の配列型フィールド(例: 1イベントが複数のexemplarやリンクを持つ)を扱う必要が生じた場合、Dremel型のrepetition levelを部分的に導入せざるを得なくなるか。それとも配列を独立イベント行へ正規化する等、フラット表現のまま拡張できるか。 - ClickHouseの`JSON`型による実行時マテリアライゼーションは、Dremelのスキーマ時符号化と比べてクエリプランニングの予測可能性(どのフィールドが列としてプルーニング可能か事前にわかるか)にどの程度劣るか。挿入パターンが変動しやすいワークロード(A/Bテストのフィーチャーフラグ属性等)では、頻出フィールドの判定自体が不安定化し、具象カラムへの昇格・降格が繰り返されるコストは生じないか。 ## 関連 - ソース: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]] - 概念: [[列指向OLAPデータベース]] / [[並列データベース]] / [[データパーティショニング]] - エンティティ: [[Protocol Buffers]] / [[Google]] / [[Sergey Melnik]] / [[Retriever]] / [[Honeycomb.io]] / [[ClickHouse]] ## 出典 - [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]](§4 Nested Columnar Storage、Figure 1-3、Appendix A-C) - [[@2026__OReilly__Observability Engineering 2E - Chapter 13 Efficient Data Storage with Retriever]](ドット区切りフラットキーによるネスト構造回避、"Storing Data by Column Within Segments") - [[@2026__OReilly__Observability Engineering 2E - Chapter 14 Efficient Data Storage with ClickHouse]](Map型とJSON型による半構造化データの実行時マテリアライゼーション、"Balancing structure and flexibility with map")