OLAPデータベース：とは何か、実ユースケース、主要ベンダー

OLAPデータベースとは何か、OLTPとの違い、実SQLを使った実践ユースケース、そして2026年の主要ベンダーを解説。

OLAPとは何か（そして何ではないか）
- OLAPではないもの
OLAP vs OLTP：すべてを説明する違い
- カラム指向がすべてを変える理由
歴史：キューブからカラム型へ（そしてなぜ気にすべきか）
スタースキーマ：OLAPデータのモデリング方法
実SQLでの実践ユースケース
2026年の主要OLAPベンダー
選び方：4つの問いでの私の基準
なぜこれが見た目以上に重要か、という考察
結論
よくある質問

OLAPとは何か（そして何ではないか）

OLAPはOnline Analytical Processing（オンライン分析処理）の略です。これはワークロードのカテゴリであり、特定の製品ではありません。

この区別は見た目以上に重要です。「OLAPが必要だ」と誰かが言うとき、彼らが記述しているのはパターンです。ビジネス上の問いに答えるために、数百万から数十億行をスキャンし集計するクエリ。「過去3年間の月次売上を商品と地域別に」というクエリは、1998年のキューブに対してExcelで実行しても、今日の10億行テーブルに対して投げても、OLAPクエリです。

この用語は、リレーショナルモデルと同じE. F. Coddが1993年にProviding OLAP to User-Analysts: An IT Mandateという論文で定義したもので、そこで分析システム向けの12のルールを定めています。

ほとんど誰も触れない正直な注記：あの論文はArbor Softwareがスポンサーしていました。ArborはEssbaseの開発元であり、Essbaseは最初期のOLAP製品の一つです。12のルールは、Essbaseが既にやっていたことを疑わしいほど見事に記述していました。学術論文の姿をした見事なマーケティング手法だったわけですが、それでもその根底にあった区別――分析ワークロードにはトランザクショナルなものとは異なる設計が必要だ――は完全に正しく、30年経った今でもこの分野を定義しています。

「オンライン」という言葉も誤解を招きます。インターネットとは一切関係ありません。1993年当時は対話的を意味し、夜間に生成されるバッチ報告書の対極でした。

OLAPではないもの

データウェアハウスと同じではありません。 OLAPは処理のカテゴリであり、データウェアハウスはインフラのパターンです。ウェアハウスはOLAPワークロードを提供するために構築されますが、OLAPはリアルタイムデータベース、組み込みエンジン、セマンティックレイヤーでも動きます。

「ワイドカラム」データベースでもありません。 名前のせいで生じる典型的で理解できる誤解です。Cassandra、HBase、Bigtableは「カラム指向」と説明されますが、内部では行ストアです。パーティションキーで行をグループ化し、各行の中にカラムをキーバリューペアとして格納します。柔軟なスキーマのOLTPワークロードを支えるものであり、分析集計用ではありません。誰かがダッシュボードにCassandraを提案してきたなら、そこには誤解があります。

「ビッグデータ」の同義語でもありません。 5 GBのデータでも完全に正当なOLAPワークロードは存在します。パターンを定義するのはクエリの形であり、データ量ではありません。

OLAP vs OLTP：すべてを説明する違い

OLTP（Online Transaction Processing）はPostgreSQL、MySQL、Oracleがやることです。トランザクションと強い一貫性で、少数の行を非常に高速に読み書きします。「注文8821をちょうだい」「在庫を1つ減らして」。

OLAPはほぼすべての軸でその逆です。

	OLTP	OLAP
ストレージ	行指向	カラム指向
読み取りパターン	少数のカラム、少数の行	多数の行、少数のカラム
書き込みパターン	1行の更新、高頻度	一括挿入、ほぼ追記専用
目標レイテンシ	ミリ秒	サブ秒〜秒
同時実行	数千ユーザー、単純なクエリ	数十〜数百、複雑なクエリ
スキーマ	正規化（3NF）	スター型または非正規化された幅広
典型的な問い	「注文Xの状態は？」	「地域別に注文はどう推移したか？」
例	PostgreSQL、MySQL、Oracle	ClickHouse、Snowflake、BigQuery、DuckDB

