# 列指向OLAPデータベース ## 定義 列指向 OLAP（Online Analytical Processing）データベースは、データを行単位でなくカラム（列）単位に格納・処理するデータベースシステムであり、大規模なテーブルの集計・フィルタリング・スキャンが中心となる分析ワークロードに最適化されている。カラム単位の格納により、クエリが参照するカラムだけを読み込む選択的 I/O が可能になり、同一型のデータが連続して並ぶため圧縮効率も高い。主な対象ユースケースは BI レポート・ウェブ解析・イベントログ分析・時系列モニタリング等であり、インターネット規模の非正規化テーブルに対してリアルタイムレイテンシ（サブ秒）を実現することを目標とする（Source: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]）。 ## 横断的知見 - **OLAP システムの性能差は設計選択の組み合わせに帰着する**: ClickHouse の ClickBench では、同一ワークロードで MySQL は ClickHouse の 2957 倍（コールド）の時間を要する。この差は単一の技術ではなく、カラム型格納・データプルーニング・ベクトル化実行・コードコンパイルの複合的な効果による。（Source: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]） - **本番グレード OLAP システムと研究システムの間にはなお性能差が残る**: ClickBench（ホットラン）では研究システム Umbra が ClickHouse を上回るが、本番グレードでは ClickHouse が最速。これは研究システムが本番運用の複雑さ（多様なインテグレーション・デプロイモード・ACID 制約等）を外している分、クエリ実行に特化できるためと解釈できる。（Source: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]） - **時系列モニタリング用途での OLAP ベンチマーク研究（TSM-Bench）は OLAP の汎用ベンチマークと評価軸が異なる**: TSM-Bench は時系列固有クエリ（ウィンドウ集計・範囲クエリ）・データ変動特性・スケーラビリティを軸にするのに対し、ClickBench は非正規化ファクトテーブルへの ad-hoc クエリを中心とする。同一「OLAP」カテゴリでもベンチマーク前提が大きく異なる。（Source: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]], [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]） - **列指向 OLAP には「サーバプロセス型」と「組み込み(embedded)型」という直交する配備形態がある**: ClickHouse は独立サーバプロセスとしてクライアントプロトコル越しにアクセスされ大規模分散クラスタでの運用を前提とするのに対し、DuckDB はホストプロセスに直接リンクされC/C++ APIで呼び出される組み込みライブラリであり、サーバプロセスもクライアントプロトコルも持たない。両者とも列指向格納・ベクトル化実行という中核技術は共有するが、DuckDB はJITコンパイルでなくベクトル化解釈実行を選択している点でClickHouseのコードコンパイル戦略とも異なる（Source: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]], [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]]）。 - **組み込み型OLAPでは「結果セットの転送コスト」が独自の性能軸になる**: DuckDB論文は、クエリ実行自体は高速なサーバ/クライアント分離型システム(HyPer)でも、ソケット経由の結果セット転送がボトルネックになりうると指摘する。プロセス内で直接メモリ共有できる組み込み型はこの転送コストを原理的に回避できる。ClickHouse等のサーバプロセス型OLAPの性能評価(ClickBench等)はクエリ実行時間を中心に据えるため、この転送コスト軸は評価から抜け落ちやすい（Source: [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]]）。 - **列指向OLAPの「ネイティブ半構造化データサポート」という第3の配備軸が Snowflake で明示化された**: サーバプロセス型(ClickHouse)・組み込み型(DuckDB)という配備形態の分類とは別に、[[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] は JSON/Avro/XML を型推論とプルーニング用統計付きで直接カラムナ格納する VARIANT 型を導入し、半構造化データに対しリレーショナルデータとほぼ同等(約10%オーバーヘッド)の性能を達成した。ClickHouse・DuckDB がいずれも半構造化データを主要な一次データ型として扱っていない(前提は事前定義されたリレーショナルスキーマ)のと対照的であり、列指向OLAPの評価軸が「配備形態」だけでなく「スキーマ前提の有無」でも分岐しうることを示す。(Source: [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]], [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]], [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]]) - **列指向OLAPシステムにおけるプルーニングの実現手段は「インデックス」ではなく「ファイル/ブロック単位の統計」で収斂している**: Snowflake の min-max ベースのファイルプルーニング(zone maps 相当)は、ClickHouse のスキッピングインデックスと同種の「データを読まずに除外する」思想を共有する。両者ともB+ツリー等の伝統的インデックスを主要な絞り込み手段としない点で一致する。(Source: [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]], [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]) - **列指向OLAPの起源はリレーショナルデータへの適用よりも早く、2010年時点でネストデータモデルへの拡張として一度完成している**: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]は、ClickHouse・DuckDB・Snowflakeが前提とする「事前定義されたリレーショナルスキーマ」ではなく、Protocol Buffers由来の任意深さのネスト構造(反復・オプショナルフィールド)を持つレコードに対し、repetition level・definition levelという符号化でカラム型格納を実現した(→ [[ネスト型カラムナストレージ]])。Snowflakeが2016年に導入したVARIANT型による半構造化データサポートは、Dremelが2010年に既に取り組んだ「非フラットなデータへの列指向拡張」という課題の、リレーショナルDBMS側からの再到達と位置づけられる。(Source: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]], [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]]) - **列指向ストレージの恩恵はDBMSに限らずバッチ処理フレームワークにも及ぶ**: Dremelの実験では、MapReduceジョブをrecord-orientedからcolumnar-orientedストレージへ切り替えるだけで実行時間が1桁短縮された(87TB→約13TB相当の読み取り量)。これはClickHouse・DuckDB・Snowflakeの性能改善が専らDBMS内部のクエリ実行(ベクトル化・コードコンパイル等)に帰着するのに対し、列指向という「データ形式」自体がDBMS外のツールにも独立して価値を持つことを示す一次証拠である。(Source: [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]) ## 未解決の問い - ClickHouse の TPC-H 結果が Snowflake に劣後する主因はジョイン再順序化・ジョイン述語プッシュダウンの欠如とされるが、これらを実装した場合の到達上限はどの程度か。 - 高インジェスト率ワークロードにおける「バックグラウンドマージのリソース消費 vs. クエリ性能」のトレードオフを本番規模で定量化した研究はあるか。 - Druid/Pinot のように「パートが永続不変（マージなし）」とする設計と、ClickHouse の「継続的マージ+データ変換」設計では、長期運用（5 年以上）でのストレージ効率・クエリ性能・運用コストにどのような差が生じるか。 - 列指向 OLAP と時系列データベース（TSDB）のユースケース境界はどこにあるか（ClickHouse は監視用途でも広く使われるが TSM-Bench では InfluxDB 等の TSDB と比較される）。 - 組み込み型(DuckDB)とサーバプロセス型(ClickHouse)の列指向OLAPを同一ベンチマーク条件(同一ハードウェア・同一クエリセット)で比較した定量評価は存在するか。結果転送コストを除いたクエリ実行時間だけで見た場合、両者の性能差はどの程度縮まるか。 - Dremel(2010)のrepetition/definition level符号化は、Snowflake(2016)のVARIANT型によるネスト半構造化データ格納と技術的にどの程度重なるか、あるいは異なる設計選択をしているか。両者を直接比較した文献はあるか。 ## 関連 - ソース: [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]] / [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]] / [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]] / [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]] / [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] - 概念: [[LSMツリー]] / [[LSMツリーコンパクション]] / [[並列データベース]] / [[データパーティショニング]] / [[時系列データベース]] / [[べき等性]] / [[結果整合性]] / [[シェアードナッシング]] / [[ネスト型カラムナストレージ]] - エンティティ: [[ClickHouse]] / [[ClickHouse Inc|ClickHouse Inc.]] / [[DuckDB]] / [[MonetDBLite]] / [[Snowflake Computing]] ## 出典 - [[@2024__PVLDB__ClickHouse - Lightning Fast Analytics for Everyone]]（§1 Introduction, §6 Performance as a Feature） - [[@2023__PVLDB__TSM-Bench - Benchmarking Time Series Database Systems for Monitoring Applications]]（時系列モニタリング OLAP ベンチマークの比較軸） - [[@2019__SIGMOD__DuckDB - an Embeddable Analytical Database]]（組み込み型OLAPの設計要件・アーキテクチャ） - [[@2016__SIGMOD__The Snowflake Elastic Data Warehouse]]（半構造化データのネイティブ列指向サポートとファイル単位プルーニングの産業実装例） - [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]]（ネストデータモデルへの列指向ストレージ拡張の起源、Google, 2010年）