DEIM Forum 2019 H2-1

複数コア環境におけるアクセス範囲を考慮したOLTP/OLAP同時実行手法

諸岡 大輝† 塩井 隆円†† Le Hieu Hanh†† 横田 治夫††

† 東京工業大学工学部情報工学科 〒 152-8550 東京都目黒区大岡山 2-12-1†† 東京工業大学情報理工学院情報工学系 〒 152-8550 東京都目黒区大岡山 2-12-1E-mail: †{morooka,shioi,hanhlh}@de.cs.titech.ac.jp, ††yokota@cs.titech.ac.jp

あらまし 近年データ分析の需要が高まり,リアルタイムで更新されるデータを対象とした分析処理等が行われてい

る.そのためデータ更新処理を行う OLTPとデータ分析処理を行う OLAPの同時実行を高速化する研究に対して注

目が集まっている.本研究では複数コア環境における OLTPと OLAPの処理性能を向上させることを目的とし,アク

セス範囲に基づいた問合わせの割り当てを行うことで,各コアの L1・L2キャッシュのヒット率を向上させ,OLTPと

OLAPの同時実行を高速に行う手法を提案する.

キーワード 複数コア,OLTP,OLAP,キャッシュヒット率,並列実行

1 は じ め に

1. 1 研 究 背 景

データベース処理は大きく分けてデータ更新を高頻度に行う

トランザクション処理とデータ分析処理の 2 つに分類される.

トランザクション処理とデータ分析処理は参照するデータの配

置が異なるため単一のデータベースシステムで高速に同時実行

することが困難である. しかしながら近年ではビックデータ・

IoT・AIの伸長によりデータ分析の需要が高まり,リアルタイ

ムで更新されたデータを対象としたデータ分析処理が求められ

ている.そのためデータベースシステムの分野では,単一のデー

タベースシステム上でトランザクション処理とデータ分析処理

の同時実行を高速化する研究に注目が集まっている [1].

同様に近年の傾向としてマルチコア CPUの多用化が挙げら

れる. クロック周波数を上昇させることで CPU の処理性能を

向上させる手法は限界に達し,高い処理性能が求められる分野

では,各々のコアのクロック周波数は低いが,処理を複数コアで

分散させることで全体として高性能処理を実現するマルチコア

CPUを用いる傾向にある [2].したがって複数コアを活かして

処理を分散させることで,処理性能を向上させるアプリケーショ

ンの開発が必要不可欠である. しかしながら, 複数コアを用い

たトランザクション処理とデータ分析処理の同時実行に関する

研究は依然として充分に行われていない.

そこで本研究は,複数コア環境においてトランザクション処

理とデータ分析処理の同時実行を高速化することを目的とす

る. 複数コア環境でトランザクション処理とデータ分析処理を

同時実行すると,各コアに割り当てられる処理が頻繁に変化し,

キャッシュヒット率が上がらないため,処理性能が向上しない.

したがって,処理性能を向上させるためには各コアへの処理の

割り当てを工夫してキャッシュヒット率を上げる必要がある. そ

こで, 本研究では各コアのキャッシュヒット率を向上させるた

めに,問合わせのアクセス範囲に着目した手法の実装・評価を

行う.

1. 2 本稿の構成

本稿は以下の通りに構成される．2節では背景となる知識に

ついて解説を行い，3節は関連する研究について述べる．4節

では本研究におけるアクセス範囲を考慮した手法を提案する.5

節では実験環境や実験内容と実験結果について述べる.最後に

6節で本稿のまとめと今後の課題を述べる.

2 背 景 知 識

本節では,本研究を理解する際に前提とする知識について説

明を行う.

2. 1 OLTP(OnLine Transaction Processing)

OLTPとはクライアントの要求に基づいて,即時性が求めら

れるデータ挿入・更新・検索等のトランザクション処理を実行

することを意味する.OLTP 一つあたりの処理は小さいサイズ

のデータ処理のため軽いが,同時に多数のクライアントがアク