2つの設計は本質的に両立しません。そして両方が存在する理由はそこにあります。1行をトランザクションの完全性とともに書くことに最適化されたエンジンが、同時に4億行をスキャンして1つの数値に集約することにも最適化されることは不可能です。

カラム指向がすべてを変える理由

物理的な違いは簡単に見えます。行指向データベースはディスクにこう保存します。

[id:1|país:ES|ingresos:42|fecha:...] [id:2|país:MX|ingresos:17|fecha:...]

ingresosを合計するには、paísやfecha、関心のない他の30カラムも一緒に読まなければなりません。カラム型は各カラムを別々に保存します。

ingresos: [42, 17, 88, 12, ...]
país:     [ES, MX, ES, AR, ...]

テーブルが40カラムあり、クエリが2つしか使わない場合、データの5%しか読みません。さらに隣り合う値は同じ型で繰り返しやすいので、圧縮効率が劇的に良くなります。ディスク上のバイト数が減り、I/Oが減り、クエリが速くなります。

その上、現代のエンジンはベクトル化実行（行ごとではなくSIMD命令でカラムのバッチを処理）、データスキッピング（スパースインデックスとmin/max統計でブロック全体を読まずに飛ばす）、コンピュートとストレージの分離を追加しています。

歴史：キューブからカラム型へ（そしてなぜ気にすべきか）

この部分は博物館のトリビアに見えますが、ネット上のドキュメントが誰も使わなくなった概念で溢れている理由を説明してくれます。

MOLAP、ROLAP、HOLAP

何十年も続いた標準的なOLAP分類はこれです。

モデル	ストレージ	クエリパス	強み	問題
MOLAP	事前集計キューブ（Essbase、Analysis Services）	MDX → キューブへクエリ	事前定義された次元でサブ秒の応答	数時間のビルド、次元追加でストレージが爆発、硬いスキーマ
ROLAP	リレーショナルテーブル（Snowflake、BigQuery、ClickHouse）	SQL → オンデマンド集計	アドホッククエリ、任意の次元、柔軟なスキーマ	クエリごとのレイテンシが大きい（エンジンが非常に高速なら別）
HOLAP	両者の混在	要約はキューブ、明細はSQL	プロプライエタリなスタック内での歴史的妥協	2つのシステムを運用するコスト

MOLAPは90年代から2000年代の王様でした。OLAPキューブのアイデアは、階層的な次元（時間、地理、商品）上のありとあらゆる集計をあらかじめ計算しておき、クエリを計算ではなく検索にする、というものでした。

これは機能しましたが、2つの残酷な代償がありました。1つ目、ビルドに何時間もかかり、データは常に昨日のままでした。2つ目、より厄介な方：キューブは設計時に想定された問いにしか答えられませんでした。アナリストが誰も予想していなかった2つの次元を掛け合わせたくなったら、キューブを設計し直して再ビルドする必要がありました。新しい問いに答えるのに何週間もかかるのです。

キューブが死んだ理由

移行は漸進的に起きました。Sybase IQが1994年にカラム型エンジンを出荷し、C-Storeの著者たちが作ったVerticaが2007年に商用化され、GoogleがDremel論文（BigQueryの基礎）を2010年に発表し、ClickHouseが2016年にオープンソース化されました。

2010年代後半に決定的なことが起きました。かつてキューブで事前集計しなければ得られなかったレイテンシが、生データのまま得られるようになったのです。その時点でキューブ層は利益ではなくなり、純粋な摩擦になりました。すべてのコスト（遅いビルド、硬さ、運用すべきシステムがもう1つ増えること）が見返りなしに支払われるだけになりました。

キューブは完全には消えていません：Essbase、Microsoft Analysis Services、Excel PowerPivotのMDXは大企業で生き続けています。しかし新しいプロジェクトに対する答えはカラム型エンジンであり、必要な場合の事前集計は、インクリメンタルに計算され通常のテーブルのようにクエリされるマテリアライズドビューで処理されます。

