DEIM Forum 2019 H2-1

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

塩井 隆円††Le Hieu Hanh††

横田治夫††† 東京工業大学工学部情報工学科 〒 152-8550 東京都目黒区大岡山 2-12-1†† 東京工業大学情報理工学院情報工学系 〒 152-8550 東京都目黒区大岡山 2-12-1
E-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 研 究 背 景

1. 2 本稿の構成

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

本稿は以下の通りに構成される．2 節では背景となる知識にトランザクション処理とデータ分析処理の 2 つに分類される.

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

トランザクション処理とデータ分析処理は参照するデータの配では本研究におけるアクセス範囲を考慮した手法を提案する.5

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

節では実験環境や実験内容と実験結果について述べる. 最後にすることが困難である. しかしながら近年ではビックデータ・

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

IoT・AI の伸長によりデータ分析の需要が高まり, リアルタイ
ムで更新されたデータを対象としたデータ分析処理が求められている. そのためデータベースシステムの分野では, 単一のデー
タベースシステム上でトランザクション処理とデータ分析処理の同時実行を高速化する研究に注目が集まっている [1].
同様に近年の傾向としてマルチコア CPU の多用化が挙げら

2 背景知識本節では, 本研究を理解する際に前提とする知識について説明を行う.

2. 1 OLTP(OnLine Transaction Processing)れる. クロック周波数を上昇させることで CPU の処理性能をOLTP とはクライアントの要求に基づいて, 即時性が求めら向上させる手法は限界に達し, 高い処理性能が求められる分野

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

では, 各々のコアのクロック周波数は低いが, 処理を複数コアですることを意味する.OLTP 一つあたりの処理は小さいサイズ分散させることで全体として高性能処理を実現するマルチコアのデータ処理のため軽いが, 同時に多数のクライアントがアクCPU を用いる傾向にある [2]. したがって複数コアを活かしてセスした際にも即時性が求められる. また, 頻繁にデータの追処理を分散させることで, 処理性能を向上させるアプリケーショ

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

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

図 1 は OLTP の一例として INSERT を行指向と列指向で実行たトランザクション処理とデータ分析処理の同時実行に関するした際のアクセス範囲を表している. INSERT のようにデータ研究は依然として充分に行われていない.

更新処理を行指向で実行すると新しい行を追加する処理のみとそこで本研究は, 複数コア環境においてトランザクション処なり, 高速に処理が行える. 一方で列指向では保存している全て理とデータ分析処理の同時実行を高速化することを目的とすの列に要素を追加する必要があり, 行指向と比較すると低速でる. 複数コア環境でトランザクション処理とデータ分析処理をある. また INSERT のみに限らず, 複数属性に対する SELECT同時実行すると, 各コアに割り当てられる処理が頻繁に変化し,では行 ID に基づく JOIN 処理が必要であり, オーバーヘッドキャッシュヒット率が上がらないため, 処理性能が向上しない.

が大きくなるため, 列指向は行指向よりも低速となる. このようしたがって, 処理性能を向上させるためには各コアへの処理のに OLTP は全般的に行指向で処理を行うと高速に実行が可能

割り当てを工夫してキャッシュヒット率を上げる必要がある. そであり, 列指向では低速となる.

こで, 本研究では各コアのキャッシュヒット率を向上させるた3. 1 OLTP/OLAP 並列実行
SAP HANA [4] はメインのデータベースエンジンを列指向型データベースにすることで OLAP の高速化を実現している.
一方で OLTP に対しては, 行指向と列指向のバッファを 1 層ずつ持ち, データベースへのデータ更新処理を一時的に行指向のバッファに書き込んだ後に, バックグラウンドで列指向に変換する処理を行うことで, クライアント目線での応答時間が短縮され,OLTP と OLAP の並列実行の高速化を実現している. このように OLTP と OLAP を並列実行する際には行指向型のデー
図 1 OLTP 実行例

タ構造と列指向型のデータ構造両方を持つことで高速に処理が可能になる.
また, 列指向型データベースをメインエンジンとして用いる
もう一つの理由としてデータの圧縮が効率的に行える点があげられる. この研究ではデータの圧縮を効率的に行い, データ処理で扱うデータサイズを縮小している. それにより, 容量が小さい