セスした際にも即時性が求められる. また, 頻繁にデータの追

加・削除,すなわちデータ更新処理が行われる点が特徴である.

図 1は OLTPの一例として INSERTを行指向と列指向で実行

した際のアクセス範囲を表している. INSERTのようにデータ

更新処理を行指向で実行すると新しい行を追加する処理のみと

なり,高速に処理が行える.一方で列指向では保存している全て

の列に要素を追加する必要があり,行指向と比較すると低速で

ある.また INSERTのみに限らず,複数属性に対する SELECT

では行 ID に基づく JOIN 処理が必要であり, オーバーヘッド

が大きくなるため,列指向は行指向よりも低速となる.このよう

に OLTP は全般的に行指向で処理を行うと高速に実行が可能

であり,列指向では低速となる.

図 1 OLTP 実行例

図 2 OLAP 実行例

2. 2 OLAP(OnLine Analytical Processing)

OLAPはデータベース上に保存された大量のデータに対し,

複雑な分析や集計処理を行うことを意味する.OLTP と比較す

ると特定の列について,全ての行をアクセスすることが多い点

が特徴である.

図 2は行指向と列指向で OLAP実行をした際のアクセス範

囲を表している.OLAPはテーブルの全てのデータを参照する

ことは少なく,多くのOLAPは特定の列ごとに集計処理を行う.

したがって列指向では対象となる列データのみを参照できるた

め,高速に処理が行える.一方で行指向では特定の列のみを集計

する際にも,全ての行を参照する必要があるため,列指向と比べ

て低速である.したがって OLAPは列指向で処理を行うと高速

に実行が可能である.

従来の OLAP はバッチ処理によって定期的に Data Ware-

house(DWH) に投入されたデータに対してデータ分析処理を

行うため,DWHとして列指向型 DBMSの Vertica [3]等を利用

し,OLAPを実行することが多かった.しかしながら,この手法

ではデータ分析の対象となるデータと最新のデータに差異が生

じてしまう. したがって OLAP の対象データを OLTP によっ

てリアルタイムで更新されたデータにするために,単一のデー

タベースシステム上で OLTPと OLAPの同時実行を高速化す

る研究が必要である.

3 関 連 研 究

本節では,本研究に関連する研究を紹介する.

3. 1 OLTP/OLAP並列実行

SAP HANA [4] はメインのデータベースエンジンを列指向

型データベースにすることで OLAPの高速化を実現している.

一方で OLTPに対しては,行指向と列指向のバッファを 1層ず

つ持ち,データベースへのデータ更新処理を一時的に行指向の

バッファに書き込んだ後に,バックグラウンドで列指向に変換す

る処理を行うことで,クライアント目線での応答時間が短縮さ

れ,OLTPと OLAPの並列実行の高速化を実現している.この

ように OLTPと OLAPを並列実行する際には行指向型のデー

タ構造と列指向型のデータ構造両方を持つことで高速に処理が

可能になる.

また,列指向型データベースをメインエンジンとして用いる

もう一つの理由としてデータの圧縮が効率的に行える点があげ

られる.この研究ではデータの圧縮を効率的に行い,データ処理

で扱うデータサイズを縮小している.それにより,容量が小さい

L1・L2キャッシュに対してもキャッシュヒット率を向上させ,処

理性能を向上している.

しかしながら,SAP HANA [4]では L1・L2キャッシュのヒッ

ト率を向上する手法は列指向型データベースを使用する以外に

行われていないため,さらなるキャッシュヒット率の向上が見込

める.

3. 2 マルチコアDBシステム

複数コア環境におけるデータベースシステムの処理性能を向

上させた研究として,Xiらが提案した CARIC-DA [5]が挙げら

れる.この研究ではトランザクションのアクセス範囲に応じて

トランザクションを処理するコアを変化させる手法を用いるこ

とで, 各コアの L1・L2 キャッシュヒット率を向上させ,OLTP

の処理性能が向上することを示した.

