DEIM Forum 2016 D3-6

列指向型データ格納 RDBMS を利用した分散 OLAP 問合せの処理最適化
塩井隆円†

波多野賢治††† 同志社大学大学院文化情報学研究科 〒 610–0394 京都府京田辺市多々羅都谷 1-3†† 同志社大学文化情報学部 〒 610–0394 京都府京田辺市多々羅都谷 1-3
E-mail: †shioi@ilab.doshish.ac.jp, ††khatano@mail.doshisha.ac.jp
あらまし

現在データ管理に利用されているデータベースシステムは，主に行指向型データ格納方式もしくは列指向型データ格納方式を採用している．しかし，高頻度に大量・複雑な非構造化データを短時間で格納・集計するビッグデータ解析の要求を満たすためには，これら二つのデータ格納方式を併用し，かつ負荷集中の問題を解決するために複数の計算機を利用した分散処理環境の元でデータベースシステムを運用する必要がある．本稿では，複数の計算機による分散処理環境として行指向/列指向双方のデータ格納方式をサポートする RDBMS の同期レプリケーションを利用した問合せ処理環境を構築し，効率的な問合せ処理のためのストレージ選択方式を提案する．評価実験の結果，提案手法は既存のストレージ選択条件と比較し，OLAP 問合せ処理速度を 5∼25%高速化することができた．
キーワード

OLAP, RDB, 列指向型ストレージ, 負荷分散

1. は じ め に散を行うことでシステムの信頼性（reliability）を保つことが一般的となっているため，コストベースのクエリプランの生成が近年，リアルタイムに蓄積する大量のセンサデータを分析

これまで以上に困難となる．そのため，二種類のストレージをし，企業の意思決定支援に利用するビッグデータ分析が注目運用する DBMS を用いる際に，OLAP 問合せに対しどちらのされている．特に，ビッグデータ解析のための情報システム

ストレージを用いて処理を行うかをルールベースで適切に処理

では Database Management System (以下，DBMS) としてする必要がある．

NoSQL 系 DBMS と Relational Database Management Sys-

そこで本稿では，二種類のストレージを運用する DBMS の

tem (以下，RDBMS) を採用することで，大量のセンサデータ

OLAP 問合せを効率的に実行するためにルールベースに基づく

格納と効果的なデータ解析を実現している．

ストレージ選択法を提案することで問合せ処理時間の高速化を

近年の DBMS では，高速なデータ分析のためにデータの参行う．具体的には，DBMS を複数ノードに同期レプリケーショ

照効率が高く，Online Analytical Processing (以下，OLAP)

ンし，ホットスタンバイによる負荷分散を行う分散処理環境の問合せを高速に実行できるとされている列指向型ストレージ

下で，問合せの種類に対して使用するストレージ選択基準を作を採用することが一般的となっている．しかしながら，列指成することで問合せ処理高速化につなげていく．

向型ストレージを採用した DBMS では Online Transactional

Processing (以下，OLTP) 問合せの実行に適さず，センサデー

2. 予 備 実 験

タに含まれるエラー修正のための更新処理がボトルネックとな

OLAP 問合せにおいては，テーブル内の特定の列データをり DBMS の作業負荷が高くなってしまうという問題点がある．

集計する処理が多く，行指向型ストレージでは処理に使用しなこうした問題点を解決するために C-store [4, 8] や Fractured

い列まで読み出してしまうため，列ごとにデータを格納する列

Mirrors [6] のような DBMS では，列指向型ストレージに加え指向型ストレージを利用することで効率良く問合せ処理が可て RDB で採用されている行指向型ストレージを一つの DBMS

能であるとされている．この点を考慮して，C-Store [4, 8] やで扱う事で，OLAP と OLTP 両方の問合せを効率的に処理しFractured Mirrors [6] では行指向型／列指向型ストレージを併ている [1, 2, 7]．

用し，問合せの種類に応じて使用するストレージを選択する条

しかし，ビッグデータを格納する場合には，分散処理環境を件を設定した上で問合せ処理を行っている．本節では，既存の構成することに加え，データテーブルのサイズがリアルタイム

行指向型／列指向型ストレージの選択基準が問合せ処理にどれに増加しつづけることや，列の値の幅が増加することが考えらほど影響を与えているかを評価する予備実験の結果を述べる．

