日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

メニーコア環境での HTAP 実現に向が高まっている. HTAP では OLTP と OLAP を組み合わせた多けた OLTP 性能とデータ鮮度重視のよる更新を OLAP データに適用する更新適用性能を得る必要が様なワークロードに対して, OLTP・OLAP 処理性能と, OLTP にある. この 2 つを得るためには計算リソースを適切に配分し, 処

動的負荷分散理を分散させる必要がある.
同様に近年の傾向として複数コア CPU の多用化が挙げられる.

諸岡 大輝 1

塩井 隆円 2

Le Hieu Hanh4

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

引田 諭之 3る手法は限界に達し, 高い処理性能が求められる分野では, 各々の横田 治夫 5コアのクロック周波数は低いが, 処理を複数コアで分散させることで全体として高性能処理を実現する複数コア CPU を用いる傾

トランザクション処理を行う OLTP での更新を, 高いデータ鮮

向にある [5]. したがって処理を分散させることで複数コアを有度でデータ分析処理を行う OLAP に適用可能な HTAP 技術が注効活用し, 処理性能を向上させるアプリケーションの開発が必要目されている. 更新適用の際にワークロードが変化しても, OLTP

不可欠である. しかしながら複数コア環境での HTAP において,の性能が劣化することは可能な限り避けなければならない. しか

動的に各コアへ処理を割り当てることで処理を分散させ, OLTP・しながら複数コア環境で OLTP 性能を維持しながら, 高いデータ

OLAP の高い処理性能と高い更新適用性能を実現する研究は十分

鮮度で HTAP を実現するためにはリソースを有効に活用する必要には行われていない.

がある. そこで本研究ではリアルタイムに変化するワークロード

そこで本研究では, HTAP における性能を OLTP 処理性能・更に応じて OLTP 性能の維持とデータ鮮度を優先し , 複数コアのリ

新適用性能・OLAP 処理性能の順に優先して考え, 複数コア環

ソースを動的に割り当てる負荷分散手法を提案する. また実際の境での HTAP 実行において OLTP 処理性能と OLAP データの

複数コア環境においてベンチマークを用いた評価を行うことで提Freshness を維持しながら, 可能な限りの OLAP 処理性能を取得

案手法の効果を検証する.

することを目的とする. この目的を実現するため, 本研究では処理内容に応じて実行するコアを割り当てるコアアサイン手法を

1

はじめに

1.1

研究背景

用いる. HTAP に必要な OLTP 処理・更新適用処理・OLAP 処理に加えてコアアサイン処理の 4 つの処理専用のコアを設定し, 各コアに対して処理のアサインを行う. また, HTAP 向けのロード

データベース処理は大きく分けてトランザクション処理を表

バランス手法を提案することで, リアルタイムに変化する多様なす OLTP (OnLine Transaction Processing) とデータ分析処理を表ワークロード各々に適したコアアサインの動的な取得を可能とす OLAP (OnLine Analytical Processing) の 2 種類に分類される.

し, ワークロードに追従して高い処理性能と更新適用性能を実現

OLTP は更新処理に伴う write 処理が多く短時間の排他制御が必する手法を提案し, その手法の評価を行う.

要だが, OLAP では長時間での read 処理を多く実行する. 従来

1.2

本稿の構成

ではこの 2 つの処理はロック取得などによって双方のパフォー

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

マンスが低下することを防ぐため, 対象データセットを分離し,れに関連する研究について述べる. 3 節では本研究におけるコア

OLTP のデータはリアルタイムで更新するが, OLAP のデータはに対する HTAP の処理の割り当てと負荷分散手法を提案する. 4

定期バッチ処理を用いて更新するアーキテクチャが多く採用され節では実験環境や実験内容と実験結果について述べる. 最後に 5ていた.

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

しかし, 近年では OLTP のデータ更新を OLAP の対象データに

背景知識

2

リアルタイムに適用可能な HTAP (Hybrid Transactional Analyti-

cal Processing) が注目を集めている [3, 6]. HTAP を用いることで本節では, 本研究を理解する際に前提とする知識とそれに関連より最新のデータ, すなわちデータ鮮度 (Freshness) が高いデータする研究について説明を行う.

を用いた OLAP が可能となる. ビックデータ・IoT・AI の伸長に

2.1

HTAP (Hybrid Transactional Analytical Processing)よりデータ分析の需要が高まり, Freshness の高いデータを対象と1 節で述べたように HTAP とは OLTP の更新をリアルタイムにした OLAP が求められるようになったことから HTAP の必要性

OLAP 対象データに適用することで, 高速な OLTP と Freshnessの高いデータを用いた OLAP の両立を可能にすることである.

1 非会員

HTAP は OLTP と OLAP 両方を実行するため, 2 種類の処理が東京工業大学情報理工学院

morooka@de.cs.titech.ac.jp
2 学生会員

混合した多様なワークロードに対応し, OLTP 処理性能と OLAP