L1・L2 キャッシュに対してもキャッシュヒット率を向上させ, 処理性能を向上している.
しかしながら,SAP HANA [4] では L1・L2 キャッシュのヒット率を向上する手法は列指向型データベースを使用する以外に行われていないため, さらなるキャッシュヒット率の向上が見込
図 2 OLAP 実行例

2. 2 OLAP(OnLine Analytical Processing)
OLAP はデータベース上に保存された大量のデータに対し,複雑な分析や集計処理を行うことを意味する.OLTP と比較す
ると特定の列について, 全ての行をアクセスすることが多い点が特徴である.
図 2 は行指向と列指向で OLAP 実行をした際のアクセス範囲を表している.OLAP はテーブルの全てのデータを参照することは少なく, 多くの OLAP は特定の列ごとに集計処理を行う.
したがって列指向では対象となる列データのみを参照できるため, 高速に処理が行える. 一方で行指向では特定の列のみを集計する際にも, 全ての行を参照する必要があるため, 列指向と比べて低速である. したがって OLAP は列指向で処理を行うと高速に実行が可能である.
従来の OLAP はバッチ処理によって定期的に Data Ware-house(DWH) に投入されたデータに対してデータ分析処理をめる.

3. 2 マルチコア DB システム
複数コア環境におけるデータベースシステムの処理性能を向上させた研究として,Xi らが提案した CARIC-DA [5] が挙げられる. この研究ではトランザクションのアクセス範囲に応じてトランザクションを処理するコアを変化させる手法を用いることで, 各コアの L1・L2 キャッシュヒット率を向上させ,OLTPの処理性能が向上することを示した.
しかしながら,CARIC-DA [5] では OLTP のみに対応しており,OLTP と OLAP を並列に実行する運用に対応できていないという課題点が挙げられる.
本稿ではこれらの課題点を解決するために, 複数コア環境でOLTP と OLAP を並列に実行した際に, 各コアごとのキャッシュヒット率を向上し, 処理性能を向上させることを目的とする.

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

前節を踏まえて, 本稿では OLTP と OLAP の各問合わせのし,OLAP を実行することが多かった. しかしながら, この手法アクセス範囲に応じて問合わせ処理を実行するコアを指定する

ではデータ分析の対象となるデータと最新のデータに差異が生手法を提案する.

じてしまう. したがって OLAP の対象データを OLTP によってリアルタイムで更新されたデータにするために, 単一のデータベースシステム上で OLTP と OLAP の同時実行を高速化する研究が必要である.

本節ではまず提案手法の全体像を述べ, 次に提案手法で用いた問合わせ割り当て手法の説明を行う.

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

3 関連研究モリかディスクに保存されたデータにアクセスし, そのデータがキャッシュメモリにキャッシュされる. 行指向型データベー

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

スと列指向型データベースに対して問合わせ処理を同時に実行
すると,2 節で述べたデータアクセスが実行され,L1・L2 キャッ
シュ上に行指向のデータと列指向のデータが混在した状況にな図3

提案手法概要図
図 4 問合わせ割り当てり, キャッシュヒット率が低下することから処理性能が低下すると考えられる.
本手法では 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, Buﬀer という 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 のいずれかに分類される.

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 であるという情報を RangeIndex が保持している.
4. 2. 4 Buﬀer
Buﬀer は DBP と CDP 間で問合わせや問合わせの処理結果を共有するために使用する.Buﬀer には 2 種類あり,DBP 各々が所有する Q Buﬀer と CDP 各々が所有する A Buﬀer に分類される.

Q Buﬀer は CDP がクライアントから取得した問合わせをDBP に伝達するために使用する. 一方で A Buﬀer は DBP が問合わせ処理を実行し, 得た処理結果を CDP に返送するために使用する.

Buﬀer は DBP や CDP 同士で競合が発生しないように, セマフォを用いたロック機能を使用する.

4. 3 処 理 手 順
本小節ではクライアントと通信を行い, 問合わせ処理を実行する際の処理手順を述べる.
まず, サーバの論理コアを CDP と DBP の二種類に分類す
る. 次に, アクセス範囲と DBP の対応関係を Range Index に格納する.
以上の処理を行った状態で, 以下の処理手順に沿ってクライ
アントと通信を行う. なお, 処理手順の番号は図 4 の番号に対応する.

