LASSIC Media らしくメディア

見積もりや請求データを分析基盤に集め、集計や粗利計算を高速に回したいという要望は、システム開発の発注担当者やプロジェクトマネージャーからよく聞かれます。ところが同じ「データベース」という言葉でも、業務アプリで使う仕組みと、大量データの集計に向く仕組みでは、データの持ち方そのものが違うのです。開発会社から「列指向データベースを使いましょう」と提案されても、何がどう違うのかが分からなければ、その提案が自社の要件に合っているかを判断できません。

本記事では、データの格納方式としての「行指向」と「列指向」の違いに絞り、なぜ列指向が集計・分析処理で速く動くのかを整理します。OLTPとOLAPの一般的な違いや、特定の分析基盤製品の選定・導入は範囲外とし、別記事に譲ります。発注やレビューの場面で製品説明を読み解く土台として役立ててください。読み終える頃には、提案書に出てくる「列指向」という言葉の意味と、確認すべき論点が見えているはずです。

列指向データベースとは

列指向データベースとは、表のデータを行ごとではなく列ごとにまとめて格納することで、大量データの集計・分析を速く処理できるようにしたデータベースです。

行指向データベースは、1件分のデータ（1行）をひとまとまりにして近い場所へ格納する方式です^*1。対して列指向データベースは、同じ列の値どうしをまとめて連続した領域に置く方式で、格納の「向き」が行と列で入れ替わっている、と捉えると分かりやすいでしょう。

どちらも表形式のデータを扱う点は同じです。違うのは、ディスクやファイル上でデータを並べる順番だけであり、この並べ方の違いが、後述する処理速度の差を生む出発点になります。

たとえば「ID・名前・金額」という3列の受注データを例に考えてみましょう。行指向であれば、1件目の「ID・名前・金額」がひとまとまりで置かれ、続けて2件目、3件目が並びます。列指向であれば、まずID列の値がまとまり、続けて名前列、金額列という順に並ぶのです。次の章の図で、この並び方の違いを具体的に確認していきます。

この違いは、最近生まれた新しい発想ではありません。表の値をどちらの向きで並べるかという考え方自体は、以前から研究・実装されてきたものです。データウェアハウスのように、大量データの集計処理に適した仕組みとして位置づけられています^*1。行数や列数が少ないうちは、この違いをほとんど体感できません。データ量が増えるにつれ、格納方式の違いが処理時間の差として、はっきり表面化していきます。

身近な例で言うと、会員情報や注文情報を保存する業務システムの土台には、行指向のリレーショナルデータベースが使われている場面が目立ちます。一方、集計・分析に特化したデータウェアハウスやBIツールの裏側では、列指向の仕組みが採用されている場面が少なくありません^*1。

行指向と列指向、格納方式の違い

行指向と列指向は、それぞれ得意な操作と向く用途が異なります^*1*2。まずは対比を一覧で見てみましょう。

表のとおり、行指向は「1件を素早く」、列指向は「特定の列を大量に」という、狙いの異なる設計です。「注文ID123の明細を見せてほしい」という業務画面の要求と、「今月の金額列を合計してほしい」という集計の要求を比べてみましょう。読み書きしたいデータの形そのものが、根本から違うと分かります。

行指向データベースで集計をしようとすると、1行ずつ全列を読み込んでから、必要な列だけを取り出す処理になりがちです。行数が増えるほど、この「不要な列まで読み込む」負荷が積み重なり、応答が遅くなっていきます^*1。会員テーブルに数十項目の属性が並んでいても、集計処理が使うのはそのうちの一部という状況は珍しくないでしょう。

行指向のデータベースでは、特定の行を素早く見つけるために主キーやインデックス（検索を速くするための索引）を使うのが一般的です^*2。列指向のデータベースでは、行を1件ずつ探すのではなく、列のブロックごと絞り込むことで、似た役割を別の形で果たしていると捉えられます。