しかしながら,CARIC-DA [5]では OLTPのみに対応してお

り,OLTPと OLAPを並列に実行する運用に対応できていない

という課題点が挙げられる.

本稿ではこれらの課題点を解決するために,複数コア環境で

OLTPとOLAPを並列に実行した際に,各コアごとのキャッシュ

ヒット率を向上し,処理性能を向上させることを目的とする.

4 提 案 手 法

前節を踏まえて,本稿では OLTPと OLAPの各問合わせの

アクセス範囲に応じて問合わせ処理を実行するコアを指定する

手法を提案する.

本節ではまず提案手法の全体像を述べ,次に提案手法で用い

た問合わせ割り当て手法の説明を行う.

4. 1 全 体 像

データベースに対して問合わせ処理を実行すると,メインメ

モリかディスクに保存されたデータにアクセスし,そのデータ

がキャッシュメモリにキャッシュされる. 行指向型データベー

スと列指向型データベースに対して問合わせ処理を同時に実行

すると,2節で述べたデータアクセスが実行され,L1・L2キャッ

シュ上に行指向のデータと列指向のデータが混在した状況にな

図 3 提案手法概要図

り,キャッシュヒット率が低下することから処理性能が低下する

と考えられる.

本手法では 3節で述べた CARIC-DA [5]同様に,データベー

スサーバ上のコアを問合わせ処理を実行するコア (以下,DBP)と

DBPに対して問合わせの割り当てを実行するコア (以下,CDP)

の 2種類に区別し,問合わせ処理のアクセス範囲に応じた割り

当てを行うことで,DBPのキャッシュヒット率を向上させ,デー

タベースシステム全体の処理性能を向上させる.CARIC-DA [5]

では DBPは OLTPのみに対応していたが,本手法では OLTP

に加えて OLAPに対応するために,OLAPを行う DBPを用意

する.

図 3が本手法の全体像となる. クライアントはサーバに問合わ

せを送信し,サーバー上で問合わせの割り当てを行うことで,そ

の問合わせのアクセス範囲に応じて,いずれかのDBPに問合わ

せ処理を実行させる.図 3の例では,DBP1はmathの列,DBP2

では physicsの列を対象とした OLAPを実行する.DBP3では

1-50の範囲,DBP4では 51-100の範囲を対象とした OLTPを

実行することで,各コアの L1・L2キャッシュに行指向のデータ

と列指向のデータが混在することを防いでいる.

4. 2 問合わせ割り当て

問合わせ割り当ては DBP, CDP, Range Index, Bufferとい

う 4つの構成要素を用いる.本小節ではこれら 4つの構成要素

についての説明を述べる.

4. 2. 1 DBP

DBPとはデータベースにアクセスし,問合わせ処理を実行す

るコアを表している.

DBP は OLTP の処理を行う DBP と OLAP の処理を行

う DBP の二種類に分類され,OLTP 処理 DBP では行指向型

DBMS を使用し,OLAP 処理 DBP では列指向型 DBMS を使

用する.

4. 2. 2 CDP

CDP とは DBP に対して問合わせの割り当てを実行するコ

アを表している.サーバ上の論理コアは全て DBPか CDPのい

図 4 問合わせ割り当て

ずれかに分類される.

CDP は問合わせがどの DBP 上で実行されるべきかを表し

た Range Indexを参照し,適切な DBPに問合わせを実行させ

る役割である.また,クライアントとの通信も全て CDPが行う.

4. 2. 3 Range Index

Range Index は全ての CDP が共有しているデータであり,

各 DBPがどの範囲の問合わせ処理を行うかを表している.図 4

の例では DBP1が mathの列,DBP2が physicsの列を処理す

る OLAP 処理用 DBP.DBP3 が 1-50 の範囲,DBP4 が 51-100

の範囲を処理するOLTP処理DBPであるという情報をRange

Indexが保持している.

4. 2. 4 Buffer

Bufferは DBPと CDP間で問合わせや問合わせの処理結果

