データ基盤

OLTPとOLAPを、なぜ別々のデータベースで動かすのか

2026/10/3 シリーズ「データ基盤はなぜ作り直されてきたか」 第1回 / 全2回

🤖 AIが執筆しています

業務の処理と分析は、一回に触るデータの量が桁で違う

データベースの分野では、業務の処理を OLTP（オンライントランザクション処理）、分析を OLAP（オンライン分析処理）と呼ぶ。トランザクションは、注文の登録のように、まとめて成功するか、まとめて取り消すかのどちらかになる一連の読み書きを指す。

Chaudhuri と Dayal の 1997 年の解説論文は、二つの仕事の違いを次のように書く¹。OLTP のトランザクションは、数十行のレコードを、多くの場合は主キーで探して読み書きする。主キーは、表の各行を一つに特定する列である。OLTP で重視する性能は、単位時間に終えたトランザクションの数（スループット）である。これに対して、OLAP の問い合わせは数百万行のレコードを読み、表全体の走査・結合・集計を多く行う。OLAP で重視する性能は、問い合わせの応答時間と、単位時間にこなす問い合わせの数である。

データベースの性能を比べる業界団体の TPC は、二つの仕事を別々のベンチマークとして定義している。OLTP のベンチマークである TPC-C では、注文の登録（New-Order）一件が平均 10 品目の注文明細を扱い、各種類のトランザクションの 90% 以上が 5 秒未満（在庫確認だけは 20 秒未満）で終わることを求める²。分析のベンチマークである TPC-H は、対象を「大量のデータを調べる」意思決定支援のシステムと定め、その問い合わせは「ほとんどの OLTP トランザクションよりはるかに複雑」だと書く³。

Stonebraker と Çetintemel は 2005 年の論文で、二つの仕事に向くデータの持ち方も違うと述べた⁴。業務用のデータベースは一行の全項目をまとめて書けるように行単位で保存する。分析用のデータベースは、少数の列を大量の行について集計する問い合わせに向けて、読みやすい形で保存する。二人は同じ論文で、分析の仕事には列単位で保存する形（列指向）が大きな性能の利点を持つと述べている。

同じデータベースで集計を動かすと、業務の処理が影響を受ける経路が三つある

Stonebraker と Çetintemel によれば、大企業のシステム管理者は、分析をする利用者を業務用のシステムに入れることをためらってきた⁴。複雑な分析の問い合わせが、業務の画面を使う利用者の応答時間を悪化させると考えたからである。分析が業務の処理に影響する経路を、データベースの開発者と研究者の文書で確かめると、少なくとも三つある。

一つ目の経路は、CPU と実行の順番の奪い合いである。SAP と大学の研究者は 2014 年に、OLTP と OLAP を同じシステムで動かす性能測定（CH-benCHmark）で、二つのシステムを測った⁵。データ量は約 7 GB で、分析の利用者の数を 1 から 128 まで倍々に増やした。SAP HANA の既定の設定では、分析の利用者を増やすほど OLTP のスループットが下がり、分析の利用者が 128 になって計算資源が飽和すると、OLTP のスループットはほぼゼロになった。著者らは原因を、長く走る分析の処理が計算資源を長時間占め、次々に届く短い OLTP の処理に空きを残さないことだと説明している。この論文は、法的な理由で絶対値を公開せず、相対値だけを示している。

二つ目の経路は、キャッシュの追い出しである。PostgreSQL の開発者は、ソースコードに添えた設計の文書で、大きな表を一度だけ順に読む処理について書いている⁶。通常の規則でキャッシュを入れ替えると、その読み込みが「キャッシュ全体を吹き飛ばす」。PostgreSQL は、これを避けるために、順に読む処理には 256 KB の小さな専用領域だけを使わせる。MySQL の InnoDB も、表全体を読む処理が頻繁に使うページを押し出さないように、新しく読んだページをキャッシュの順番の途中に入れる⁷。どちらの対策も既定で入っている。キャッシュの経路は、対策の無い単純な方式で起きる危険であり、現在の主なデータベースは既定でその一部を防いでいる。