表1

実験環境

クライアント

表 2 性能評価対象
サーバ

プロセッサ

Intel Xeon E7-4860 AMD Opteron 6174

ソケット数

44

論理コア数

80

48

クロック周波数

2.27GHz

2.20GHzL1 キャッシュ

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.149.5.14

cstore fdw

未使用

1.6.2

OLTP
ベースライン

問合わせ割り当て

OLAP

PostgreSQL cstore fdw

提案手法

未使用perf使用使用表3コア配分

CDP DBP(OLTP) DBP(OLAP)
実験 1:OLTP

16320

実験 2:OLAP1047

実験 3:OLTP&OLAP

916235. 2 実 験 方 法
1⃝
CDP は socket 通信を用いてクライアントから問合わ

OLTP,OLAP,OLTP/OLAP 同時実行の 3 種類に対する有効性を測るために 3 つの実験を行い, 提案手法とベースラインのせを受信
2⃝
CDP は Range Index を参照し, 問合わせを実行する

DBP 情報を取得
3⃝
CDP は DBP に対応する Q Buﬀer に問合わせを書き比較を行った.
表 2 に本実験におけるベースラインと提案手法の定義を示す. ベースラインは問合わせの割り当てを行わず, 直接サーバに対して問合わせを実行した. また, どちらの場合に対しても込む
4⃝
DBP は Q Buﬀer から問合わせを取得

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

5⃝
DBP は DB にアクセスし, 問合わせ処理を実行て DBP のキャッシュミス率計測を同時に行った.

6⃝
DBP は A Buﬀer に問合わせの処理結果を書き込む

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

7⃝
CDP は A Buﬀer から処理結果を取得

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

8⃝
CDP は socket 通信を用いてクライアントに実行結果を行った.

を送信

5. 3 実験内容・結果

DBP は Range Index に従い, 特定のアクセス範囲のみを参照する. 各々の DBP が限られた範囲のみをアクセスするため,DBP の L1・L2 キャッシュヒット率が向上し, 処理性能が向上すると考えられる.

5 実

験

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 トランザクションを実行し, 同時接続ため,C 言語を用いて問合わせ割り当て手法を実装し, 以下に示するクライアント数を変化させながら,1 秒間に処理したトランす複数の実験を行った.

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

5. 1 実 験 環 境のキャッシュミス率を計測し, 評価を行った.

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

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

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

Linux 環境ではプログラムを実行する際, プロセスを特定のの割り当てを行った.

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

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

ネル 2.6 以降の環境で使用可能な「sched setaﬀnity()」API をント数が少ない場合にはキャッシュミス率はベースラインに劣用いて CPU aﬃnity を設定することで問合わせの割り当てをる結果になるが, ベースラインはクライアント数の増加に対し行った.てキャッシュミス率が高くなるのに対して, 提案手法ではキャッ行指向の DBMS として PostgreSQL, 列指向の DBMS として Citus Data 社が PostgreSQL の拡張機能として提供する

cstore fdw [6] を使用した.

シュミス率が低下し続けていることが確認できる.
図 7 に示した tps では, キャッシュミス率がベースラインより劣る,48 クライアント時に提案手法とベースラインを比較する

なお, ディスク I/O がボトルネックとなることを防ぐためにと tps が 150 低下し, 処理性能が 10.2%低下している. しかし

PostgreSQL の「shared buﬀers」の値を 20GB に設定した. こながらサーバの論理コア数である 48 を超えるクライアント数

れによって実験の際のデータセットは全てメインメモリ上で処では, 提案手法がベースラインを上回る結果となり,96 クライア理が行われた.

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

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

図5

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

図9

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

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

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

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 のキャッシュミス率を計測し, 評価を行った.
図 7 実験 1:tps

Query の割り当て方式は各 DBP に対して実行する Queryを指定し, それぞれの DBP がすでに Query を実行している際し, 処理性能が 35.9%向上する結果となった.には待ち行列を生成する手法を用いた. このように設定するこベースラインではデータ処理を行う DBP をサーバ上の 48とで各 DBP は限られた属性のみを対象としたデータアクセコア全て使用するが, 提案手法では 16 コアを CDP として使用スを行う. 図 8 の例では Query1 を実行するコアは DBP1 とするため DBP は 32 コアのみしか使用しておらず, 処理性能がDBP2 とし,Query2 は DBP3 でのみ実行するように設定してベースラインよりも低下してしまう危険性がある. しかしながいる. これによって DBP1 と DBP2 は s acctbal カラム,DBP3