を共有するために使用する.Bufferには 2種類あり,DBP各々が

所有する Q Bufferと CDP各々が所有する A Bufferに分類さ

れる.

Q Buffer は CDP がクライアントから取得した問合わせを

DBPに伝達するために使用する.一方で A Bufferは DBPが

問合わせ処理を実行し, 得た処理結果を CDP に返送するため

に使用する.

Buffer は DBP や CDP 同士で競合が発生しないように, セ

マフォを用いたロック機能を使用する.

4. 3 処 理 手 順

本小節ではクライアントと通信を行い,問合わせ処理を実行

する際の処理手順を述べる.

まず, サーバの論理コアを CDP と DBP の二種類に分類す

る. 次に, アクセス範囲と DBP の対応関係を Range Index に

格納する.

以上の処理を行った状態で,以下の処理手順に沿ってクライ

アントと通信を行う.なお,処理手順の番号は図 4の番号に対応

する.

表 1 実 験 環 境

クライアント サーバ

プロセッサ Intel Xeon E7-4860 AMDOpteron 6174

ソケット数 4 4

論理コア数 80 48

クロック周波数 2.27GHz 2.20GHz

L1 キャッシュ 32KB+32KB 64KB+64KB

L2 キャッシュ 256KB 512KB

L3 キャッシュ 24576KB 5118KB

RAM 32GB 32GB

OS Ubuntu 16.04.3 Ubuntu 16.04.3

PostgreSQL 9.5.14 9.5.14

cstore fdw 未使用 1.6.2

1⃝ CDPは socket通信を用いてクライアントから問合わせを受信

2⃝ CDP は Range Index を参照し, 問合わせを実行するDBP情報を取得

3⃝ CDPは DBPに対応する Q Bufferに問合わせを書き込む

4⃝ DBPは Q Bufferから問合わせを取得5⃝ DBPは DBにアクセスし,問合わせ処理を実行6⃝ DBPは A Bufferに問合わせの処理結果を書き込む7⃝ CDPは A Bufferから処理結果を取得8⃝ CDPは socket通信を用いてクライアントに実行結果

を送信

DBP は Range Index に従い, 特定のアクセス範囲のみを

参照する. 各々の DBP が限られた範囲のみをアクセスするた

め,DBPの L1・L2キャッシュヒット率が向上し,処理性能が向

上すると考えられる.

5 実 験

提案手法の性能,及びパラメータによる性能の変化を調べる

ため,C言語を用いて問合わせ割り当て手法を実装し,以下に示

す複数の実験を行った.

5. 1 実 験 環 境

表 1に本実験で用いた実験環境を示す.

Linux環境ではプログラムを実行する際, プロセスを特定の

コアに限定して実行させることができる.本研究は Linuxカー

ネル 2.6以降の環境で使用可能な「sched setaffnity()」APIを

用いて CPU affinity を設定することで問合わせの割り当てを

行った.

行指向の DBMSとして PostgreSQL,列指向の DBMSとし

て Citus Data 社が PostgreSQL の拡張機能として提供する

cstore fdw [6]を使用した.

なお,ディスク I/Oがボトルネックとなることを防ぐために

PostgreSQLの「shared buffers」の値を 20GBに設定した.こ

れによって実験の際のデータセットは全てメインメモリ上で処

理が行われた.

表 2 性能評価対象

OLTP OLAP 問合わせ割り当て perf

ベースラインPostgreSQL cstore fdw

未使用使用

提案手法 使用

表 3 コ ア 配 分

CDP DBP(OLTP) DBP(OLAP)

実験 1:OLTP 16 32 0

実験 2:OLAP 1 0 47

実験 3:OLTP&OLAP 9 16 23

5. 2 実 験 方 法

OLTP,OLAP,OLTP/OLAP同時実行の 3種類に対する有効

性を測るために 3つの実験を行い,提案手法とベースラインの

比較を行った.