キューブに一切触れないのにこれがなぜ重要か、私の意見：OLAPについて調べると、MOLAPパラダイムを当然とする資料が大量に見つかります。MDX、次元、ビルドについて語り、あなたを2003年のメンタルモデルでシステムを設計するよう導きます。この分類は主に教科書と認定試験に生き残っています。これらの概念は歴史として受け取り、ガイドとしてではないようにしてください。

生き残った語彙

キューブは死にましたが、分析クエリを語る言語は変わっていません。現代のSQLに翻訳すると：

ロールアップ（集計レベルを上げる）：日次売上から月次へ。

SELECT toStartOfMonth(fecha) AS mes, sum(importe) AS ingresos
FROM ventas GROUP BY mes ORDER BY mes;

ドリルダウン（明細に降りる）：月からその月の日々へ。

SELECT fecha, sum(importe) AS ingresos
FROM ventas WHERE toStartOfMonth(fecha) = '2026-07-01'
GROUP BY fecha ORDER BY fecha;

スライス（1つの次元を固定値で切る）：スペインだけ。

SELECT fecha, sum(importe) FROM ventas WHERE pais = 'ES' GROUP BY fecha;

ダイス（複数フィルタのサブキューブ）：スペインとメキシコ、特定カテゴリ、四半期。

SELECT pais, categoria, sum(importe)
FROM ventas
WHERE pais IN ('ES','MX') AND categoria = 'hardware'
  AND fecha BETWEEN '2026-04-01' AND '2026-06-30'
GROUP BY pais, categoria;

ピボット（行をカラムに回転）：現代のOLAPでは条件関数です。

SELECT
    toStartOfMonth(fecha)         AS mes,
    sumIf(importe, pais = 'ES')   AS espana,
    sumIf(importe, pais = 'MX')   AS mexico,
    sumIf(importe, pais = 'AR')   AS argentina
FROM ventas GROUP BY mes ORDER BY mes;

90年代には専用サーバーと専用言語を必要とした5つの概念が、今日では5つのSQLクエリです。

スタースキーマ：OLAPデータのモデリング方法

アナリティクスで支配的な論理モデルはスタースキーマです。中央に1つのファクトテーブル、周りをディメンションテーブルが囲みます。

ファクトテーブルは測定可能なイベントを格納し、行が多くカラムは少ないです：1つの売上、1つのクリック、1つのセンサー読み取り。ディメンションテーブルは記述的なコンテキストを格納します：その顧客は誰か、その商品のカテゴリは何か、その店舗はどの地域にあるか。

-- ファクトテーブル：際限なく成長する
CREATE TABLE hechos_ventas (
    fecha       Date,
    producto_id UInt32,
    cliente_id  UInt32,
    tienda_id   UInt16,
    unidades    UInt32,
    importe     Decimal(12, 2)
) ENGINE = MergeTree
ORDER BY (tienda_id, fecha, producto_id);

-- ディメンション：小さく安定
CREATE TABLE dim_producto (
    producto_id UInt32,
    nombre      String,
    categoria   LowCardinality(String),
    marca       LowCardinality(String)
) ENGINE = MergeTree ORDER BY producto_id;

ここに理論と実践を分けるニュアンスがあります。クラシックなデータウェアハウスでは、スタースキーマは教義です。現代のカラム型OLAPエンジンでは、非正規化してcategoriaやmarcaを直接ファクトテーブルに入れる方が良いことが多いです。異端に聞こえます（データを複製しているのですから）が、そうしたカラムはLowCardinalityで劇的に圧縮されるため、ストレージコストはほぼゼロで、クエリごとのJOINを節約できます。

私のルール：ほとんど変わらないもの（商品カテゴリ、店舗の国）は最初から非正規化し、よく変わるものや大きいものは別ディメンションとして残す。

実SQLでの実践ユースケース

ここからOLAPは理論でなくなります。これが現実に遭遇するパターンです。

1. プロダクトアナリティクス：コンバージョンファネル

プロダクトで最も一般的なケース。ページビューからサインアップ、そして購入へと進む人がどれくらいいて、どこで離脱するかを知りたい。

標準SQLではCTEと自己結合の悪夢です。現代のOLAPエンジンでは関数1つです。