東京工業大学情報理工学院

データの Freshness を維持することが求められている.

shioi@de.cs.titech.ac.jp
3 正会員

東京工業大学情報理工学院

また HTAP のアーキテクチャは大きく分けて 2 種類に分類さhikida@de.cs.titech.ac.jp
4 正会員

れる [7]. 両者の違いを表したものが図 1 である. 一つ目は同

東京工業大学情報理工学院

一のデータを対象にスナップショット機能などを用いて OLTP

hanhlh@de.cs.titech.ac.jp
5 正会員

東京工業大学情報理工学院と OLAP を実行する Uniﬁed Storage である. Uniﬁed Storage で

yokota@cs.titech.ac.jp

1

日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

図 1 HTAP アーキテクチャ

は OLAP 実行のたびにスナップショットなどによって OLAP
クエリ実行時点のデータを取得するため, Freshness が最新のデータを対象に OLAP が可能であるが, OLTP 性能へのオー
図2

バーヘッドが大きいという特徴を持つ. もう一つのアーキテク

アクセス範囲に応じたコアアサイン

チャは Decoupled Storage である. Decoupled Storage は OLTP とOLAP は別々のデータを対象に実行され, OLTP による更新を随時 OLAP データに反映するアーキテクチャである. Decoupled

用いることで, 各コアの L1・L2 キャッシュヒット率が向上する

Storage は Uniﬁed Storage よりも OLAP の Freshness が劣るが,ことを示した.

高い OLTP 性能が実現できるという特徴を持つ.

また複数コア環境に対応した HTAP に関する研究として関連

また Decoupled Storage における OLAP データを更新する手法

研究 [7] が挙げられる. この研究では複数コア環境上での HTAPの一つとして Log shipping があげられる. OLAP データは常にあにおいて, OLAP データの鮮度を表す Freshness Rate [1] に応じる時点の OLTP データが保存されている. そこで OLTP データ

た状態遷移を行い, Uniﬁed Storage と Decoupled Storage を切りに対して実行されたトランザクションの実行ログを OLAP デー

替えることでワークロードに応じたリソース配分が可能な HTAP

タに送信し, 送信されたトランザクションログを OLAP データにシステムを提案している.

対して Redo することで OLTP データと同等な最新のデータを

2.3

既存研究の課題点

取得する手法が Log shipping である. したがって, Log shipping

先行研究 [11] の課題点として, OLAP の対象データが更新されを採用する Decoupled Storage では Uniﬁed Storage と比べてトラないため最新データを用いた OLAP が不可能であり, HTAP を実

ンザクションログを Redo する処理が必要なためマシン上で実行現できていないという点が挙げられる. HTAP を実現するためにする処理の種類が増え, よりリソース配分の重要性が高いと言えは, OLTP による更新を OLAP データに適用する処理も含めてコる. 同様に OLAP データを更新する手法であるバッチ処理と Log

アアサインを考える必要がある. また, コアアサインが静的なた

shipping を比較するとバッチ処理時に OLTP を停止する必要がめ初期状態からコア配分を変更できないため, ワークロードに応ないため, Log shipping は OLTP 処理性能と Freshness の両立がじたコアアサインが実現できない点も課題点である.

可能な手法であるといえる.

関連研究 [7] の課題点として, 各処理に割り当てるコア数の配OLTP ではレスポンスタイムが QoS のユーザ設定要件になる

分が状態ごとに静的であるため, ワークロードによっては処理内

ため, HTAP においても OLTP 処理性能を高くすることは最も容の割り当てに改善の余地が残されている点が挙げられる. 具優先すべき要件である. したがって, 本研究では HTAP におい

体的には, OLAP ヘビーなワークロードにおいて, Freshness を優て OLTP 処理性能を最も優先するために, アーキテクチャとし先する Uniﬁed Storage を使用するアーキテクチャに切り替えるて Decoupled Storage, 更新適用手法として Log shipping を採用ことは可能だが, OLTP 実行に割り当てるコアの数は静的なため,する.

OLAP 実行に割り当てるコアが不足してしまう可能性が考えられ

2.2

複数コア DB システム

る. また OLTP と OLAP の処理性能を維持するためのリソース

1 節で述べたように, 近年の CPU は搭載するコア数の増加が著

配分は行われているが, 更新適用に関してはアーキテクチャを切しく, 複数コア環境に対応したデータベースシステムが必要であり替えるのみで, 更新適用性能に対するリソース配分が行われてる. そこで本研究の先行研究 [10, 11] では複数コア環境に対応しいないという点も課題点の一つである.

たデータベースシステムの提案を行った.

本研究ではこれらの課題点を解決するため, HTAP の多様な

図 2 が先行研究 [11] の概要図である. この研究では OLTP とワークロードに対して複数コア環境を想定し, 動的にコアの割り