表 2 に本実験におけるベースラインと提案手法の定義を示

す. ベースラインは問合わせの割り当てを行わず, 直接サーバ

に対して問合わせを実行した. また, どちらの場合に対しても

Linuxカーネル 2.6.31以降の環境で使用可能な perf [7]を用い

て DBPのキャッシュミス率計測を同時に行った.

なお,提案手法に関しては論理コア数 48のサーバマシンに対

して表 3のように CDPと DBPのコア数を調節しながら実験

を行った.

5. 3 実験内容・結果

5. 3. 1 実験 1:OLTP

OLTP における本手法の有効性を確認するために,TPC-C

benchmark [8]の簡易実装である JdbcRunner [9](スケールファ

クター:SF=16)のデータと問合わせを用いて実験を行った.New-

Order, Payment, Order-Status, Delivery, Stock-Levelの 5種

類のトランザクション数を 10:10:1:1:1 の比率で実行する.1 ク

ライアントあたり 5000 トランザクションを実行し, 同時接続

するクライアント数を変化させながら,1秒間に処理したトラン

ザクション数である transaction per second(以下,tps)と DBP

のキャッシュミス率を計測し,評価を行った.

Queryの割り当て手法として多くのテーブルの主キーや外部

キーである,Warehouse id と District id を基に分割し,Query

の割り当てを行った.

実験 1 の結果を図 5～7 に示す. 図 5 と図 6 から, クライア

ント数が少ない場合にはキャッシュミス率はベースラインに劣

る結果になるが,ベースラインはクライアント数の増加に対し

てキャッシュミス率が高くなるのに対して,提案手法ではキャッ

シュミス率が低下し続けていることが確認できる.

図 7に示した tpsでは,キャッシュミス率がベースラインより

劣る,48クライアント時に提案手法とベースラインを比較する

と tpsが 150低下し,処理性能が 10.2%低下している. しかし

ながらサーバの論理コア数である 48を超えるクライアント数

では,提案手法がベースラインを上回る結果となり,96クライア

ント時に提案手法とベースラインを比較すると tpsが 400上昇

図 5 実験 1:L1 データキャッシュ

図 6 実験 1:L1 命令・L2 キャッシュ

図 7 実験 1:tps

し,処理性能が 35.9%向上する結果となった.

ベースラインではデータ処理を行う DBP をサーバ上の 48

コア全て使用するが,提案手法では 16コアを CDPとして使用

するため DBPは 32コアのみしか使用しておらず,処理性能が

ベースラインよりも低下してしまう危険性がある.しかしなが

ら実験結果から,キャッシュヒット率を向上させることでベース

ラインを上回る性能となることがわかり,本手法の有効性を確

認できる.

5. 3. 2 実験 2:OLAP

OLAPにおける本手法の有効性を確認するために以下の実験

を行った.

TPC-H benchmark [10](スケールファクター:SF=1)のデー

タである,supplier テーブル (10000タプル) に対して比較的軽

図 8 集計処理割り当て手法

図 9 実験 2:L1 データキャッシュ

い集計処理として,以下の 4つのQueryを用いて実験を行った.

Query 1: SELECT SUM(s acctbal) FROM supplier

Query 2: SELECT AVG(s nationkey) FROM supplier;

Query 3: SELECT COUNT(s suppkey) FROM supplier:

Query 4: SELECT COUNT(s nationkey)

FROM supplier WHERE s nationkey=x;

1クライアントは 4種類のQueryの中からランダムにQuery

を選択し,実行する処理を 1回とし,この処理を 5000回実行す

る. 同時接続するクライアント数を変化させながら, 各 Query

の応答時間・サーバが 1 秒間に処理した問合わせの数である

query per second(以下,qps)・DBPのキャッシュミス率を計測

し,評価を行った.

Query の割り当て方式は各 DBP に対して実行する Query

を指定し,それぞれの DBPがすでに Queryを実行している際

には待ち行列を生成する手法を用いた.このように設定するこ