れるため，既存のオプティマイザにおける OLAP 問合せにおい2. 1 実 験 環 境て，コストベースのクエリプランの生成に時間が掛かり，上手

予備実験に使用したデータは，米国トランザクション処理性能

く生成されたクエリプランも実行する時点には見積り通りの問

協議会 (Transaction Processing Performance Council: TPC)

合せ処理が可能であるとは言い難いのが現状である [3]．また，によって策定されたテストコレクションである TPC-H（注 1） で計算機の故障に備えて複数計算機を用いたレプリケーション

あり，それを行指向型／列指向型ストレージに格納した．本稿

によってシステムの可用性（availability）を高め，レプリケー
ションされた計算機に対してもホットスタンバイによる負荷分（注 1）：http://www.tpc.org/tpch/spec/tpch2.8.0.pdf

の実験では PostgreSQL 9.4.4 と PostgreSQL に列指向型スト比較を行ったところ，問合せ実行時間は図 3 の結果であった．

レージ機能を追加するための cstore fdw 1.3 を利用することで

ただし，C-Store [4, 8] や Fractured Mirrors [6] では以下のよ行指向型ストレージと列指向型ストレージの併用を実現していうなストレージの選択基準を設定した．

る．列指向型ストレージに格納するデータは図 1 のようにテー

C-Store: OLAP 問合せを処理する場合はディスク上の列

ブルごとに行指向型ストレージのデータから複製し，列ごとに指向型ストレージを使用（列指向型）

圧縮して格納している．また，TPC-H によって定義されていFractured Mirrors: 多数列／少数行を利用する OLAP

る OLAP 問合せ 22 種類をそれぞれ 5 回ずつ実行した平均実行

問合せを処理する場合には行指向型ストレージを使用，少数時間をそれぞれの問合せの処理時間とした．

列／多数行を利用する OLAP 問合せを処理する場合には列指向型ストレージを使用（併用型）

図 1 行指向型／列指向型ストレージを用いた DBMS

このとき分散処理環境を実現するために，図 2 のように 2 種

図3

問合せ処理実行時間

類のストレージを利用した複数の計算機を同期レプリケーショ
ンした上で，OSS である Pgpool-Ⅱ 3.4 を用いて各計算機に問合せを分散する負荷分散環境を構築した．この実験環境を利用して，TPC-H によって定義されている 22 種類の OLAP 問合せの中からそれぞれランダムに 8 種類同時に実行して実験を

図 3 が示す結果から，行指向型ストレージのみを使用した場
合が最も平均実行時間が速く，OLAP 問合せを効率良く実行できると言われている列指向型ストレージを用いる場合は問合せを効率良く実行できなかった．特に，列指向型ストレージを利用する場合は，問合せ処理を利用する条件の場合は，平均実行った．

行時間が遅く，かつその分散が大きいため極端に実行時間が遅い問合せ存在することがわかった．その一方で，行指向型スト
レージを用いた場合に比べ，図 4 に示すように問合せ#9，#21
は，行指向型／列指向型の併用型ストレージを用いる場合が最も高速に問合せ処理を実行できるケースがあることが判明した．

図2

レプリケーションを用いた評価実験環境

2. 2 既存のストレージ選択基準の比較
TPC-H を用いて作成されるデータのサイズはスケールファ
クターによって定義されており，本実験ではおよそ 10GB のデータ量となるスケールファクター 10 を使用した．また，行指図 4 問合せ#9，#21 の平均実行時間

向型／列指向型ストレージ選択法の比較には行指向型ストレー
ジのみを用いた場合と，C-Store のように列指向型ストレージ
のみ（テーブルの結合が必要な場合は Hash Join，Merge Join
のみを利用）を利用した場合，そして Fractured Mirrors のよ
うに行指向型／列指向型ストレージを併用する場合の三種類の

このことから，行指向型／列指向型ストレージの併用は，それぞれのストレージのみを利用するよりも高速に問合せを実行できる可能性がある．しかしながら，特に問合せ#2，#5，#8
においては，図 5 が示すようにストレージ併用型に比べて，行
指向型ストレージで問合せ処理する場合の方が大幅に処理時間が短い．つまりこれらの問合せに併用型ストレージを用いる際ズの大きいテーブルの走査条件にインデックスが作成されていのディメリットが含まれると考えられる．

る列が指定されていれば，インデックスを用いた Nested Loop