SELECT nivel, count() AS usuarios
FROM (
    SELECT
        usuario_id,
        windowFunnel(86400)(
            timestamp,
            evento = 'pageview',
            evento = 'signup',
            evento = 'purchase'
        ) AS nivel
    FROM eventos
    WHERE fecha >= today() - 30
    GROUP BY usuario_id
)
GROUP BY nivel
ORDER BY nivel;

windowFunnel(86400)は24時間のウィンドウ内で各ユーザーが連続して何ステップ完了したかを数えます。結果は直接ファネルの形を与えてくれます。

なぜここでOLAPが必要か： このクエリは1か月分の全ユーザーの全イベントに触ります。数千万行のPostgresでは、本番DBを倒すシーケンシャルスキャンになります。

2. オブザーバビリティ：ログ、メトリクス、トレース

ログはOLAPの代表例ですが、Elasticsearchと結びつけて考えているため多くの人が気づきません。タイムスタンプ付きイベントで、大量に書かれ、集計で読まれ、ほとんど更新されません。

SELECT
    toStartOfMinute(timestamp)                    AS minuto,
    servicio,
    count()                                       AS total,
    countIf(nivel = 'ERROR')                      AS errores,
    round(countIf(nivel = 'ERROR') / count(), 4)  AS tasa_error,
    quantile(0.95)(duracion_ms)                   AS p95,
    quantile(0.99)(duracion_ms)                   AS p99
FROM logs
WHERE timestamp >= now() - INTERVAL 3 HOUR
GROUP BY minuto, servicio
HAVING tasa_error > 0.01
ORDER BY minuto DESC;

パーセンタイル、エラー率、分別集計を1パスで。TTLを追加して90日以上のデータを自動削除すれば、完全なオブザーバビリティプラットフォームになります。

私の計算を変えた経済的なメモ： SaaSのオブザーバビリティソリューションからセルフホストのOLAPデータベースへログを移行することは、小さなプロジェクトで利用可能な最大のコスト削減の一つです。ログプラットフォームの価格は取り込み量で計算され、ログの量は増える一方です。

3. EコマースとBIのダッシュボード

クラシックなケース：複数のディメンションで集計されたビジネス指標。

SELECT
    toStartOfWeek(fecha)                       AS semana,
    categoria,
    sum(importe)                               AS ingresos,
    count()                                    AS pedidos,
    uniq(cliente_id)                           AS clientes,
    round(sum(importe) / count(), 2)           AS ticket_medio,
    round(sum(importe) / uniq(cliente_id), 2)  AS ingreso_por_cliente
FROM hechos_ventas
WHERE fecha >= today() - 180
GROUP BY semana, categoria
ORDER BY semana DESC, ingresos DESC;

uniq()に注目してください。HyperLogLogを使って近似でDISTINCTカウントし、典型的な誤差は1%未満、uniqExact()に比べてメモリ消費は無茶苦茶小さくなります。ビジネスダッシュボードにはこの近似で十分であり、パフォーマンス差は巨大です。

4. 時系列とIoT

センサー、インフラのメトリクス、市場価格。高頻度で届き、より低い解像度でクエリされるデータ。

SELECT
    toStartOfFifteenMinutes(timestamp)  AS intervalo,
    sensor_id,
    round(avg(temperatura), 2)          AS media,
    min(temperatura)                    AS minima,
    max(temperatura)                    AS maxima,
    count()                             AS lecturas
FROM metricas_sensores
WHERE timestamp >= now() - INTERVAL 7 DAY
  AND sensor_id IN (101, 102, 103)
GROUP BY intervalo, sensor_id
ORDER BY intervalo;

これを持続可能にするパターンは解像度の段階的削減です。1秒単位の読み取りを1週間、1時間単位を1年、1日単位を無期限に保存します。集計TTLを使えば自動化できます。

5. ユーザー向けアナリティクス（組み込みアナリティクス）

最も要求の厳しいケース。3人が見る社内ダッシュボードではなく、あなたのプロダクトの中の「統計」タブを、すべての顧客が同時にクエリするのです。

SELECT
    toDate(timestamp)     AS dia,
    count()               AS visitas,
    uniq(visitante_id)    AS visitantes,
    countIf(rebote)       AS rebotes