とで各 DBP は限られた属性のみを対象としたデータアクセ

スを行う. 図 8 の例では Query1 を実行するコアは DBP1 と

DBP2 とし,Query2 は DBP3 でのみ実行するように設定して

いる.これによって DBP1と DBP2は s acctbalカラム,DBP3

は s nationkeyカラムのみにアクセスを行う.

実験 2の結果を図 9～12に示す.図 9と図 10に示した L1・L2

キャッシュミス率に関してベースラインと比較を行うと,ベース

ラインと提案手法でほぼ差が生じていないことがわかる.この理

由として cstore fdwは read命令を stripeと呼ばれる単位でま

とめて行っており,10000 タプル,7 カラムの supplier テーブル

は 1つの stripeに収まるデータサイズであると考えられる. し

たがってベースラインと提案手法で集計処理を実行する際にメ

図 10 実験 2:L1 命令・L2 キャッシュ

図 11 実験 2:qps

図 12 実験 2:応答時間

モリからフラッシュするデータサイズが同じになったため,L1・

L2キャッシュヒット率に差が生じなかったと考えられる.

図 11に示した qpsに関してはクライアント数が少ない際に

は, ベースラインを上回り,24 クライアントの際には qps が約

2200上昇し,処理性能が 37.6%上昇する結果となった.この理

由はベースラインが 24クライアントの際には特定のコアのみ

で OLAP を実行するようにスケジューリングされ,DBP とし

て使用できるコアを充分に使用できていなかったためと考えら

れる. 実験時における提案手法とベースラインの DBP として

用いたコアの CPU利用率を比較した結果が表 4である. ベー

スラインは CPU利用率が 17.6%に対して提案手法は 27.3%と

なっている.したがって CPUスケジューリングの差から提案手

法が優れた qpsになったと考えられる.

表 4 実験 2:CPU 利用率

ベースライン 提案手法

24 クライアント 17.6% 27.3%

72 クライアント 51.2% 50.6%

しかしながら, クライアント数が 48 より多くなった際には

ベースラインを下回る結果となり,72 クライアント時には qps

が約 3800低下し,処理性能が 30.4%低下している. この理由と

して,表 4から CPU利用率の観点でベースラインが提案手法

より優れた結果となったことが挙げられる.また提案手法は問

合わせを実行する DBPを指定し,待ち行列を生成していた.し

たがって問合わせを実行すべき DBPがすでに他のクライアン

トの問合わせで埋まっている場合には,待ち時間が生じてしま

う.クライアント数が増加した際にはこの待ち時間のオーバー

ヘッドが非常に大きくなってしまうため,qpsが低下する結果に

なったと考えられる.

図 12 に示した各 Query の応答時間を見ると,24 クライア

ント時には全ての Query がベースラインよりも短い応答時間

だが,72クライアント時には Query4の応答時間が大幅に長く

なっていることが確認できる.DBP に使用した 47 コアのうち

Query1～3は各 12コアで実行していたのに対し,Query4のみ

が 11コアで実行していたため,他の Queryよりも使用できる

コアが少ない状況が続き,クライアントほぼ全員が Query 4の

DBPが使用可能になるのを待つ状況になり,待ち時間の増加に

よって応答時間が大幅に遅くなってしまったことと考えられる.

この待ち時間を解消するための方策としては,問合わせの偏り

に応じてコアの割り当て範囲を変更するロードバランス機能を

実装することが挙げられる.

5. 3. 3 実験 3:OLTP/OLAP同時実行

本研究の目的である OLTPと OLAPの同時実行に対する本

手法の有効性を確認するために,以下の実験を行った.

実験 1で使用した TPC-Cのトランザクションと実験 2で使

用した問合わせ処理を同時に実行する.なお,本実験ではOLTP

と OLAPの対象テーブルは異なるため,OLAPの対象データは

OLTPによって更新されたデータではない.

また,問合わせ処理に関しては OLAP処理 DBPにかかる負