Join が行われた上でデータの走査が可能なので，行指向型スト
レージを用いたほうが問合せ#5，#8 を高速に実行できたと考えられる．
また，インデックスが利用できないパタンでは，WHERE 句で指定される条件は基本的に列指向型ストレージを用いた場合に余分な列を読み出す必要がないため扱うデータ量が少なく，効率的に問合せ処理を実行できると考えられる．さらに，コストベースでは無くルールベースによる条件ではテーブルサイズを考慮することは難しい．
そこで，テーブルサイズは考慮せず WHERE 句内の条件のインデックスを考慮したストレージ選択条件を以下のように設図 5 問合せ#2，#5，#8 の平均実行時間

定した．



以上のことから，問合せ#2，#5，#8 には行指向型ストレー

条件 2: WHERE 句の条件のうちインデックスが作らジを選択すべき条件があり，また，問合せ#9，#21 のようにれていない数を n，WHERE 句の条件のうちインデッ

併用型ストレージを使用すべき条件が存在することがわかるた

クスが作られている数 m とし，n < m を満たす場合はめ，これらを考慮しながらルールベースのストレージ選択条件
を提案を行い，平均問合せ処理時間の短縮を図ることとする．

行指向ストレージを利用する．







これらの条件 1，2 によって問合せ#2，#5，#8 は高速に処

3. 提 案 手 法

理を実行できると予想されるが，行指向型ストレージのみを用2 節で述べたように，列指向型ストレージの利用においてはいた場合に問合せ処理の実行が遅かった問合せ#9，#21 に関問合せ#2，#5，#8 の平均実行時間が遅いため，列指向型スト

しては，予備実験で使用したストレージ併用型の選択条件が効

レージを利用するには不適切な問合せ処理が行われていると考果的に作用することが分かったために，以下のような条件を設えられる．よって本節では，問合せ#2，#5，#8 を高速化する

定した．

ために，行指向型ストレージを効果的に利用するための条件の

考案と，問合せ#9，#21 を高速に実行できたストレージ併用型

条件 3: テーブルの全列数の半分よりも問合せ内で扱条件との適切な組合せ方法について述べる．また，併用型スト

われる列数のほうが多い場合，行指向ストレージを利用

レージには，図 4 に示したように問合せ処理を高速に実行できた問合せも含まれているため，併用型ストレージにおけるスト
レージ選択条件をも考慮に入れた上で，問合せ内の FROM 句で指定される各テーブルごとにストレージ選択条件を提案する．

3. 1 ストレージ選択条件の考案する

部であり，問合せ#9，#21 を行指向型ストレージのみを用いた場合よりも処理を高速化できると考えられる．

3. 2 ストレージ選択条件の組合せ

合，一般的に副問合せで扱うデータサイズが大きくなると問合せ処理に時間が掛かる傾向にある．また，内部結合が比較的多く実行されるため，Nested Loop Join の処理の効率化にインデックスを利用するべきだと考えられる．このことは，問合せ#2 が行指向型ストレージのみを使用した場合に最も高速に問合せを処理することができたことからも明らかである．よって，
相関副問合せを含む問合せが実行される場合には，以下のようられている場合，行指向ストレージを使用する

3.1 節においてストレージの選択条件を提案したが，この条
件をどのように組み合わせていくのかは未だ決まっていないた
め，それぞれの条件の優先順位を設定する必要がある．
そこで本稿では考案した条件を，問合せ#2 を唯一高速に実行できた条件である条件 1 を筆頭に，平均問合せ処理時間を最も高速に実行できた条件 2，そして残りの条件 3 のように優先順位を決めて条件の適用順を設定した．条件 4 についてはテー
ブルのストレージ選択を行った後にのみ判断できる条件である

ため，ストレージを選択した後に適用するようにしている．これらの優先順位を適用した条件の概略を以下の図 6 ように示す．

条件 1: 相関副問合せの結合条件にインデックスが創

条件 3 は予備実験で使用したストレージ併用型の選択条件の一

まず，問合せ#2 は，相関副問合せが含まれている．この場な条件 1 が設定できる．



4. 評 価 実 験

一方，問合せ#5，#8 は結合処理を行う問合せである．この3 節で述べた条件を図 6 のように適用し，問合せ内の各テー

とき，サイズの大きなテーブルを扱っているが，テーブルの結