OLAP の同時実行において OLTP 処理コアと OLAP 処理コアを当てを変更することでリソース配分を行い, OLTP 処理性能と高別々に設け, OLTP トランザクションのアクセス範囲に応じてトFreshness を維持しながら, 可能な限りの OLAP 処理性能を得る

ランザクションを処理するコアを変化させるコアアサイン手法をことを目的とする.

2日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

図3

全体アーキテクチャ

図 4 HTAL 動作例

Data: WT ：OLTP 実行キューの待機数

提案手法

3

Data: F ：Freshness Rate
StateDecision

前節を踏まえて, 本研究では処理内容に応じたコアアサインF ⇐ 1 − 更新が未適用なタプル数
総タプル数

を行い, さらにコアアサインを動的に調節するロードバランサ

if (WT ≥ α) then

である HTAL (Hybrid Transactional Analytical processing Load

SetState(S1 ) // OLTP modebalancer) を導入した手法を提案する.

else

本節ではまず全体のアーキテクチャについての説明を行い,

if (F ≤ β) then

次に HTAL を適用するコアアサイン手法について述べ, 最後にSetState(S2 ) // LS mode

HTAL のアルゴリズムや処理についての説明を行う.
3.1

else

全体像

SetState(S3 ) // OLAP mode

図 3 が HTAL を用いたシステムの全体アーキテクチャを表し

図 5 Algorithm 1: 状態遷移ている. クライアントはミドルウェア経由でクエリを送信し, ミ
ドルウェアがクエリに応じて指定された実行コアに送信する.
このアーキテクチャでは Decoupled Storage を採用するため,

OLTP データと OLAP データは分離し, OLTP による更新は Log

一方で OLAP データは OLAP 専用コアのいずれかで実行される

shipping によって OLAP データに反映される. Log shipping をように設定されている.
更新適用処理を行うコア (以下, LS) は Log shipping を実行す

使用することでバッチ処理と比べ, OLTP 処理性能を維持した

るコアを表す. Log shipping では Log の送受信や更新適用処理がOLAP データの更新が実現される.

並列に行われているため, LS を増やすことで Log shipping の更また Log shipping による OLAP データ更新が原因で実行結果

新適用性能を高めることが可能である.

に不整合が生じることを防ぐため, OLAP データを 2 つ保有し,片方のデータに対しては OLAP を実行するが, もう一つのデータ

コアアサイン処理を行うコア（以下, CDP）はミドルウェアを動に対しては Log shipping による更新適用を行う. OLAP データ

作させるためのコアを表す. CDP は 2 種類の役割を担う. 1 つ目に関しては更新が適用されるデータと OLAP 実行の対象になるの役割はクライアントや DBP との通信を行う Query Dispatcher

データを交互に切り替えながら, OLAP 処理を実行する.

の役割である. CDP はクライアントから受け取ったクエリに応じ

3.2

コアアサインて適切な OLTP_DBP や OLAP_DBP を指定し, クエリの送受信

2 節で述べた先行研究 [11] 同様に複数コア環境を有効に活用を行う. もう一つの役割は HTAL を動作させ, 動的にコアの割りするため, 各コアに対して処理内容に応じたコアアサインを行う.

当てを変化させることでコア全体での負荷分散を行う Balancer

本手法では OLTP 処理・OLAP 処理・更新適用処理・コアアサイの役割である.
このように 4 種類の処理専用のコアを設定することで, 高負荷

ン処理の 4 種類のいずれかを実行するようにコアアサインの設定

なワークロードにおいても, OLTP_DBP や LS に与える影響を最を行う.

小限化し, OLTP 処理性能と OLAP データの Freshness を維持す

OLTP 処理コア (以下, OLTP_DBP) と OLAP 処理コア (以下,OLAP_DBP) はそれぞれ OLTP データと OLAP データに対してることが可能であると考えられる.

のみアクセスし, 各クエリの実行を行う. 先行研究 [11] 同様に,

3.3

ロードバランサ

OLTP データは主キーで Range パーティショニングされており,

HTAL では多様なワークロード各々に適したリソース配分を実クエリがアクセスする主キーに応じて専用の OLTP_DBP に実行現するため, 各処理を割り当てたコアの再配分を実行する. 図 4を割り当てることで, クエリ実行のキャッシュヒット率を高める.

は OLTP ヘビーなワークロードと OLAP ヘビーなワークロード3日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

を実行している場合における HTAL の動作を表している. HTAL

Data: UC ：CPU 使用率平均 (CDP)は各コアの負荷状況を把握し, OLTP ヘビーなワークロードと判

Data: DT ：OLTP 実行キュー待機数の分散断した場合には OLAP 処理のリソースを OLTP 処理を実行する

Data: CLS ：LS のコア数ようにアサインの変更を行う. 一方で OLAP ヘビーなワークロー

Data: CM L ：LS の最高効率に必要なコア数ドと判断した場合には OLTP 処理のリソースを OLAP 処理を実

Data: U A：CPU 使用率平均 (OLAP_DBP)

行するようにアサインの変更を行う. 接続するクライアントが増

Data: W A：iowait 平均 (OLAP_DBP)

加した場合や即時性の高い OLTP ヘビーな場合には DBP だけで

Core_Balancing

はなく, Query Dispatcher を行う CDP に対する負荷が増加するこ

while True doとを考慮し, HTAL は OLTP_DBP・OLAP_DBP・LS・CDP の 4

State ⇐ GetState()

種類全てに対して動的な負荷分散を行う.

if (State = S1 ) thenif (UC ≥ γ) then

HTAL は図 5, 6 で表されるアルゴリズム 1 とアルゴリズム 2
を基に動作する. アルゴリズム 1 では現在実行されているワー

AssignmentChange(CDP)else if (DT ≥ δ) then

クロードにおいて, どの処理を実行するコアを優先的に割り当てる必要があるか判断し, 優先する処理の状態に遷移する. 状態はAssignmentChange(OLTP)

3 種類あり, それぞれ OLTP, Log shipping, OLAP のコアを増やelse

す状態を表す. 入力値としては OLTP_DBP が現在処理している

PartitionAssign() // partition 変更
else if (State = S2 ) then

クライアント数を表す W_T と OLAP データの Freshness を表す

if (CLS ≤ CM L ) thenFreshness Rate [1] が与えられる.
2 節で述べた通り, 本手法では OLTP 処理性能・更新適用性

AssignmentChange(LS)

能・OLAP 処理性能の順に優先的にコアの割り当てを行うため,

else if (State = S3 ) then

OLTP・LS・OLAP の順に状態遷移の判断を行う. OLTP ヘビー

if (UC ≥ γ) then

なワークロードでは W_T が閾値を越えるため, OLTP モードに遷AssignmentChange(CDP)

移する. 一方で OLAP ヘビーなワークロードであっても, W_T や

else if (U A ≥ ϵ and W A ≤ ζ) thenFreshness Rate が閾値を超えない場合にのみ OLAP モードに遷移

AssignmentChange(OLAP)するため, OLAP 処理性能の優先度は最も低く設定されている.

図 6 Algorithm 2: コア数バランシング

アルゴリズム 2 ではアルゴリズム 1 で得た状態に基づいて, 各
処理に割り当てられたコア数を変化させる必要があるか判断を行

表 1 実験環境

う. 入力値として CPU 使用率平均と iowait 平均が与えられる. 入クライアント

サーバ

プロセッサ

Intel Xeon E7-4860

Intel Xeon Platinum 8260M
Processor

ソケット数

4

2

論理コア数

80

96

OLTP_DBP に対して割り当てを行っているため, skew が生じ

L1 キャッシュ

32 KB+32 KB

32 KB+32 KBているワークロードでは一部の OLTP_DBP では負荷が過多だが,L2 キャッシュ

256 KB

1,024 KB

L3 キャッシュ

24,576 KB

36,608 KB

RAM

32 GB

384 GB

力値から OLTP_DBP・OLAP_DBP・CDP に関する負荷状況を判断し, コア数を増やす必要がある場合には AssignmentChange によって対象のコアアサインを交換する.
な お OLTP に 関 し て は Range パ ー テ ィ シ ョ ニ ン グ を 基 に

別の OLTP_DBP に余裕がある状況が生じる可能性が考えられる.
そのようなワークロードに対応するため, アクセスに偏りが生じ

OLTP：Intel Optaneている場合には PartitionAssign によって, Range パーティショニ

二次記憶装置

ングの範囲を変化させることで OLTP_DBP 間での負荷分散をDELL MZ-5EA2000-0D3 Persistent Memory(1. 5 TB)
SSD(200 GB)行う.
以上のようなアルゴリズムを用いて動的にコア数を増減し計

OLAP：Dell H8X3X
SSD(880 GB) × 2

OSUbuntu 16.04.3

Ubuntu 18.04.5

PostgreSQL

11.5

13.0

算リソースを配分することで, OLTP 処理性能・更新適用性能・OLAP 処理性能の順に優先付けされたロードバランスが可能と考えられる.

し, Log shipping として PostgreSQL の Streaming Replication 機
能を用いて行った.

実験

4

また, 本研究は Linux カーネル 2.6 以降の環境で使用可能な提案手法の性能を調べるため, 3 節の提案手法を実装し, 評価実「sched_setaﬀnity()」API を用いて CPU aﬃnity を設定することで験を行った.
4.1

処理内容に応じたコアアサインを適用した.

実験環境

4.2

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

実験構成

表 2 は実験で使用した手法を表している. Baseline としてコア

OLTP と OLAP を実行する DBMS として PostgreSQL を使用

アサイン・HTAL によるロードバランス・OLAP データセットの4

日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

図 7 Baseline 概要図

表 2 手法一覧

表3

アルゴリズムパラメータ

Algorithm 1
コアアサインHTALOLAP データ切り替え

LS

α

β

γ

δ

ϵ

ζ

✓

2

85%

60%

8

80%

10%

Baseline (Uniﬁed)
Baseline (Decoupled)
比較手法

✓

提案手法

✓

✓

Algorithm 2

OLAP データ分離

✓

✓

✓

✓

✓

✓

表4

比較手法コア配分

OLTP_DBP

40

切り替え・Log shipping を実行しない手法を用いる. なお, 図 7 の

OLTP_CDP

8

ように Baseline は Uniﬁed Storage と Decoupled Storage の 2 種

OLAP_DBP

44

類のアーキテクチャを用いる.

OLAP_CDP

2

Baseline (Decoupled Storage) は OLAP データの更新が行わ

HTAL_CDP

1

れないため OLTP・OLAP 処理性能を高い状態で維持できるLS

1が, OLAP データの Freshness は低下し続ける. 一方で Baseline(Uniﬁed Storage) は OLTP と OLAP は同一データを使用している
表 4 は比較手法におけるコア数配分と提案手法における初期状

ため Freshness は常に最も高い状態を維持するが, OLTP・OLAP

態のコア数配分を表している. 論理コア数が 96 のサーバに対し処理性能は低下する.
また比較手法として HTAL を適用せずにコアアサインのみをて, OLTP と OLAP の処理コアがおおよそ 1 対 1 になるように設行う手法を用いる. 比較手法は 120 秒おきに OLAP データセッ

定し, CDP 数に関しては先行研究 [11] と同様に設定した. 比較手トの切り替えを行い, 提案手法は HTAL が Freshness Rate の低法は HTAL を使用しないためコア数配分は表 4 の状態から変化下を検知した際に OLAP データセットの切り替えが発生する.

しない. 一方で提案手法は表 4 の状態を初期状態にし, 負荷状況

Baseline と提案手法を比較することでコアアサイン手法や OLAPに応じて各処理のコア数を増減させる.

データセットを OLTP データから分離させて二重化するアーキ

4.3

テクチャの効果検証を行い, 比較手法と提案手法を比較すること

実験内容

本実験では 2 種類の実験を行った. 一つ目の実験では最優先の性能要件である OLTP に負荷が偏った OLTP ヘビーなワーク

で HTAL によるロードバランス機能の効果を検証する.

Baseline (Uniﬁed Storage) におけるトランザクション分離レベ

ロードに対する性能評価. 二つ目の実験では OLTP と OLAP のルは SERIALIZABLE に設定し, それ以外の 3 手法に関しては設

負荷割合がリアルタイムに変化するワークロードを用いて評価を定可能なトランザクション分離レベルの中で最も Consistency が行った. 本小節ではそれぞれの実験の内容について説明を述べる.

高い repeatable read に設定して実験を行った.

4.3.1

実験 1：OLTP ヘビーワークロード

実験 1 では HTAP 向けベンチマークである CH-benCHmark [2]

3.3 小節で述べた HTAL のアルゴリズムで使用するパラメータのデータを用いて評価実験を行った.

は表 3 のように設定した. このパラメータ設定はパラメータの候補を網羅的に探索し, 後述の実験 1 で OLTP 処理性能・OLAP 処

CH-benCHmark は OLTP 処理性能を測る TPC-C [8] と OLAP

理性能・更新適用性能を最もバランスよくバランシングできたと処理性能を測る TPC-H [9] を混合したベンチマークであり, TPC-考えられるパラメータを使用している.

C で更新されたデータを対象として TPC-H を実行することが可5日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

図 8 CH-benCHmark+ 概要図

図 9 実験 1：OLTP 処理性能能である. このベンチマークを用いて, OLTP・OLAP 処理性能と更新適用性能について計測を行う. なお, CH-benCHmark のデー
タ生成やクエリは oltpbench [4] に基づいて SF (Scale Factor)200のデータ (約 20 GB) を使用した.
な お, 今 回 の 実 験 で は CH-benCHmark に お け る 22 種 類 のOLAP クエリでは実行時間に散らばりが大きいため, 実行時間が似た値であり関連研究 [7] でも評価に使用されている Q1, Q6,

Q19 の 3 種類を用いて実験を行った.
OLTP 処理性能として 1 秒間に処理したトランザクション数を

図 10

実験 1：OLAP 処理性能表す tps (transaction per second), OLAP 処理性能として OLAP 処
理性能として 1 時間で処理が可能なクエリ数を表す qph (query

per hour), 更新適用性能として Freshness Rate の 3 つについて

OLAP の負荷比率がリアルタイムに変更されるワークロードであ計測を行った. Freshness Rate は Algorithm1 で示した式で算出

る. 以上のような処理を行う CH-benCHmark+ を用いて実験 2 をされる. 本実験では PostgreSQL の統計情報であり, Streaming

行った.
実験 2 で使用する OLAP クエリは実験 1 同様 Q1, Q6, Q19 のReplication によって更新されているデータは何秒遅延している3 種類を用いて評価を行い, データサイズに関しても同様に SFかを表す replay_lag を用いて算出を行った.
実験 1 では CH-benCHmark における client 数を OLTP client

200(約 20 GB) で生成したデータを使用した. 評価指標に関して

数を 100, OLAP client 数を 20 に設定し, OLTP に比重が偏ったも実験 1 同様に tps, qph, Freshness Rate の 3 つを計測すること

ワークロードを実行した際の各手法における性能評価を行った.

で OLTP・OLAP 処理性能と更新適用性能の計測を行った. リア

4.3.2

ルタイムに変化する OLTP・OLAP の負荷は 180 秒毎に client 数

実験 2：CH-benCHmark+実験 1 で使用した CH-benCHmark では OLTP と OLAP の負が 50：50, 70:30, 30:70 の順に変化させることで, 負荷比率が釣り

荷比率の調整をリアルタイムに変更することが不可能である.

合う状態, OLTP ヘビーな状態, OLAP ヘビーな状態の順にワーク

CH-benCHmark における OLTP と OLAP の負荷比率はデータロードを変化させて評価を行った.

ベースに同時接続する OLTP と OLAP の stream 数を事前にパなお実験 2 では多様なワークロード実行時におけるコアアサイ

ラメータとして設定するため, ベンチマーク実行時に OLTP とン手法の効果を把握するため, perf を用いて OLTP と OLAP のOLAP の負荷比率は変更されない. 本研究で提案する提案手法は

DB 処理におけるキャッシュミス率の計測も行った.

多様なワークロード各々に適したコアアサインの動的な取得を行

4.4 実験結果

うため, 性能評価で使用するベンチマークは OLTP と OLAP の負本小節では実験 1 と実験 2 の実験結果について述べる.

荷比率を動的に調整する必要がある.

4.4.1 実験 1：OLTP ヘビーワークロード

そこで実験 2 では CH-benCHmark+ という CH-benCHmark に

図 9〜図 11 が実験 1 の実験結果である. OLTP 処理性能であOLTP と OLAP の負荷比率調整機能を追加したベンチマーク

る tps に関して比較手法と提案手法を比較すると, 比較手法は時を使用する. 図 8 が CH-benCHmark+ の概要図を表している.

間経過に対して性能変化が見られないが, 提案手法は時間経過

CH-benCHmark+ はデータベース全体に同時接続する client 数ととともに OLTP 処理を行う OLTP_DBP が増加することで性能時間変化する OLTP・OLAP の比率をパラメータとして設定すが向上していることが確認でき, 実験終了直前には比較手法よる. そして 1client は定期的に Load Ratio にアクセスし, OLTP

り 32.6%OLTP 処理性能が向上する結果になった. また Baselineと OLAP の比率に応じて OLTP のトランザクションと OLAP ク(Uniﬁed) の OLTP 処理性能は OLAP 実行に伴う read 命令によっ

エリどちらを実行するか決定する. 事前に指定された時間が経て OLTP が妨げられることで極端に低い性能であることがわか過すると OLTP・OLAP を実行する client 数が変化し, OLTP・る. 図 10 の OLAP 処理性能も考慮すると, Baseline (Uniﬁed) は6

日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

図 11

実験 1：更新適用性能

図 12

実験 2：OLTP 処理性能

OLAP 性能が優先されてしまい OLTP 性能を維持した HTAP 実

増減に釣り合いが取れている状態である. 70：30 の負荷では行が実現できていないことが確認できる. Baseline (Decoupled)

OLAP_DBP が減少し, OLTP_DBP を増加させる OLTP ヘビーと提案手法を比較すると, Baseline (Decoupled) は実験開始時
から提案手法より優れた OLTP 処理性能であり, 時間経過になワークロードに対する処理が HTAL によって行われている.
30：70 の負荷に対しては OLTP_DBP や CDP は減少しているが,対して OLTP 処理性能に変化は見られず, 提案手法は Baseline

OLAP_DBP は増加せずに LS が増加していることが確認できる.

(Decoupled) より 8.56% 性能が低い結果である. このような結果

この配分は OLAP ヘビーなワークロードにおける Freshness がになった理由として, 提案手法は Baseline (Decoupled) では行っ

低い際のロードバランスであり, OLAP ヘビーなワークロードにていない Log shipping やコアアサイン処理を行っているため, そ対して OLAP 処理性能より更新適用性能を優先する HTAL が想れらの処理を実行するための LS や CDP が設定されている. 一方定している動作が実現していることが確認できる.

で Baseline (Decoupled) は OLAP 側のデータを更新するというOLTP 処理性能に関しては OLTP ヘビーな 180 秒〜360 秒以

本来の機能を実現していないため, それらのオーバーヘッドがな

外では比較手法と同程度の OLTP 処理性能, OLTP ヘビーな時間

く, 提案手法より OLTP 性能が高くなったと考えられる.

帯では比較手法を上回り, 9. 47% 性能向上している. 次に 2 つ

次に図 10 の OLAP 処理性能である qph に関して考察を行う.

の Baseline と比較すると Baseline (Uniﬁed) は実験 1 同様, OLAP

提案手法では時間経過とともに OLAP_DBP 数が減少しているこ

実行によって他の手法より低い OLTP 処理性能であることが確とが確認できる. これは OLTP ヘビーなワークロードに対して認できる. また,Baseline (Decoupled) と比較した場合には OLTP

HTAL が OLTP_DBP 数を増加させていることが原因である. しヘビーな 180 秒〜360 秒では実験 1 同様, 提案手法は Baseline

たがって, 提案手法は OLAP_DBP の減少に伴って OLAP 処理性(Decoupled) に対して 17. 8% 性能低下している. 一方で OLAP

能は低下していき, 比較手法と比べて 55.6% 性能が低下する結果

ヘビーな 360 秒〜540 秒の時点では Baseline (Decoupled) を上回になった. この二つの結果から提案手法は OLTP ヘビーなワーク

る結果になり, 48. 6% 性能向上する結果になった. 提案手法はロードに対して適切に OLAP 処理性能よりも OLTP 処理性能とコアアサインにより OLTP 処理に使用するコアが指定されてい更新適用性能を優先してロードバランスを実行していると考えらるため, OLAP 実行によって OLTP 性能に受ける影響が小さかっれる.

たことに対し, Baseline (Decoupled) はどちらの手法も OLAP ヘ

図 11 は提案手法と比較手法における OLAP 対象データのビー時には OLAP 実行による影響を受けてしまうためこのよう

Freshness Rate を表している. Baseline (Uniﬁed) は OLTP とな結果になったと考えられる.

OLAP のデータセットが同一のため, OLAP 実行における Freshness Rate は 100% である. また Baseline (Decoupled) は Log

次に OLAP 処理性能に関しては, ワークロードの変化に対して
OLAP_DBP は減少しているため比較手法より低い処理性能であshipping による更新を行わないため図 11 では Freshness Rate のり, 最大で 16. 7% の性能差が生じている. 提案手法は HTAL に算出は行っていない. 比較手法は 120 秒経過毎に OLAP データ

よってコア数の調整を行っているが, LS を増加させ更新適用性能

セットの切り替えが発生し, Freshness Rate が上昇する. また, 提を優先していたためこのような結果になった.

案手法は比較手法と比較すると LS コア数が HTAL によって増加

図 14 は CH-benCHmark+ 実行時の時間変化による Freshness

しているため, 切り替え後の Freshness Rate に関しては比較手法

Rate の推移である. 比較手法に関しては 120 秒毎に OLAP デー

よりも緩やかに低下しているため比較手法と比べると 6.37% 向

タセットの切り替えが発生しており, 切り替わるたびに Freshness

上する結果になった.

Rate は上昇するが, 時間経過とともに 2 つの OLAP データセ

4.4.2

実験 2：CH-benCHmark+

ット両方の Freshness が低下してしまうため, 切り替え直後の

図 12〜図 14 が CH-benCHmark+ を用いた実験 2 の実験結果

Freshness Rate は次第に低下していく. 提案手法に関しても比較を表している. 提案手法は 50：50 の負荷では OLTP_DBP と手法と同様の傾向が見られるが, HTAL によって LS コアの増加

OLAP_DBP の増減を繰り返し, ワークロードに対してコアのしているため, 比較手法より緩やかな低下が見られ, 35. 7% 向上

7日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

複数コアに適したシステム構成に関する検討を行い, Decoupled

Storage を前提とした OLAP データセットの切り替えを行うアー
キテクチャを採用し, OLTP・OLAP のデータ形式に関しては更新
適用性能を考慮し, 双方を行指向データにするデータ形式を採用
した.
また, 検討したシステム構成に対して 4 種類の処理専用コアを設定するコアアサイン手法を提案し, コアアサイン手法に対してのロードバランサである HTAL を提案した.
提案した HTAP システムに対して OLTP ヘビーなワークロー
図 13

ドやリアルタイムに OLTP・OLAP の負荷比率を変化させること

実験 2：OLAP 処理性能が可能な CH-benCHmark+ を用いて性能評価実験を行った結果,

HTAL を使用しない比較手法と比較して OLTP ヘビーなワーク
ロードでは OLTP 処理性能を 32.6%, 更新適用性能を 6.37% 向上
した. 同様に CH-benCHmark+ を用いたリアルタイムに OLTP とOLAP の負荷比率を変化させるワークロードに対しても, OLTP
処理性能を 9.47%, 更新適用性能を 35.7% 向上させたことから

HTAL によるロードバランスの有効性を示した. また OLTP 性
能に優れた Decouple Storage を採用した Baseline との比較ではOLTP ヘビー時における OLTP 性能は 8.56% 低下してしまうが,OLAP ヘビー時にはコアアサインによってキャッシュヒット率を向上させ, OLTP 性能を 48.6% 向上させたことからコアアサイン
図 14

手法の有効性を示すことができた.

実験 2：更新適用性能

5.2
表 5 実験 2：キャッシュミス率

今後の課題

本研究ではロードバランスのパラメータとして CPU 使用率やキャッシュミス率 [%]クエリキューの待機数を用いたアルゴリズムを使用したが, ラン

Baseline (Uniﬁed)

63.3

キューや CDP 一つが担当する DBP 数などの別パラメータを用

Baseline (Decoupled)

25.4

いたアルゴリズムの効果を検証することが今後の課題である.

比較手法

6.3

また OLTP ヘビーなワークロードのように, コアアサイン処理

7.1

を行う CDP がどの程度オーバーヘッドになるかを検証するため,

提案手法

今回使用したマシンとは異なるコア数のマシンで性能検証を行う必要があると考えられる.
する結果になった.

本研究では OLTP 処理性能と更新適用性能を優先した構成を採

表 5 は実験 2 の実行時におけるキャッシュミス率を表してい用している. したがって, OLAP データエンジンとしても OLAP

る. Baseline (Uniﬁed) は Baseline (Decoupled) に比べて 37.9%

処理に有利ではない行指向データベースを使用し, 実験 1 と実験

キャッシュミス率が高い結果になった. この結果は, OLTP による

2 では OLAP 処理性能が低下する結果になった. よって, OLAP

Dataset の更新が OLAP の read に及ぼす範囲が広くなり, キャッ

データセットのデータ形式や OLAP データエンジンを OLAP

シュをリフレッシュしてしまっているためと考えられる. 提案手

実行に有利な構成に対応させることも今後の課題としてあげら

法は HTAL によってコアアサインが動的に変化するため, 静的なれる.

コアアサインを用いた比較手法よりキャッシュミス率が高い結

謝辞

果になったが, Baseline (Decoupled) と比較すると 18.3% キャッ
シュミス率が低い結果になった. この結果からコアアサイン手法

この成果は，国立研究開発法人新エネルギー・産業技術総合開を使用した比較手法と提案手法は意図した通り, キャッシュミス

発機構（NEDO）の委託事業（JPNP16007）の結果得られたもの

率を削減できていることが確認できる.

です．

5

おわりに

参考文献

5.1

まとめ

[1] Mokrane Bouzeghoub. A framework for analysis of data freshness.
In Proceedings of the 2004 international workshop on Information
quality in information systems, pages 59–67, 2004.
[2] Richard Cole, Florian Funke, Leo Giakoumakis, Wey Guy, Alfons Kemper, Stefan Krompass, Harumi Kuno, Raghunath Nambiar,
Thomas Neumann, Meikel Poess, et al. The mixed workload CH-

本研究では, 複数コア環境においてリアルタイムに変化する異なるワークロードに対して, OLTP 処理性能と Freshness を維持しながら, 可能な限りの OLAP 処理性能を得ることを目的に動的なコアへの処理の割り当てを行う HTAP システムを検討した.

8

日本データベース学会和文論文誌
一般論文

Vol. 20-J, Article No. 8, 2022 年 3 月

1775. ACM, 2017.
[7] Aunn Raza, Periklis Chrysogelos, Angelos Christos Anadiotis, andAnastasia Ailamaki. Adaptive htap through elastic resource scheduling. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, pages 2043–2054, 2020.
[8] TPC. TPC-C Benchmark 5.11.0. http://www.tpc.org/tpcc/.
[9] TPC. TPC-H Benchmark 2.17.3. http://www.tpc.org/tpch/.
[10] Fang Xi, Takeshi Mishima, and Haruo Yokota. CARIC-DA: Coreaﬃnity with a range index for cache-conscious data access in a multicore environment. In Proceedings of the International Conferenceon Database Systems for Advanced Applications, pages 282–296.
Springer, 2014.
[11] 諸岡 大輝, 塩井 隆円, Le Hieu Hanh, and 横田 治夫. 複数コア環境におけるアクセス範囲を考慮した OLTP/OLAP 同時実行手法. In 第
11 回データ工学と情報マネジメントに関するフォーラム, 2019.

benCHmark. In Proceedings of the Fourth International Workshop on
Testing Database Systems, page 8. ACM, 2011.
[3] Samuel S Conn. OLTP and OLAP data integration: a review offeasible implementation methods and architectures for real time data
analysis. In Proceeding of the 2005 SoutheastCon, pages 515–520.
IEEE, 2005.
[4] Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe
Cudre-Mauroux. Oltp-bench: An extensible testbed for benchmarking
relational databases. Proceedings of the VLDB Endowment, 7(4):277–
288, 2013.
[5] David Geer. Chip makers turn to multicore processors. Computer,
38(5):11–13, 2005.
[6] Fatma Özcan, Yuanyuan Tian, and Pinar Tözün. Hybrid transactional/analytical processing: A survey. In Proceedings of the 2017
ACM International Conference on Management of Data, pages 1771–

9