三つ目の経路は、古い版のデータの保持である。多くのデータベースは MVCC（多版型同時実行制御）という方式で、書き換えた行の古い版をしばらく残し、読み始めた時点の状態を読む処理に見せる。MySQL のマニュアルは、読むだけのトランザクションでも定期的に終わらせるよう勧めている⁸。長い読み込みが続くあいだは古い版を消せず、業務用のデータベースで古い版を置く領域が大きくなり続け、その領域を使い切るおそれがあるからである。この経路で文書が書いているのは、処理の遅れではなく領域の圧迫である。

実際の組織がこの危険をどう扱ったかの例として、オンライン学習サービスの Udemy の技術ブログがある⁹。Udemy は 2014 年 5 月に分析用のデータベース（Amazon Redshift）を立ち上げるまで、分析の処理をすべて本番の MySQL で動かしていた。ブログは、これが問題だった最大の理由を、一つの悪い問い合わせがサイトの性能を落とし、最悪の場合はサイトを止めうることだったと書く。ブログが書いているのは起こりうる危険であり、実際に起きた障害の記録ではない。

分析を別のコピーへ移すと、業務は守れるが、遅れと手間を払う

分析を業務用のデータベースから外す最も小さな手は、同じデータベースのコピー（リードレプリカ）を作り、そこで集計を動かすことである。PostgreSQL の文書は、この構成の制約を書いている¹⁰。コピー側で長い問い合わせを動かすと、元のデータベースが古い版を片付けた変更をコピーに反映するときに衝突が起き、問い合わせが取り消されることがある。古い版の片付けによる取り消しを防ぐ設定を有効にすると、今度は元のデータベースで古い版の片付けが遅れ、表が膨らむ。文書はこの状態を、元のデータベースで直接問い合わせを動かした場合より悪くはならない、と説明している。コピーで分析を動かすと CPU とキャッシュの負担はコピーに移るが、古い版の片付けを通じた影響は業務用のデータベースに残る。

分析を業務用とは別のデータベースへ完全に移すと、業務の処理の資源は守れる。その代わりに、分析が読むデータは業務用のデータより遅れる。TPC-H の仕様は、この遅れを許している。TPC-H のデータベースは、変更をまとめて取り込む更新処理によって、OLTP のデータベースの状態を「場合によっては遅れて」追いかける³。仕様は同じ節で、TPC-H のデータベースを「OLTP のアプリケーションが同時に走るデータベースではない」とも明記している。分析のベンチマークそのものが、分析用のデータベースを、業務用の状態を更新処理で追いかける別のデータベースとして定義している。

分けて持つ理由は、負荷だけではない。Chaudhuri と Dayal は、業務用のデータベースは現在の状態しか持たず、傾向をつかむのに必要な過去のデータや、複数のシステムにまたがるデータが欠けることを、もう一つの理由に挙げる¹。Uber の技術ブログは、2014 年より前の状態を、データが数個の OLTP のデータベース（MySQL と PostgreSQL）に分かれ、組み合わせるには利用者が自分でコードを書くしかなく、全体を見渡せなかったと書いている¹¹。

HTAP でも、業務への干渉を小さく抑えた設計は分析用のコピーを分けている

二つのデータベースを持つ形には、データの遅れと二重の運用という代償がある。この代償を嫌い、一つのシステムで OLTP と OLAP の両方を扱う設計を HTAP（ハイブリッドトランザクション・分析処理）と呼ぶ。SAP の共同創業者の Plattner は 2009 年の講演論文で、データウェアハウス（分析用に別に作るデータベース）の導入を妥協だったと書き、両方を一つのシステムで扱うことを望ましいと述べた¹²。SAP のデータベース製品である SAP HANA では、OLTP と OLAP が同じデータを対象にする⁵。Plattner 自身の試作システムでは、問い合わせを同時に動かすと、一件の挿入にかかる時間が大きく増えた。Plattner はこれを実装の問題と見ている。

HTAP を主張する設計のうち、測定が論文で公開されているものを比べると、OLTP への干渉の大きさは、分析をどこで実行するかで分かれる。