ブルごとにストレージの選択を行った問合せ処理の速度，行指合をする際にデータを絞り込むための条件が存在せず，全ての向型ストレージのみを用いた問合せ処理速度，列指向型スト

データを走査するという理由から処理速度が遅い．もし，サイレージのみを用いる C-store 型条件の問合せ処理速度の比較を

図 8 平均問合せ処理実行時間（Scale Factor 10，100）

図6

条件の優先順位

行った．使用した実験環境は，2.1 節と同じものを使用した．
その実験結果を図 7 に示す．

図 9 同時問合せ処理数 24 の場合の平均問合せ処理実行時間（Scale

Factor 10，100）

ジのみを利用した場合が最も平均問合せ処理時間の増加が少な
く，行指向型ストレージに比べて問合せ処理に利用しない列を読み込む必要がなく，扱うデータ量が少なくなるため負荷分散の際に問合せ処理を効率的に行えることがわかった．具体的には，行指向型ストレージと併用型ストレージでは，スケールファ
図7

問合せ処理実行時間（Scale Factor 10）

クター 10 の時は約 3.5 倍，スケールファクター 100 の時は約1.7 倍となったのに対し，列指向型ストレージではそれぞれ約図 7 に示す結果から，平均問合せ処理時間は 3 節で提案した2.3 倍，1.3 倍の増分となっている．このような結果となったのストレージ選択条件を適用した場合が最も早く，効率良くストは，図 10 に示す TPC-H の問合せ#7 のように，同時に処理す

レージの選択を行うことで問合せ処理速度を高速化できたこと

る問合せ処理数が増えた場合においても，列指向型ストレージがわかる．

では問合せ処理速度の増加が少ない問合せがあったからである．

また，およそ 100GB のデータ量となるスケールファクター

問合せ#7 は中間結果に対して sum() や一つの列の全データ

100 を使用した同様の実験を行ったところ，図 8 のように扱うに対して乗算する処理が利用されているため，一度ディスクか

データ量が増えた場合においても，本提案によるストレージのら読み込まれたデータを出来る限り計算機上のメモリにキャッ選択条件が最も平均問合せ処理時間を高速化できたことが示さ

シュすることで，ディスクにアクセスする回数を減らすことがれたため，行指向型／列指向型ストレージを単独で用いるよりできると考えられる．そこで，PostgreSQL の共有バッファサも二種類のストレージを併用運用したほうが有用であることがイズを 2.1 節で述べた各計算機の総メモリサイズに対して 1/2

分かる．

のサイズとなる 8GB に設定して実験を行った．実験に使用し一方，負荷分散がストレージに与える影響を調べるために，たデータは，およそ 10GB となるスケールファクター 10 のデー

TPC-H によって定義されている 22 種類の OLAP 問合せの中

タではほとんどのデータがキャッシュされてしまい，行指向型

からそれぞれランダムに 24 個の問合せを同時に実行して実験

ストレージと列指向型ストレージを利用した際の扱うデータ量を行ったところ，図 9 のような結果となった．

の差が及ぼす問合せ処理時間の性能差が表れないと判断したた

しかし，この結果から，負荷分散によって同時に処理する問

め，およそ 100GB のデータサイズとなるスケールファクター

合せ処理数が 3 倍に増えた場合においては，列指向型ストレー

100 の場合でのみ実験を行った．その実験結果を以下の図 11

ある．
しかし，行指向型ストレージに比べ OLTP 問合せのような行を特定し，取得することでその行に含まれる列データを更新する処理には適していないというデメリットを持ち合わせている．そのため，近年の DBMS は行指向型ストレージと列指向型ストレージを併用することで，OLTP ／ OLAP 双方の問合せを効率的に処理することを目指したものが多い．
この場合，2 節で述べたように，二種類のストレージを併用した問合せに応じてストレージの選択を適切に設定しなければ問合せ処理に時間が掛かることとなる．本節では，1 節で述べ
図 10

問合せ#7 の同時問合せ処理数 8，24 の場合の平均問合せ処理
実行時間（Scale Factor 100）た行指向型と列指向型ストレージを併用する DBMS の例として C-store や Fractured Mirrors のアーキテクチャとストレー
ジの選択基準を紹介する．

に示す．