ら実験結果から, キャッシュヒット率を向上させることでベースは s nationkey カラムのみにアクセスを行う.

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

実験 2 の結果を図 9〜12 に示す. 図 9 と図 10 に示した L1・L2
キャッシュミス率に関してベースラインと比較を行うと, ベース

5. 3. 2 実験 2:OLAP

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

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

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

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

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

は 1 つの stripe に収まるデータサイズであると考えられる. しタである,supplier テーブル (10000 タプル) に対して比較的軽たがってベースラインと提案手法で集計処理を実行する際にメ表4

実験 2:CPU 利用率
ベースライン

提案手法

24 クライアント

17.6%

27.3%

72 クライアント

51.2%

50.6%

しかしながら, クライアント数が 48 より多くなった際にはベースラインを下回る結果となり,72 クライアント時には qpsが約 3800 低下し, 処理性能が 30.4%低下している. この理由として, 表 4 から CPU 利用率の観点でベースラインが提案手法より優れた結果となったことが挙げられる. また提案手法は問合わせを実行する DBP を指定し, 待ち行列を生成していた. し図 10 実験 2:L1 命令・L2 キャッシュ

たがって問合わせを実行すべき DBP がすでに他のクライアントの問合わせで埋まっている場合には, 待ち時間が生じてしまう. クライアント数が増加した際にはこの待ち時間のオーバーヘッドが非常に大きくなってしまうため,qps が低下する結果になったと考えられる.
図 12 に示した各 Query の応答時間を見ると,24 クライア
ント時には全ての Query がベースラインよりも短い応答時間
だが,72 クライアント時には Query4 の応答時間が大幅に長くなっていることが確認できる.DBP に使用した 47 コアのうちQuery1〜3 は各 12 コアで実行していたのに対し,Query4 のみが 11 コアで実行していたため, 他の Query よりも使用できるコアが少ない状況が続き, クライアントほぼ全員が Query 4 の
図 11

実験 2:qps

DBP が使用可能になるのを待つ状況になり, 待ち時間の増加によって応答時間が大幅に遅くなってしまったことと考えられる.
この待ち時間を解消するための方策としては, 問合わせの偏りに応じてコアの割り当て範囲を変更するロードバランス機能を実装することが挙げられる.

5. 3. 3 実験 3:OLTP/OLAP 同時実行
本研究の目的である OLTP と OLAP の同時実行に対する本手法の有効性を確認するために, 以下の実験を行った.
実験 1 で使用した TPC-C のトランザクションと実験 2 で使用した問合わせ処理を同時に実行する. なお, 本実験では OLTPと OLAP の対象テーブルは異なるため,OLAP の対象データはOLTP によって更新されたデータではない.
図 12

実験 2:応答時間

また, 問合わせ処理に関しては OLAP 処理 DBP にかかる負荷を分散させるため,Query 1〜Query 4 を 1:2:2:2 の比率で実モリからフラッシュするデータサイズが同じになったため,L1・L2 キャッシュヒット率に差が生じなかったと考えられる.

行するように変更した.
問合わせ処理とトランザクション処理を 5 分間並列に実行し,

図 11 に示した qps に関してはクライアント数が少ない際に同時接続するクライアント数を変化させながら, トランザクショは, ベースラインを上回り,24 クライアントの際には qps が約ン処理の tps, 問合わせ処理の応答時間及び qps,DBP のキャッ2200 上昇し, 処理性能が 37.6%上昇する結果となった. この理

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

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

なお, 本実験ではトランザクション処理と問合わせ処理のクで OLAP を実行するようにスケジューリングされ,DBP としライアント数は等しいものとし,12 クライアントで実験を行って使用できるコアを充分に使用できていなかったためと考えらた際には, サーバに対してトランザクション処理と問合わせ処れる. 実験時における提案手法とベースラインの DBP として理どちらも 12 クライアント, 合計 24 クライアントが接続して用いたコアの CPU 利用率を比較した結果が表 4 である. ベーいる状況とする.