FROM eventos_web
WHERE tenant_id = {tenant:UInt32}      -- 常にORDER BYの最初に！
  AND timestamp >= {desde:DateTime}
GROUP BY dia
ORDER BY dia;

ここで設計の鍵は、tenant_idをソートキーの最初のカラムにすることです。そうすれば各顧客は自分のデータだけをスキャンし、テーブルが全顧客の数十億行になってもレイテンシはミリ秒に保たれます。スケールする機能と、顧客が100人になったら倒れる機能の違いです。

6. リテンションとコホート分析

ある月に登録したユーザーが、何か月後もアクティブか。

SELECT
    cohorte,
    mes_relativo,
    uniq(usuario_id) AS usuarios
FROM (
    SELECT
        usuario_id,
        fecha,
        toStartOfMonth(min(fecha) OVER (PARTITION BY usuario_id)) AS cohorte,
        dateDiff('month', cohorte, toStartOfMonth(fecha))         AS mes_relativo
    FROM eventos
)
GROUP BY cohorte, mes_relativo
ORDER BY cohorte, mes_relativo;

OVERをどこに置くか注意してください。min(fecha)に密着させ、toStartOfMonth()の内側に入れる必要があります。toStartOfMonth(min(fecha)) OVER (...)と書くと、ClickHouseはtoStartOfMonthがウィンドウ関数だと解釈し、Aggregate function with name 'toStartOfMonth' does not existで失敗します。

この種のクエリ（テーブル全体へのウィンドウ）こそ、トランザクショナルDBを沈め、カラム型が数秒で解決するものです。

2026年の主要OLAPベンダー

市場はかなり明確に5つのカテゴリに分かれます。シェア順ではなく、実プロジェクトへのフィット順に並べています。

リアルタイムOLAPエンジン（オープンソース）

サブ秒のレイテンシ、連続インジェスト、ライブダッシュボードと組み込みアナリティクス向け。

ClickHouseはこのカテゴリの参照点です。カラム型、単一バイナリ、Apache 2.0ライセンス、ノートPCから数百ノードまでスケール。セルフホストのデフォルト選択肢で、独自のマネージドサービス（ClickHouse Cloud）もあります。詳細は**ClickHouseの完全ガイド**をご覧ください。

Apache Druidは長年、大規模なリアルタイム時系列分析を行ってきました。Kafkaからのインジェストに非常に強力ですが、運用コストが高いです：6種類のプロセスにZooKeeper。

Apache PinotはLinkedInで生まれ、数億ユーザーにアナリティクスを提供するために作られました。非常に高い同時実行で最小レイテンシを実現するよう最も特化して設計されており、同じく運用複雑さが難点です。

StarRocksとApache Dorisは近い親戚で、カラム型MPPとClickHouseより強いJOINオプティマイザを持ちます。スキーマが正規化されたウェアハウスなら良い選択です。

マネージドクラウドデータウェアハウス

運用ゼロ、事実上無制限のスケール、従量課金。

Snowflakeはコンピュートとストレージの分離を普及させ、エンタープライズ層を支配しています。データガバナンスと権限で非常に成熟しています。ウェアハウスのコンピュート時間で課金されます。

Google BigQueryは真のサーバレスです：クラスタを管理せず、SQLを書きます。主にスキャンしたデータ量で課金され、書き方が悪いクエリは高くつきます。

Amazon RedshiftはAWSエコシステムの選択肢です。より古く、手動チューニングが多く必要ですが、Amazonの他サービスとネイティブに統合されます。

Databricks SQLはレイクハウスアーキテクチャの参照実装で、データエンジニアリング、機械学習、アナリティクスを同じストレージ上で統合します。非構造化データやAIパイプラインがある場合に強力です。

Azure SynapseはMicrosoftに既に深く入っている人向けのハイパースケーラートリオを完結させます。

このカテゴリに関する私の警告（比較記事からの繰り返しですが、ここでも relevant）：従量課金モデルは、インタラクティブアナリティクスのパターンをまさに罰します。小さく頻繁なクエリがたくさん。自動リフレッシュするダッシュボードが不釣り合いな請求を生むことがあります。予算が厳しいなら、変動する請求書は技術的リスクではなくビジネスリスクです。