在庫管理システムを例にすると、「商品コード・在庫数・入荷予定日」など数十項目を持つ在庫テーブルから、在庫数の合計だけを知りたい場面があります。行指向のままでは、他の数十項目も一緒に読み込むことになり、知りたい値に対して読み込む量が過剰になりがちです。次の章では、なぜ列指向がこの集計処理で速く動くのかを詳しく見ていきます。

列指向で分析が速くなる理由

集計処理の多くは、表の全列ではなく一部の列だけを大量の行にわたって読み込みます^*3。この性質に列指向の格納方式を重ねると、なぜ速くなるのかが見えてきます。下図は、同じ表を行指向と列指向でそれぞれ格納したときの並び方の違いを示したものです。

ここでいう「ブロック」とは、ディスクやメモリがデータを読み書きする際のひとまとまりの単位を指します^*2。列指向では、同じ列の値だけをブロックへ集めて置くため、集計に使わない列のブロックにはそもそも触れずに済むのです。

行指向では1行分の値が連続して並ぶため、特定の列だけを取り出すにも、行ごとに他の列の値を読み飛ばす必要があります^*2。列指向では同じ列の値が連続して並ぶため、必要な列のブロックだけを読めば済み、無駄な読み込みが減ります。

Amazon Redshiftの公式ドキュメントでは、100列の表から5列だけを使う集計クエリを例に挙げています^*2。この場合、列指向であれば表全体のおよそ5パーセント程度のデータを読むだけで済むと説明されているのです。行指向であれば、使わない95列分のブロックまで読み込むことになる、という対比になります。この差を一覧にすると、次のとおりです。

ディスクから読み込む量が減れば、その分だけメモリに載せるデータ量も減ります^*2。読み込みと展開の両方が軽くなることが、集計クエリの応答時間を縮める土台になっているのです。

もう一つの理由が圧縮です。列の中には同じ種類・似た値が並びやすいため、列単位でまとめて圧縮する方式と相性が良く、ディスク容量と読み込み量の両方を抑えられます^*1*4。Google Cloudの公式ドキュメントでも、列の中は行全体より値の重複が多いため、繰り返しをまとめて表現する符号化方式で圧縮しやすいと説明されています^*3。

Apache Parquetのような列指向ファイル形式でも、この圧縮効率の高さが採用理由の一つに挙げられています^*4。数十億件規模の行を扱うデータウェアハウスでは、読み込み量と圧縮率の差が、集計クエリの体感速度に直結しやすいと言えるでしょう。

たとえば「契約ステータス」のように、値の種類が「契約中・解約済み・休止中」の数種類に限られる列を考えてみましょう。同じ値が連続して並びやすいため、値そのものではなく「同じ値が何件続くか」という情報に置き換えて表す圧縮方式と相性が良くなります。結果として、ディスク容量を効率よく抑えられるのです^*3。名前や住所のように値がばらつきやすい列に比べ、種類の少ない列ほど圧縮効果が出やすい傾向があります。

実務のテーブルには、空欄（NULL、値が未入力の状態を指す）の項目を含む列も少なくありません。列指向では、そうした欠損の多い列もまとめて圧縮しやすいため、無駄な領域を抑えやすい特性があります^*1。

タイムスタンプのように順序よく増えていく値も、列指向では圧縮や絞り込みと相性が良い列の代表例です^*4。ログ分析基盤で列指向の仕組みがよく採用されている理由の一つは、この特性にあると考えられます。

ここまで見てきた「読み込む量を減らす」ことと「値をまとめて圧縮しやすくする」ことは、別々の工夫ではなく、同じ列指向という格納方式から生まれる、表裏一体の効果だと捉えるとよいでしょう。

列指向が不向きな場面

1件のデータをまとめて追加・更新・削除する業務処理では、列指向は分が悪くなります。1件の値が複数列に分かれて格納されているため、1件を書き込むたびに複数の列ブロックへ分散して書き込む必要が生じるのです^*2。