5. 1 C-Store
C-Store は，近年の DBMS で用いられるようになった一般的な行指向型／列指向型併用ストレージを採用するアーキテク
チャとなっている．ストレージの選択基準は OLTP 問合せの場合は行指向型ストレージを利用し，OLAP 問合せの場合は列指向型ストレージを利用するというものであり近年用いられる
一般的なものとなっている．
このようなアーキテクチャでは，行指向型ストレージは基本的にメモリ上に構築し，列指向型ストレージはディスク上に構築するようになっている．つまり，OLTP により格納されるデータは逐次，列指向型ストレージに格納され，さらに格納されるデータは圧縮されることによって総データ量を減らすことができる．一方，OLAP においては，基本的に列指向型スト図 11

共有バッファサイズ 8GB での同時問合せ処理数 24 の場合のレージを用いて問合せ処理を行うが，行指向型に一時的に保存

平均問合せ処理実行時間（Scale Factor 100）

されているデータを参照する場合には，行指向型ストレージからデータを読み出すことによって，更新途中のデータ参照にお

図 9，11 の結果から，提案手法を用いてストレージを併用

いても一貫性が保たれるようになっている．しかし，本稿で述

運用した場合に最も平均問合せ処理時間が早いことが分かる．

べたように列指向型ストレージのみを用いた OLAP は，問合

また，列指向型ストレージが最も平均問合せ処理時間が遅く，せによっては行指向型ストレージを利用した場合の方が処理を

TPC-H を用いた OLAP 処理性能が良いと判断できないため，高速に実行できるため，C-store のストレージ選択基準が正し既存の列指向型ストレージのみを利用した問合せではなく行指いとは言えない．C-store では列指向型ストレージのみを用い

向型ストレージとの併用運用が必要であると考えられる．しかて OLAP 問合せを処理するが，本稿で述べた提案手法では 2

しながら，共有バッファサイズを増やした場合には列指向型ス

種類のストレージを併用利用するという点でストレージ選択基

トレージのみを利用した場合が最も平均問合せ処理時間の改善

準の違いがある．C-store が採用する OLTP ／ OLAP におけが見られ，提案手法を用いたストレージの併用運用が最も平均

る処理の概略を図 12 に示す．図に示す矢印は，OLTP による問合せ処理時間を改善できていない．具体的には，列指向型ス

データ格納から，OLAP によるデータの読み出しまでの流れをトレージでは約 15%改善できたのに対し，提案手法では共有示している．

バッファを利用したディスクアクセス回数を考慮したストレー

5. 2 Fractured Mirrors

ジ選択を行っていないため，併用型ストレージでは約 5%のみ

Fractured Mirrors は，C-Store のように行指向型／列指向型の改善となっている．

5. 関 連 研 究

ストレージを併用する DBMS だが，C-Store とは異なるアー
キテクチャを構成している．
図 13 に示すように行指向型ストレージと列指向型ストレー

列指向型ストレージはテーブルのデータを列ごとに格納する

ジはそれぞれディスク上に構築され，RAID1 のようなミラー

データ格納方式であり，近年多くの DBMS で採用されるようリングを利用することで二種類のストレージを扱う DBMS をになった．列ごとに格納されたデータは，OLAP 問合せのよ

二台運用し，それぞれ OLTP 用と OLAP 用の DBMS としてうな各列ごとに値を集計する処理に適しており，列単位でデー利用する．また，片方の DBMS に処理が集中した場合には，もタ型が一致するためデータの圧縮効果が高いというメリットがう片方の DBMS を利用することで負荷分散を行うことも可能

向型ストレージを併用運用した際に，TPC-H の問合せ処理の平均実行時間を 5∼25%短縮できた．
しかし，TPC-H の問合せ#2，#9 はおよそ 100GB のサイズとなるスケールファクター 100 のデータを使用した場合に，提案手法のストレージ選択条件が行指向型ストレージのみを使用
した場合よりも，それぞれ約 2.2 倍，約 1.3 倍問合せ処理速度が遅くなってしまったことから，ストレージの選択が効率良く行うことができていない可能性が残されているため，この点も考慮したストレージの併用運用方法も考える必要がある．また，問合せ内の SELECT 句で利用されている sum() や average()などは列指向型ストレージを利用したほうが扱うデータ量も
図 12 C-Store

少ないため，負荷分散環境においても効率よく問合せ処理を行えると考えられる．特に，今回の図 11 の結果から，負荷分散となっている．さらに，OLAP の問合せ処理の性能を向上させ