組み込みエンジン

サーバーなし、プロセス内で動きます。

DuckDBはアナリティクス版SQLiteです：pip install duckdbでPostgreSQL互換方言のベクトル化カラム型エンジンが手に入ります。ParquetやCSVを直接読みます。1台のマシンに収まるデータセットには、シンプルさで敵なしです。MotherDuckがそのクラウド層です。

chDBはPythonに組み込まれたClickHouseエンジンで、pandas風のAPIを持ちます。

特化型

**kdb+**は高頻度トレードを支配しています。時系列で極めて高速、独自言語（q）と、ニーズに見合った価格を持ちます。

QuestDBはオープンソースで、拡張SQLによる時系列指向です。

TimescaleDB（2025年に社名をTigerDataに変更した企業のもの。ただしオープンソース拡張はTimescaleDBの名を維持）はPostgreSQLを時系列データベースに変えます。既にPostgresを使っており、データ量が中規模なら、最も摩擦の少ない移行です。

FireboltとSingleStoreはクラウド管理の高性能ニッチで競合します。

データレイク上のクエリエンジン

Trino（旧PrestoSQL）とApache Spark SQLは、オブジェクトストレージ上のApache Iceberg、Delta Lake、Parquetのようなオープンフォーマットに存在するデータをクエリします。データベースではなく、ファイルの上にSQLを置くエンジンです。

このカテゴリは「データレイク」と「OLAPデータベース」の境界を曖昧にしています。多くのカラム型エンジン（ClickHouseを含む）はIcebergやParquetを直接読めるため、何も取り込まずにレイクをクエリできます。

その上のレイヤー

OLAPは処理 layer であり、表示 layer ではないことに触れておく価値があります。Tableau、Looker、Power BI、Metabase、GrafanaはBIツールで、背後でクエリを実行するためにOLAPデータベースに接続します。データベースが速度と構造を、BIがインターフェイスを提供します。

選び方：4つの問いでの私の基準

実務的な意思決定に翻訳します。

データが1台のマシンに収まる（例：数百GB未満）？ DuckDBから始めましょう。運用ゼロ、優れたパフォーマンス、馴染みのあるSQL。最も多くの人が無視し、最も多くの場合に正しい推奨です。

連続書き込みと複数リーダーを持つ共有サービスが必要？ ClickHouse。今日存在するパフォーマンスと運用複雑さの最良のバランス点で、控えめなVPSで動きます。

既にPostgreSQLを使っており、中規模？ TimescaleDB。新サービスではなく拡張を追加します。退屈な選択肢が大抵は正解です。

チーム、予算、インフラゼロを優先？ Snowflake、BigQuery、またはDatabricks。初日からコストアラートを設定しましょう。

そしてすべてに先行する問い：本当にOLAPが必要か？ 最大のテーブルが200万行で、Postgresでクエリが200msなら、答えはノーです。分析システムを追加するとは、維持・バックアップ・監視するサービスを追加することです。その瞬間が来たというシグナルは具体的です：プロダクトの中核となる集計が5秒以上かかり、既にインデックスを試した場合。

なぜこれが見た目以上に重要か、という考察

長年、私は「OLAP」を銀行でキューブを扱う人々のための企業ジャーゴンだと思っていました。開発者の間に広がっている偏見であり、私はそれで高い代償を払いました。

私の認識を変えたのは、ほぼすべてのデジタルプロダクトがイベントデータを生成し、そのほとんどが活用されていないという気づきでした。デフォルトのインフラ（リレーショナルデータベース）がクエリを苦痛にするからです。なので捨てられるか、誰も触れないテーブルに保存されるか、持てるものの10%しか返さないアナリティクスSaaSに支払われるか。

OLAPデータベースの導入は、測れるものを変えませんでした。問いを投げる頻度を変えたのです。クエリが40秒かかるとき、1セッションで2つの仮説を探ります。300ミリ秒のときは20個を探ります。そしてその頻度の差こそが、探していなかった発見を生み出します。

これがOLAPを支持する本当の議論であり、どのベンチマークにも出てきません：クエリが速くなるのではなく、もっと多くの問いを投げるようになるのです。