スラインは CPU 利用率が 17.6%に対して提案手法は 27.3%となっている. したがって CPU スケジューリングの差から提案手法が優れた qps になったと考えられる.

実験 3 の結果を図 13〜16 に示す. 図 13 に示した OLTP のtps に関しては, クライアント数が少ない際の結果に対してウェ図 13

実験 3:tps

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

シュミス率はクライアント数が多い際にはベースラインの結果に劣る結果となっている. この理由としてベースラインは qpsが線形に近い形で増加をし続け, 集計処理の実行回数がトランザクション処理と比べ, 大幅に増加している. 集計処理は 1 つのテーブルのみを対象とした処理であり, トランザクション処理と比較して, キャッシュヒット率が非常に高い. ベースラインはキャッシュヒット率が非常に高い集計処理を, トランザクション処理の 10 倍以上多く実行している. 一方で提案手法はベースラインと比べると集計処理の実行回数が少なく, トランザクション処理の約 6 倍ほどしか実行をしていない. したがってベース
図 14

実験 3:qps

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

5. 3. 4 ま と め
OLTP に関しては実験 1 にて 96 クライアント時に 35.9%の性能が向上し, 提案手法はデータベースへの同時接続数が増えた際に処理性能が向上することが確認できた.

OLAP に関しては, 実験 2 にて 24 クライアント時に 37.6%処理性能が向上したが,72 クライアント時には 30.4%処理性能が低下する結果となった. この原因として,cstore fdw を用いたことによって L1・L2 キャッシュのキャッシュヒット率に差が生じなかったことと,DBP の待ち行列による待ち時間がクライアン
ト数の増加によって大幅に増加したことが挙げられる.
図 15 実験 3:L1 データキャッシュ

また,OLTP と OLAP を並列実行に関しては,OLTP は 72 ク
ライアント時には.6.0%の処理性能向上が確認できた.OLAP でルチの t 検定を行ったところ有意差は確認できなかった. しかしは 12 クライアント時には 27.1%の処理性能向上し,72 クライアながら, 実験 1 と同様に同時接続するクライアント数が増加すント時には 40.7%処理性能が低下する結果になった. この結果

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

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

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

因であると考えられる.

図 14 に示した OLAP の qps に関しては, クライアント数がなお, 今回の実験では OLTP の更新が OLAP の対象データ少ない際にはベースラインよりも優れた結果となり,12 クライに反映されていないため, より実世界で求められる処理性能をアント時には qps が約 900 上昇し,27.1%の処理性能向上が確認評価するにはさらなる実験が必要である.

できた.
しかしながら, 実験 2 と同様にクライアント数が多い際には6 おわりに待ち時間が長いことや L1・L2 キャッシュヒット率に差が出な

本研究では複数コア環境において OLTP と OLAP の同時実いことが原因になり,72 クライアント時には qps が約 5200 低行を高速化を目的に研究を行った. アプローチとしてアクセス下し,40.7%処理性能が低下する結果となった.

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

図 15 と図 16 のキャッシュミス率を見ると, 提案手法のキャッヒット率を向上することで高速化を実現する手法を示した.
提案手法について実験を行った結果, 同時接続数が増加し, ク
ライアント同時リクエスト負荷が高い際に 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 review of feasible implementation methods and architectures
for real time data analysis. In Proceeding of the 2005 SoutheastCon, 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, NgaTran, Ben Vandiver, Lyric Doshi, and Chuck Bear. The vertica analytic database: C-store 7 years later. Proceedingsof the VLDB Endowment, Vol. 5, No. 12, pp. 1790–1801,2012.
[4] Vishal Sikka, Franz Färber, Wolfgang Lehner, Sang Kyun
Cha, Thomas Peh, and Christof Bornhövd. Eﬃcient transaction processing in SAP HANA database: the end of acolumn store myth. In Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data,
pp. 731–742. ACM, 2012.
[5] Fang Xi, Takeshi Mishima, and Haruo Yokota. CARIC-DA:
Core aﬃnity with a range index for cache-conscious data access in a multicore environment. In Proceedings of the International Conference on Database Systems for AdvancedApplications, 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/.