環境での同時に実行される問合せ処理の数が多い場合に，行指るために，データを列ごとにハードディスクのシリンダごとに向型／列指向型ストレージではそれぞれ約 13%，15%改善で格納して利用することで処理性能を向上させている．

きたことに対して，提案手法を用いた併用型ストレージでは約Fractured Mirrors で考慮されているストレージ選択基準は，5%のみしか改善できていない．そのため，今後のストレージ

基本的に OLAP 問合せは列指向型ストレージを使用するが，多併用運用には共有バッファを利用した際のディスクアクセス回

数列／少数行が選択される問合せ処理の場合には行指向型スト数を考慮して，問合せ処理で利用されるテーブルの列数とディレージを利用するという条件を設定している．2 節で行った実スクページ数によって行指向型／列指向型ストレージを選択し

験では，Fractured Mirrors のストレージ選択基準を利用した

つつ，Sequential Scan 回数によって扱うデータ量の少ない列

OLAP 問合せの平均処理時間が行指向型ストレージのみを用

指向型ストレージを選択する等の，分散処理環境でも利用可能いた場合に比べて遅くなってしまっていたため，本稿ではこのなコストベースクエリプラン生成方法をルールベースクエリプ

Fractured Mirrors のストレージ選択基準も利用しつつ新たにラン生成方法と組み合わせてストレージ選択方法を提案する必ストレージ選択基準を提案することで，行指向型ストレージの要がある．

みを用いた場合よりも問合せ処理時間を短縮できた．

さらに，本稿で評価に利用した TPC-H だけでなく，Star

Schema Benchmark [5] や OLTP 問合せを含む TPC-C を用いたベンチマークテストを行い，提案手法のパフォーマンス測定を行う必要がある．

謝辞本研究の一部は JSPS 科研費 26280115，および文部科学省
私立大学戦略的研究基盤形成支援事業 S1411030 の助成を受けたものである．

文

図 13 Fractured Mirrors

6. お わ り に
本稿では，負荷分散環境の下で行指向型ストレージと列指向型ストレージを併用した DBMS を運用する際に，それぞれのストレージを選択するための条件を定めることで OLAP 問合せの処理最適化を図った．その結果，行指向型ストレージを利用する RDBMS に比べて，提案手法を用いて行指向型／列指献[1] M. Colgan, J. Kamp, and S. Lee. Oracle Database InMemory. Oracle Corporation, October 2014. An Oracle
White Paper.
[2] F. Färber, S.-K. Cha, J. Primsch, C. Bornhövd, S. Sigg,
and W. Lehner. SAP HANA Database: Data Managementfor Modern Business Applications. ACM SIGMOD Record,
40(4):45–51, December 2011.
[3] H. Garcia-Moluna, J. D. Ullman, and J. Widom. Database
Systems: Pearson New International Edition: The Complete Book. Pearson, August 2013.
[4] A. Lamb, M. Fuller, R. Varadarajan, N. Tran, B. Vandiver,
L. Doshi, and C. Bear. The vertica analytic database:C-store 7 years later. In Proceedings of the 1985 ACM
SIGMOD international conference on Management of data,
pages 1790–1801. VLDB Endowment, August 2012.
[5] P. O’Neil, B. O’Neil, X. Chen, and S. Revilak. The Star
Schema Benchmark and Augmented Fact Table. In Performance Evaluation and Benchmarking, pages 237–252. Au-

gust 2009.
[6] R. Ramamurthy, D. J. DeWitt, and Q. Su. A Case for Fractured Mirrors. In Proceedings of the 28th International Conference on Very Large Data Bases, pages 430–441. VLDB
Endowment, August 2002.
[7] R. Seiﬀert.
Online Transactional and Analytics Processing using SPSS, DB2 z/OS, DB2 Analytics Accelerator. http://www-304.ibm.com/connections/blogs/
systemz/entry/online_transactional_and_analytics_processing,
March 2013. Retrieved April 20, 2015.
[8] M. Stonebraker, D. J. Asadi, A. Batkin, X. Chen, M. Cherniack, M. Ferreira, E. Lau, A. Lin, S. Madden, E. O’Neil,
P. O’Neil, A. Rasin, N. Tran, and S. Zdonik. C-Store: A
Column-Oriented DBMS. In Proceedings of the 31st International Conference on Very Large Data Bases, pages
553–564. VLDB Endowment, August 2005.