同じサーバーで両方を動かす二つの設計では、分析を増やすと OLTP のスループットが大きく落ちた。HyPer は、Kemper と Neumann が 2011 年に発表した、データをすべてメモリに置くデータベースである¹³。著者らは、複雑な分析の問い合わせを OLTP の待ち行列にそのまま入れると、後に続くすべての OLTP の処理がその完了を待つことになり、システムが詰まると書く。HyPer は、OS の機能で OLTP の状態を写したスナップショットを同じサーバーの上に作り、分析をそのスナップショットの上で動かす。前の節で挙げた 2014 年の測定では、スナップショットを作り直さない最も速い設定でも、分析の利用者が 128 になると HyPer の OLTP のスループットはほぼゼロになり、SAP HANA と同じ形を示した⁵。分析の利用者が 22 問ごとにスナップショットを作り直す設定では、分析の利用者を一つ加えただけで OLTP のスループットが約 30% 下がった。HyPer の 2011 年の論文自身も、8 コアのサーバー 1 台で分析の問い合わせの流れを 1 本から 8 本に増やすと、OLTP のスループットが毎秒約 12.7 万件から約 6.5 万件に下がった値を示している¹³。著者ら自身は、この値を、分析を動かし続けたままでも出せた OLTP の性能として評価している。

分析用のコピーを別のサーバーに置く二つの設計について、TiDB は OLTP のスループットの低下を、F1 Lightning は分析の CPU 時間を測っている。TiDB は、PingCAP が開発するデータベースである。2020 年の論文の要旨は、HTAP のデータベースは二つの種類の問い合わせを互いに干渉させないために、それぞれ専用のデータのコピーを持つ必要があると書く¹⁴。TiDB は、OLTP 用の行単位のコピーとは別に、分析用の列単位のコピーを別のサーバーに置くことができ、測定もその構成で行った。PingCAP の測定（CH-benCHmark、6 台のサーバー）では、分析の利用者を増やしても、OLTP のスループットの低下は最大 10% だった。同じ論文は、同じ 6 台のサーバーと同じデータ量の CH-benCHmark で、取引と分析の両方を扱う分散データベースの MemSQL 7.0 も測っている。HTAP のシステムで二つの仕事を隔てる問題を示すための比較で、分析の利用者を増やすと MemSQL の OLTP のスループットは 5 分の 1 以下に落ちた。論文は、TiDB の低下の小ささをこの MemSQL の結果と対比している。これらの数値は、いずれも TiDB の開発元である PingCAP 自身による測定である。

F1 Lightning は、Google が 2020 年に発表した仕組みで、業務用のデータベースの変更を取り込み、分析に向く列単位の別のコピーを作って最新に保つ¹⁵。Google は、本番の分析の問い合わせを、同じ時点のデータに対して業務用のデータベースと F1 Lightning の両方で動かし、CPU 時間を比べた。これも、Google が自社の仕組みについて行った測定である。データを読む側の CPU 時間は、業務用のデータベースで動かすと、問い合わせの規模によって F1 Lightning の 2.3 倍から 11.8 倍（中規模の問い合わせで最大）かかった。論文は、分析の問い合わせの多くは業務用のデータベースでも動かせるが、はるかに高い費用がかかると書いている。この比較は、同じ分析を業務用のデータベースで動かすと、その分の CPU を業務用の側で何倍も使うことを示す。

コピーを分けない方向も残っている。2014 年の測定の著者らは、同じシステムの中で OLTP と OLAP の処理を区別し、異なる優先度で実行する仕組みが必要だと結論した⁵。実際に SAP HANA で分析の並列実行を止める設定にすると、OLTP のスループットは既定の設定より上がった。ただし、この方向で干渉がどこまで小さくなるかは、同じ論文でも今後の課題とされている。

OLTP への干渉そのものを測った四つの設計の範囲では、低下が小さかったのは分析用のコピーを別のサーバーに置いた TiDB だった。コピーを分ける HTAP の設計が変えたのは、利用者から見た入口である。利用者は一つのシステムに問い合わせを投げ、システムがコピーの作成と同期を自動で行う。分析用のコピーを持つと決めると、次の問題は、複数の業務用データベースに散らばったデータを、どこへ、どの形で集めるかになる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。