荷を分散させるため,Query 1～Query 4を 1:2:2:2の比率で実

行するように変更した.

問合わせ処理とトランザクション処理を 5分間並列に実行し,

同時接続するクライアント数を変化させながら,トランザクショ

ン処理の tps,問合わせ処理の応答時間及び qps,DBPのキャッ

シュミス率を計測し,評価を行った.

なお,本実験ではトランザクション処理と問合わせ処理のク

ライアント数は等しいものとし,12クライアントで実験を行っ

た際には,サーバに対してトランザクション処理と問合わせ処

理どちらも 12クライアント,合計 24クライアントが接続して

いる状況とする.

実験 3 の結果を図 13～16 に示す. 図 13 に示した OLTP の

tpsに関しては,クライアント数が少ない際の結果に対してウェ

図 13 実験 3:tps

図 14 実験 3:qps

図 15 実験 3:L1 データキャッシュ

ルチの t検定を行ったところ有意差は確認できなかった.しかし

ながら,実験 1と同様に同時接続するクライアント数が増加す

るにつれて提案手法はベースラインを上回り,72クライアント

時には tpsが約 70上昇し,6.0%の処理性能向上が確認できた.

図 14に示した OLAPの qpsに関しては,クライアント数が

少ない際にはベースラインよりも優れた結果となり,12クライ

アント時には qpsが約 900上昇し,27.1%の処理性能向上が確認

できた.

しかしながら,実験 2と同様にクライアント数が多い際には

待ち時間が長いことや L1・L2キャッシュヒット率に差が出な

いことが原因になり,72 クライアント時には qps が約 5200 低

下し,40.7%処理性能が低下する結果となった.

図 15と図 16のキャッシュミス率を見ると,提案手法のキャッ

図 16 実験 3:L1 命令・L2 キャッシュ

シュミス率はクライアント数が多い際にはベースラインの結果

に劣る結果となっている. この理由としてベースラインは qps

が線形に近い形で増加をし続け,集計処理の実行回数がトラン

ザクション処理と比べ,大幅に増加している.集計処理は 1つの

テーブルのみを対象とした処理であり,トランザクション処理

と比較して,キャッシュヒット率が非常に高い.ベースラインは

キャッシュヒット率が非常に高い集計処理を,トランザクション

処理の 10倍以上多く実行している.一方で提案手法はベースラ

インと比べると集計処理の実行回数が少なく, トランザクショ

ン処理の約 6倍ほどしか実行をしていない.したがってベース

ラインのキャッシュミス率が提案手法よりも低い結果になった

と考えられる.

5. 3. 4 ま と め

OLTPに関しては実験 1にて 96クライアント時に 35.9%の

性能が向上し,提案手法はデータベースへの同時接続数が増え

た際に処理性能が向上することが確認できた.

OLAPに関しては,実験 2にて 24クライアント時に 37.6%処

理性能が向上したが,72クライアント時には 30.4%処理性能が

低下する結果となった.この原因として,cstore fdwを用いたこ

とによって L1・L2キャッシュのキャッシュヒット率に差が生じ

なかったことと,DBPの待ち行列による待ち時間がクライアン

ト数の増加によって大幅に増加したことが挙げられる.

また,OLTPと OLAPを並列実行に関しては,OLTPは 72ク

ライアント時には.6.0%の処理性能向上が確認できた.OLAPで

は 12クライアント時には 27.1%の処理性能向上し,72クライア

ント時には 40.7%処理性能が低下する結果になった.この結果

についても OLAP実験と同様に,待ち行列による待ち時間が原

因であると考えられる.

なお,今回の実験では OLTPの更新が OLAPの対象データ

に反映されていないため,より実世界で求められる処理性能を

評価するにはさらなる実験が必要である.

6 お わ り に

本研究では複数コア環境において OLTPと OLAPの同時実

行を高速化を目的に研究を行った.アプローチとしてアクセス

範囲に基づいて問合わせの割り当てを行い,各コアのキャッシュ