受発注システムや会員管理のように、1件単位の登録・更新が頻繁に発生する業務処理（OLTP）では、行指向のほうが同じ処理を軽く済ませられます^*2。列指向データベースを分析用途以外に無理に当てはめると、書き込みの遅さが業務全体のボトルネックになりかねません。

たとえば、ECサイトの受注画面から新しい注文を1件登録する処理を考えてみましょう。行指向であれば、その1件分の値を1か所にまとめて書き込めば完了します。列指向で同じことをすると、ID・名前・金額といった値がそれぞれ別の列ブロックへ振り分けられ、書き込み先が複数箇所に分かれてしまうのです。

同様に、登録済みの注文金額を1件だけ修正する更新処理でも、該当する列のブロックを探して書き換える手間が生じます。行指向であれば、該当する行のレコードを見つけて書き換えるだけで完結するでしょう。

会員データを一括更新するようなバッチ処理でも、事情は同じです。列指向では更新対象の値が複数の列ブロックにまたがって分散するため、行指向に比べて書き換えの手間が増えやすくなります。1件単位・大量件数を問わず、追加や更新が主な処理であるほど、行指向の設計が向いていると言えるでしょう。

逆に、今日入ってきたログをまとめて追記するだけで、あとは読み取るだけというデータもあります。このように追記が中心で更新がほとんど発生しない場合、列指向でも書き込みの負担は目立ちにくくなるでしょう。書き込みパターンの中身まで見て判断することが欠かせません。

この特性を踏まえると、列指向と行指向は優劣ではなく、処理内容に応じた使い分けの関係にあると言えるでしょう。実務では、業務処理は行指向データベースで受け止め、そこから分析用の列指向データベースへ定期的にデータを転送する構成がよく採られています^*1。この組み合わせ方については、次の章でもう少し詳しく見ていきます。

列指向データベースの主な用途

列指向データベースは、大量データの集計・分析を継続的に行う基盤で採用されてきました^*1。代表的な用途を挙げます。

• データウェアハウス：複数の業務システムから集めたデータを蓄積し、部門横断の集計に使います。経営会議向けの月次集計などが典型例です。
• BI・分析基盤：ダッシュボードやレポート作成のための集計クエリを速く処理します^*3。日次・週次で更新される定型レポートとの相性が良い領域です。
• ログ分析：アクセスログや操作ログなど、時系列で積み上がる大量データの集計に向きます^*4。特定期間・特定項目だけを絞り込んで集計する用途に合っています。

これらの用途に共通するのは、業務システムで発生したデータをいったん行指向のデータベースで受け止める点です。そのうえで、集計向けの列指向データベースへ取り込むという流れをとります。業務処理と分析処理を同じデータベースで無理に両立させるのではなく、役割の異なる2種類のデータベースを組み合わせる構成が実務では珍しくありません。

この橋渡しの処理は、一般にETL（データを抽出・変換し、分析用データベースへ格納する処理）やELTと呼ばれています。取り込みの頻度は日次バッチのこともあれば、より短い間隔で反映する構成のこともあり、業務要件に応じて設計が変わってくるのです。

経営会議向けの月次集計であれば日次の取り込みで足りることが多い一方、日々の売上状況をこまめに追いたい場合は、より短い間隔での取り込みが求められます。求める鮮度に応じて、必要な仕組みの複雑さも変わってくると考えておくとよいでしょう。

なお、どの製品を選び、どう導入するかは、要件やデータ量によって判断が変わる別テーマです。本記事では格納方式の理解にとどめ、個別製品の選定・導入の検討は別記事に譲ります。

発注・レビューで確認する点

列指向データベースそのものを一から作る場面は少なく、既存の分析基盤製品を選び、使い方を整える形が実務の中心と言えるでしょう。発注やレビューの段階で押さえておきたい観点を4つ挙げます。