ヒット率を向上することで高速化を実現する手法を示した.

提案手法について実験を行った結果,同時接続数が増加し,ク

ライアント同時リクエスト負荷が高い際に OLTP 処理性能の

向上が確認できた.また,OLAPに関しては同時接続数が少数で

あり,クライアント同時リクエスト負荷が低い際に処理性能向

上が確認できた.

さらに, 本研究の目的である OLTP/OLAP の同時実行に関

しても同様に,OLTPは同時リクエスト負荷が高い際に処理性能

の向上が確認でき,OLAPは同時リクエスト負荷が低い際に処

理性能の向上が確認できた.しかしながら,同時リクエスト負荷

が高くなった際には OLAP処理性能は低下してしまうことが

わかった.この原因としてクライアント数の増加によって,DBP

の処理に偏りが生じてしまい,各コアの待ち時間が大幅に増加

したこと.また,cstore fdwのデータアクセス方式によって,L1・

L2キャッシュのキャッシュヒット率に差が生じなかったことが

考えられる.

今後の課題としては, 今回の実験におけるボトルネックと

なったアクセス範囲に偏りが生じた際の待ち時間解消や OLAP

処理性能を向上させるために OLAP 処理を行う DBMS を

cstore fdw 以外の列指向型データベースに変更し, 列ごとの

データをキャッシュに保存させることで L1・L2キャッシュヒッ

ト率を向上させることが挙げられる.

また,今回の実験では OLTPの更新を OLAPの対象データ

に反映できていないため,OLTP によるデータ更新を反映でき

るように機能拡張する必要がある.

そのほかにも,今回の実験ではベースラインの OLTP処理性

能はクライアント数がサーバの論理コア数よりも多くなった際

に低下したため,提案手法はベースラインよりも高い処理性能

になった.したがって,より論理コア数の多いサーバマシンにお

けるベースラインと提案手法の性能検証が必要である.

謝 辞

この成果は,国立研究開発法人新エネルギー・産業技術総合

開発機構（ＮＥＤＯ）の委託業務の結果得られたものである.

文 献[1] Samuel S Conn. OLTP and OLAP data integration: a re-

view of feasible implementation methods and architectures

for real time data analysis. In Proceeding of the 2005 South-

eastCon, pp. 515–520. IEEE, 2005.

[2] David Geer. Chip makers turn to multicore processors.

Computer, Vol. 38, No. 5, pp. 11–13, 2005.

[3] Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan, Nga

Tran, Ben Vandiver, Lyric Doshi, and Chuck Bear. The ver-

tica analytic database: C-store 7 years later. Proceedings

of the VLDB Endowment, Vol. 5, No. 12, pp. 1790–1801,

2012.

[4] Vishal Sikka, Franz Färber, Wolfgang Lehner, Sang Kyun

Cha, Thomas Peh, and Christof Bornhövd. Efficient trans-

action processing in SAP HANA database: the end of a

column store myth. In Proceedings of the 2012 ACM SIG-

MOD International Conference on Management of Data,

pp. 731–742. ACM, 2012.

[5] Fang Xi, Takeshi Mishima, and Haruo Yokota. CARIC-DA:

Core affinity with a range index for cache-conscious data ac-cess in a multicore environment. In Proceedings of the In-

ternational Conference on Database Systems for Advanced

Applications, pp. 282–296. Springer, 2014.

[6] Citus Data. cstore fdw-Fast columnar store for analytics

with PostgreSQL. http://citusdata.github.io/cstore_

fdw/.

[7] perf:Linux profiling with performance counter. https://

perf.wiki.kernel.org/index.php/Main_Page.

[8] TPC. TPC-C Benchmark 5.11.0. http://www.tpc.org/

tpcc/.

[9] Sadao Hiratsuka. JdbcRunner - 汎用データベース負荷テストツール. https://dbstudy.info/jdbcrunner/.

[10] TPC. TPC-H Benchmark 2.17.3. http://www.tpc.org/

tpch/.