分析用途か業務処理用途かを見極める

提案されているデータベースが、集計・分析を目的としているのか、業務処理（受発注・会員管理等）を目的としているのかを、まず切り分けましょう。目的が曖昧なまま列指向製品を選ぶと、想定外の書き込み負荷を招くことがあります。

提案書やRFP（提案依頼書）の回答に「集計処理」「分析基盤」といった言葉が出てきた場合は、その処理が列指向を検討する対象になっているかを確認する目印になります。逆に「受発注」「会員登録」といった業務処理に列指向を当てはめる提案が出てきたときは、その根拠を尋ねてみるとよいでしょう。

本記事の冒頭で挙げた、見積もりや請求データの集計を高速に回したいという要望も、この分析用途に当てはまるケースといえるでしょう。まずは、その処理が「集計・分析」と「業務処理」のどちらに当たるのかを言語化してみることが、最初の一歩になります。

判断に迷う場合は、本番導入の前に、実データに近いサンプルで集計クエリの応答時間を検証しておくとよいでしょう。想定した速さが実際に出るかを事前に確かめられ、導入後の手戻りを避けやすくなります。

更新頻度を確認する

データが1件ずつ頻繁に更新されるのか、まとまった単位でバッチ的に取り込まれるのかで、向く格納方式は変わります。更新の頻度と単位を具体的に確認し、列指向製品の得意な取り込み方式と合っているかを照らし合わせることが大切です。

既存の行指向データベースとの役割分担を設計する

業務システムの行指向データベースと、分析用の列指向データベースを併用する構成は珍しくありません。どちらのデータをいつ・どう連携させるか、役割分担をあらかじめ設計しておくと、後工程での手戻りを抑えられます。

連携の頻度（毎日なのか、リアルタイムに近い頻度なのか）や、連携が止まった場合の業務影響も、あわせて確認しておきたい点です。分析用データベースへの反映が遅れても業務が止まらない設計かどうかで、必要な連携方式の複雑さが変わってきます。どちらのデータベースが「正」の情報を持つのかを、あらかじめ明確にしておくことも欠かせません。

運用コストと管理体制を確認する

列指向の分析基盤は、扱うデータ量やクエリの実行量に応じて費用が変わる仕組みを採る製品が少なくありません。導入前に、想定するデータ量・クエリ頻度でどの程度の費用感になるかを見積もり、誰が運用・監視を担うのかも決めておくと、稼働後の想定外を減らせます。

データ量が増えるにつれて費用も比例して増えていく仕組みが多いため、将来のデータ量の伸びをどこまで見込むかによって、選ぶべき構成も変わってきます。契約前に、データ量の伸びに応じた費用の変化を開発会社へ確認しておくと判断しやすくなるでしょう。

4つの観点はいずれも、列指向データベース単体の技術評価ではなく、既存の業務システムとの関係性を含めた設計判断です。提案を受けた際は、この4点に沿って開発会社へ質問を投げかけると、論点の抜け漏れを防ぎやすくなるでしょう。

まとめ

• 列指向データベースは、列の値をまとめて連続格納することで集計・分析を速くする仕組みである。
• 行指向は1件単位の読み書きに向き、列指向は特定の列を大量に読む集計に向く。
• 列単位の連続配置により無駄な読み込みが減り、同種の値が並ぶため圧縮効率も高まる。
• 更新の多い業務処理には不向きで、行指向データベースとの役割分担が前提になる。
• 実務では行指向で業務処理を受け止め、列指向へ定期的にデータを取り込む構成が多く採られている。
• 導入検討では、分析用途か業務用途か、更新頻度、既存データベースとの役割分担、運用コストを確認する。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Wikipedia日本語版「列指向データベース」
• Amazon Web Services「Amazon Redshift Database Developer Guide – Columnar storage」
• Google Cloud「BigQuery storage overview」
• Apache Parquet「Overview」

Tweet