Embed Size (px)
Citation preview
DEIM Forum 2016 A8-2
* 株式会社日立製作所 研究開発グループ 情報通信イノベーションセンタ, E-mail: [email protected]
ジョイン方式選択の精度向上をめざしたデータベース問い合わせ処理における CPU 処理コスト計算方法の検討とその評価
田中 剛†* 石川 博‡
†‡首都大学東京 システムデザイン研究科 〒191-0065 東京都日野市旭が丘 6-6
E-mail: †[email protected], ‡[email protected]
あらまし 半導体記録媒体の高速・大容量化に伴い，データベースのクエリ処理における最適な処理手順を求め
るためのコスト計算ではディスク IO処理コストに対してCPU処理コストの割合が相対的に増大すると考えられる．
そのため，今後はより精度の高い CPU 処理コストの計算方式が求められる．報告者らは，CPU アーキテクチャを
考慮したコスト計算モデルを導入し，コスト計算の精度向上に向けて研究を進めている．本研究では，実際のジョ
イン処理の CPU 動作解析結果を基に CPU 処理コスト計算式を作成し，データベースの種類の変更に対応も含めた
方法の検討および評価を実施した．
キーワード データベース, クエリ最適化, CPU コスト, TPC-H
1. はじめに
半導体技術の発展に伴い，SSD（Solid State Drive）の高速化お
よび，大容量化が進んでいる．例えば HDD（Hard Disk Drive）の
応答時間は約数十ミリ秒であるが，SSD の応答時間は約百マイク
ロ秒である．さらに 2015 年に発表された 3D XPoint memory は従
来の NAND 型フラッシュメモリの 10 倍高速(～10us)[1]になって
おり，主記憶の応答時間に近づきつつある．また SSD のデータ格
納容量はテラバイトクラスに到達し，更に大容量化が計画されて
いる．これまでデータベースの永続的記録媒体として HDD が広
く使用されてきたが，SSD を活用するケースが増加しつつある．
HDD から SSD，さらに高速な半導体記憶にデータベースを格納
する媒体が移行することで，DBMS（Database Management System）
に対してはクエリ処理の応答時間が短縮されるという面だけでな
く，DBMS の内部処理も記録媒体の高速化を活かすための施策が
必要になると考えられる．
図 1 にオープンソースの DBMS で 2 表ジョインをしたときの
CPU 時間とディスク時間の比を示す（計測条件ならびに計測環境
は後述の表 3 および図 7 を参照）．この計測では Nested loop join
と Hash join のジョイン方式の 2 方式において，データベースを格
納する媒体を HDD から SSD に変更することでディスク時間に対
する CPU 時間の割合が Nested Loop Join で約 20 倍，Hash Join で
約 750 倍に増大している．
図 1: 2 表ジョイン時の CPU 時間とディスク時間比
ディスク時間に対する CPU 時間の相対的な増大は，クエリ処理
時間を見積る場合において CPU 処理の正確な見積りが重要であ
ることを示唆している．従来はクエリ処理時間を見積る場合にお
いて HDD 処理時間を正確に見積ること，つまり HDD へのアクセ
ス回数を主に評価していた．しかし，高速な SSD などの記録媒体
を活用するにあたっては CPU 時間の正確な見積りが必要になる
と考えられる．
DBMS はクエリを処理するにあたり，クエリを解析し，複数の
実行プランを作成する．そして，これらの各実行プランに対して
クエリ処理時間の見積り（以後，コスト計算と呼ぶ）を実施し，
複数の候補の中からコストが最小な実行プランを選択する．例え
ば，DBMS が図 2 の(a)に示す R 表と S 表の 2 表をジョインするケ
ースにおいて，参照する行数が最小となる実行プランとして(b)
を生成する．このとき，どのジョイン方式を選択するかで処理時
間が異なる．一般に(c)の列 R.C を選択する条件 x の値によって列
の選択される割合（以後，選択率と呼ぶ）によって最適なジョイ
ン方式は異なっているため，DBMS はデータベースの統計情報を
元にジョイン方式ごとにコスト計算し，自動的に最適な方式を選
択する必要がある．このとき(c)のグラフにある最適なジョイン方
式の切り替えとなる選択率 Xcross を正確に見積ることができない
と，選択すべきジョイン方式を誤ることになる．
図 2：クエリ最適化におけるコスト計算での課題
一方，データベースのクエリ最適化のためのコスト計算は IO
コストと CPU コストの和で評価することが多い [2][3][5]．例えば，
オープンソースのデータベース（PostgreSQL, MySQL）のコスト
計算式は，（総コスト）＝（CPU コスト）+（IO コスト）＝（レ
コード数）×（CPU 処理単価）＋（ページ数）×（ディスク処理
単価）で与えられ，各処理単価は固定値になっている．ディスク
性能が向上し CPU 処理コストの精度が重要になると固定的な
CPU 単価ではなく，より CPU のアーキテクチャやその動作を踏
まえた計算モデルが必要になると考えられる．
これまで CPU の性能指標の一つとして CPI（Cycles Per
1.E-02
1.E-01
1.E+00
1.E+01
1.E+02
1.E+03
0.00 0.02 0.04 0.06
(CP
U tim
e) ÷
(Dis
k t
ime)
外部表の選択率
SSD Nested Loop Join
HDD Nested Loop Join
Nested Loop Join
1.E-02
1.E-01
1.E+00
1.E+01
1.E+02
1.E+03
0.00 0.02 0.04 0.06
(CP
U tim
e) ÷
(Dis
k t
ime)
外部表の選択率
SSD Hash JoinHDD Hash Join
Hash Join
[選択率]
[クエリ処理時間
] Join方式2
Join方式2
を選択Join方式1
を選択
Join方式1
Xcross
σR.C=x
R
Join
Join方式の判定
S
選択条件の変更
select count(*)
from R, S
where R.C = x
and R.A = S.B;
(a) SQL (b) 実行プラン (c) 選択率と処理時間
選択条件x
の変更
Instruction）が古くから使用されてきた．一般に CPI の計算は，実
行命令の種類と実行数に着目した計算方法と命令実行パイプライ
ンの滞留（ストール）原因に着目した計算方法がある．特に命令
実行パイプラインのストール原因に着目した方法では，分岐予測
の失敗や演算器不足，キャッシュミス等のイベントの発生頻度と，
それらのイベントによって命令実行パイプラインが停止している
時間の積の合計から CPI を算出する．データベースの CPU の処理
モデルを構築する先行研究[4]では，CPU 処理単価をメモリの遅延
時間(メモリレイテンシ)の関数で記述している．
以上のような CPU 処理のモデル化の先行事例を考慮すると，デ
ータベースの CPU 処理時間を処理単価という単一の指標でモデ
ル化することは困難であると考えられる．そこで，我々は CPU コ
スト計算の精度向上のため以下の取り組みを行う．
CPU のパイプライン・アーキテクチャを考慮し，CPU 処理を命
令キャッシュミスに起因するパイプライン・ストール時の CPU
サイクル数，分岐予測ミス時の CPU サイクル数，データキャッ
シュおよび主記憶アクセス時の CPU サイクル数に分類し，CPU
動作を包括的に表すことができるモデル化手法を提案する．そ
して，データベースのジョイン処理の処理時間を見積るために，
ジョイン処理のパタンを 4 種類の部品に分解し，これらの組み
合わせにより，ジョイン処理のコスト計算手法を提案する(第 2
章)．
次に，CPU に搭載されたパフォーマンスモニタを用いてジョイ
ン処理時のキャッシュアクセス回数等のイベントの実測値の
傾向を分析し，コスト計算式決定する(第 3 章)．
最後に，コスト計算式を用いて実際の CPU 処理時間との比較検
証を実施した結果，コスト計算式を作成するために実測したケ
ースにおいて，ジョイン方式の変化点を外部表の選択率で
0.0006 の差で再現することが可能なことを示す(第 4 章)．
2. CPU コスト計算モデルの検討
2.1. コスト計算の方針
報告者らは先行研究[8]にて CPU コスト計算モデルの検討を行
った．本研究においては，この CPU コスト計算モデルをベースに
さらに適用範囲を拡大する検討を加えた計算モデルを提案する．
最初に，CPU の処理時間を包括的にとらえるために，CPU の処理
全体を俯瞰できる計算モデルを説明する．次に，この計算モデル
を構成する各要素を DBMS でクエリを実行時に測定した CPU 搭
載のパフォーマンスモニタによる統計情報を分析し，コスト計算
式を作成する．
2.2. CPU 処理時間のモデル
広くデータベースサーバの用途で用いられている CPU の典型
例として Intel 社の Nehalem のアーキテクチャを選択する．
Nehalem アーキテクチャはその後継 CPUの基本構成になっており，
後継 CPU では，主に命令でコードを実行する Front End において
は，マイクロオペレーション(uOP)のキャッシュの追加等が，uOP
を実行する Back End において Reorder Buffer の面数の増大，実行
ユニットの演算器増強のような部分的な変更が行われている．
Nehalem のパイプライン処理[14]を図 3 に示す．パイプライン
の構造は Front End と Back End および Memory 部分に分類される．
Front End では，命令キャッシュから命令をフェッチし， uOP に
デコードする処理が行われる．Back End は Front End から発行さ
れる uOP を各種演算処理やメモリへのロード・ストア処理が実行
される．分岐命令先を予測して投機的に命令実行を進める分岐予
測ユニットは Front End に設置されている．図 3 の Memory にはキ
ャッシュメモリや主記憶があり，Front End や Back End からのメ
モリアクセス要求を処理する．Front End での処理はパイプライン
で後続命令が先行命令を追い越すことはなく，インオーダで処理
が行われる．そのため，命令キャッシュのミスは，命令キャッシ
ュが下位のメモリから命令をフェッチしてくるまでのサイクル数，
分岐予測ミスは投機的に実行している先行命令を全てフラッシュ
するため十数サイクル数，Back End に命令を発行不能になる．本
研究では，この現象を命令スタベーション状態と呼ぶことにする．
一方で Back End は命令実行スループットを向上させるためにデ
ータの整合性を失わない範囲で非順序（アウトオブオーダ）に命
令を実行する．
図 3：CPU パイプライン処理の例
先に述べたように CPU の動作解析のために CPU 処理時間をモ
デル化する手法として，CPI が広く用いられている．特に，キャ
ッシュや主記憶へのアクセス特性が性能に与える影響を評価する
ために，キャッシュおよび主記憶のアクセス頻度とメモリ要求を
CPU（正確には演算器のロードユニット）が発行してから期待す
るアドレスのデータが戻ってくる時間（レイテンシ）の積で計算
するモデルが広く用いることが一般的である．あるアプリケーシ
ョンを CPU が実行するときの命令数を Iinst，全データが L1 キャッ
シュに載っているときの命令あたりの実行サイクル数を CPI0，レ
ベル 2以降のキャッシュメモリや主記憶のアクセス回数を Mcachei，
Mmem，各レイテンシを Lcachei， Lmem とする．BFcachei および BFmem
は重複してロード命令が実行されるときの実効的なメモリレイテ
ンシを表現するための係数(以後，ブロッキングファクタと呼ぶ)
である．このとき，CPI は式(1)のように表せる．
𝐶𝑃𝐼 = 𝐶𝑃𝐼0 + ∑ (𝑀𝑐𝑎𝑐ℎ𝑒𝑖
𝐼𝑖𝑛𝑠𝑡
× 𝐿𝑐𝑎𝑐ℎ𝑒𝑖× 𝐵𝐹𝑐𝑎𝑐ℎ𝑒𝑖
)𝐿2 以降
𝑖
+ (𝑀𝑚𝑒𝑚
𝐼𝑖𝑛𝑠𝑡
× 𝐿𝑚𝑒𝑚 × 𝐵𝐹𝑚𝑒𝑚)
(1)
両辺に命令数掛けることで式(2)に示すアプリケーションを実
行したときに要する CPU クロックサイクル数サイクル数(以後，
サイクル数)が得られる．特に式(2)の右辺の第二項目のキャッシ
ュおよび主記憶へのアクセス回数とレイテンシおよびブロッキン
グファクタの積をメモリストールサイクル数と以後呼ぶことにす
る．
𝐶𝑃𝐼 × 𝐼𝑖𝑛𝑠𝑡 = 𝐶𝑃𝐼0 × 𝐼𝑖𝑛𝑠𝑡
+ ∑ (𝑀𝑐𝑎𝑐ℎ𝑒𝑖× 𝐿𝑐𝑎𝑐ℎ𝑒𝑖
× 𝐵𝐹𝑐𝑎𝑐ℎ𝑒𝑖)
𝐿2 以降
𝑖
+ (𝑀𝑚𝑒𝑚 × 𝐿𝑚𝑒𝑚 × 𝐵𝐹𝑚𝑒𝑚)
(2)
式(1)は図 3 の Back End 側，特に命令実行ユニットのうちロー
ド命令実行からみた CPU の処理モデルあると考えられる．Front
End 側の処理は全て CPI0 に集約している．CPI0 がデータベースの
L1
Instruction
Cache
Instruction
Fetch,
Branch
Prediction
DecoderResource
Allocation
Reorder
Buffer
(ROB)
Reservation
Station
(RS)
Execution
Units
Register File
L1Data
CacheL2 Cache
Last Level
Cache
(LLC)
Main
Memory
Global
Queue
(GQ)
Front End Back End
Memory
Quick Path Interconnect (QPI)
Active
Stall
Starvation 境界の状態に着目
In-order Execution Out-of-order Execution
(1)
(2)
(3)
Resource Full
性能を左右するパラメータと相関がある場合，処理時間を評価す
る上での尺度としては不十分であると考えられる．
そこで，本研究では Front End または Back End の片方の動作を
元にした処理モデルではなく，CPU の処理時間全体を包括的にと
らえるために，Front End と Back End の両方を考慮できる部分と
して，Front End と Back End の境界部分，つまりインオーダ処理
とアウトオブオーダ処理の境界部分に着目する．
この境界で観測される状態は，(1)Front End で発行された uOP
を滞りなく Bank End に転送するサイクル数(CActive)，(2)Back End
のリオーダバッファ等のバッファの飽和や，データの従属性が高
いため後続命令が発行できない状態(この状態を以後，まとめて
Resource Full と呼ぶ)[9]のサイクル数(CResource_Full)，(3)Front End が
Back End に発行可能な命令が存在しない命令スタベーション状
態のサイクル数(CInst_Starvation)の 3 種類に分類できる．つまり，CPU
の実行サイクル数(CTotal)は式(3)のように表現できる．
𝐶𝑇𝑜𝑡𝑎𝑙 = 𝐶𝐴𝑐𝑡𝑖𝑣𝑒 + 𝐶𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒_𝐹𝑢𝑙𝑙 + 𝐶𝐼𝑛𝑠𝑡_𝑆𝑡𝑎𝑟𝑣𝑎𝑡𝑖𝑜𝑛 (3)
命令スタベーション状態は，主に命令キャッシュミスや分岐予
測ミス(CInst_Cache_Miss)によるストールサイクル(CInst_Cache_Miss)に分類
可能なことから式(4)が得られる．BRMP は分岐予測ミスと命令キャ
ッシュミスが同時発生のケースを考慮するための補正係数である．
𝐶𝐼𝑛𝑠𝑡_𝑆𝑡𝑎𝑟𝑣𝑎𝑡𝑖𝑜𝑛 = 𝐶𝐼𝑛𝑠𝑡_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠 + 𝐶𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝐵𝐹𝑀𝑃 (4)
先行研究[10]で意思決定処理向けのベンチマークの CPI は 1.5
から 2.5 であると報告されていることから，データベースのクエ
リ実行では命令はほぼシーケンシャルに実行されている可能性が
高い．このような DBMS のメモリアクセス特性を考慮すると Back
End 側で uOP の実行が滞っているサイクル数 CResource_Full は，パイ
プラインが停止していない状況 CActive の両者はメモリアクセスレ
イテンシが大半を占めていると考え，CData_Cache_Access に一体化して
扱うことが可能と考えられる(式(5))．なお，CData_Cache_Access は式(2)
のメモリストールサイクル数の式で計算することができる．
𝐶𝐷𝑎𝑡𝑎_𝐶𝑎𝑐ℎ𝑒_𝐴𝑐𝑐𝑒𝑠𝑠 = 𝐶𝐴𝑐𝑡𝑖𝑣𝑒 + 𝐶𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒_𝐹𝑢𝑙𝑙 (5)
以上の検討から，式(6)の計算式を作成することで CPU での処理
サイクル数の計算が可能になる．
𝐶𝑇𝑜𝑡𝑎𝑙 = 𝐶𝐷𝑎𝑡𝑎_𝐶𝑎𝑐ℎ𝑒_𝐴𝑐𝑐𝑒𝑠𝑠 + 𝐶𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛 + 𝐶𝐼𝑛𝑠𝑡_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠 (6)
本研究では，実測から得た統計情報を用いて式(6)の右辺の各項
目を計算する式を作成する．
2.3. DBMS の処理モデル
DBMS におけるクエリの処理（表の操作）は選択（selection），
射影（projection），ジョイン（join）などがある．これらの処理の
中でジョイン処理はクエリで指定される行の選択率により選択す
べきジョイン方式が異なるため，コスト計算の精度が処理時間の
増大に結びつく可能性があると考えられる．そこで，本研究では
ジョイン処理の最適化のためのコスト計算に焦点をあてる．
基本的なジョイン処理として図 4 にあげた Nested Loop Join
(NLJ)と Hash Join (HJ)の 2 種類がある．
図 4：モデル作成対象の Join 方式
NLJ は外部表を 1 行読み出すごとに内部表の検索を行う．NLJ
によるジョインを一般化すると図 5 に示すように複数のテーブル
を順番にたどる処理になる．複数のテーブルやインデックスをた
どる処理を CPU の動作で考慮すると，Linked List をたどる処理の
繰り返しとみなせる．そこで，コンパイラによるループ展開にな
ぞらえ，ひとつの大きな二表間の NLJ とみなすことができると考
える．つまり，典型的な 2 表の NLJ（部品(a)）でコスト式を作成
し，多表ジョインでもアクセスする行数（たどる Linked List 数）
のみでコスト計算をすることで対処が可能と考えられる．
図 5：縮退・分割コスト計算
一方，HJ の場合は build フェーズと probe フェーズの繰り返し
処理になるため多表のジョインをひとつにまとめて考えることは
困難である．そこで，図 5 に示すように，部品(b-1)build フェーズ
と(b-2)probe フェーズのみのケースの部品に分解することで，外
部表と内部表の組み合わせのモデル化が容易になる．これは，多
くの DBMS では build フェーズ，probe フェーズの順番でシーケン
シャルに処理されており，各フェーズを分離した実機評価をベー
スにコスト計算式を検討することができるからである．
一方，NLJ と HJ の組み合わせの例も考えられるため，部品と
して図 6(b-3)の外部表がバッファに存在するケースからスタート
する NLJ を準備する必要がある．
図 6：分割コスト計算
本研究では，まず方式の有効性について検討するため，あらゆ
るジョイン処理の基本パタンである 2 表ジョインのケースで計算
式を検討する．3 表以上の(a)と(b-3)は今後の課題とする．
2.4. コスト計算式
表 1 にコスト計算式の入出力情報および計算式を構成するパラ
メータを示す．コスト計算式の入力情報は一般的な DBMS であれ
ば，表の作成時等に採取している統計情報に含まれる情報である．
これらの情報でコスト計算可能であれば提案するコスト計算式を
DBMS に組み込むことは可能であると考えられる．
表 1：コスト計算式に関わる情報
入力情報 ジョインする外部表の選択率，表の行数
出力情報 計算コスト（CPU サイクル数）
計算式の
パラメータ
・静的な情報
キャッシュメモリおよび主記憶のレイテンシ
・実機計測から得られる情報
式(6)の右辺の各イベントのサイクル数と入力情報
の関係式（例えば，入力情報と着目イベントのサイ
クル数が線形近似可能であれば，その切片と傾き）
具体的には，前節で検討した 2 表 NLJ と HJ のコスト計算式と
して，それぞれケースで 2.2 節の式(6)を求める．このとき式(6)の
各要素は表の選択率(P)や行数(外部表の行数 RO，内部表の行数 RI)
R表 S表 R表 S表
Hash表
(1)Nested Loop Join (NLJ)
ScanScan
indexKey
KeyKey
Key
(2)Hash Join (HJ)
外部表 内部表 外部表 内部表
R S
T
U
R S
T
U
X Y
X Y
Y
Nested Loop Join Case Hash Join Case
部品に分割2表ジョインに縮退
(b-1) buildフェーズ
(b-2) probeフェーズ
(a) 2表ジョイン
参照する順番
X
R S
T
Hash Join
Nested
Loop join
Y
(b-3) 外部表がバッファされたNLJ
Xon buffer
の関数になると考えられる．TNLJ は NLJ の実行時間を，THJ，Tbuild，
Tprobe は HJ と HJ の Build フェーズおよび Probe フェーズの実行時
間を表す．
Probe フェーズにおいては，表の行数に対して計算値がスケー
ルするように，コスト計算対象の表の行数(RO, RI)と，コスト計算
式のパラメータを求めるために実測データを採取した表の行数
(RO_ref, RI_ref)の積の比を掛けている．
Build フェーズでは，ハッシュ表に登録するデータサイズ(D)が
ハッシュテーブルのサイズ（buf）より大きい場合，（⌈𝐷 𝑏𝑢𝑓⁄ ⌉）回
だけ繰り返して実行される．D は外部表のレコードの中でジョイ
ンのキーとなる列や group by 句で指定している列や，select 文で
抽出する列などのデータサイズおよび列の位置を示すアドレスの
合計したデータのサイズを表す．
𝑇𝑁𝐿𝐽 = 𝐶𝑁𝐿𝐽 𝑇𝑜𝑡𝑎𝑙(𝑃, 𝑅𝑂, 𝑅𝐼) ×(𝑅𝑂 × 𝑅𝐼)
(𝑅𝑂_𝑟𝑒𝑓 × 𝑅𝐼_𝑟𝑒𝑓)
÷ (CPU 周波数)
(7)
𝑇𝐻𝐽 = 𝑇𝐵𝑢𝑖𝑙𝑑 + 𝑇𝑃𝑟𝑜𝑏𝑒
= {𝐶𝐵𝑢𝑖𝑙𝑑 𝑇𝑜𝑡𝑎𝑙(𝑃, 𝑅𝑂) + 𝐶𝑃𝑟𝑜𝑏𝑒 𝑇𝑜𝑡𝑎𝑙(𝑃, 𝑅𝐼) × (⌈𝐷 × 𝑃 × 𝑅𝑂
𝑏𝑢𝑓⌉)}
÷ (CPU 周波数)
(8)
NLJ のコスト計算式（式(9)）は，式(2)(6)(7)を組み合わせるこ
とで得られる．命令キャッシュ，分岐予測ミス，データアクセス
関連のコストは式(10)(11)(12)で表される．コスト計算式の構造は
基本的に，イベントの発生回数とそのレイテンシと補正係数の積
和式になっている． L1D キャッシュ，L2 キャッシュ，LLC キャ
ッシュおよび主記憶からデータ参照した回数 (ML1D, ML2, MLLC,
MMain_mem)，分岐予測ミス回数(MMiss_Predict)とブロッキングファクタ
BF は，選択率 P や表の行数(RO，RI)の関数で表される．データ参
照の場合，命令と異なり L1 キャッシュまで含めているのはスト
ールサイクルだけでなく L1 キャッシュにヒットしたケースまで
𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠には含めているからである．
𝐶𝑁𝐿𝐽 𝑇𝑜𝑡𝑎𝑙(𝑃, 𝑅𝑂, 𝑅𝐼)
= 𝐶𝑁𝐿𝐽 𝐼𝑁𝑆 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠(𝑃, 𝑅𝑂, 𝑅𝐼) + 𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, 𝑅𝑂, 𝑅𝐼)
+ 𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(𝑃, 𝑅𝑂, 𝑅𝐼) (9)
𝐶𝑁𝐿𝐽 𝐼𝑛𝑠_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠(𝑃, 𝑅𝑂, 𝑅𝐼)
= 𝑀𝐿2𝐼𝑛𝑠𝑡(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝐿2 × 𝐵𝐹𝐿2𝐼𝑛𝑠𝑡
(𝑃, 𝑅𝑂 , 𝑅𝐼)
+𝑀𝐿𝐿𝐶𝐼𝑛𝑠𝑡(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝐿𝐿𝐶 × 𝐵𝐹𝐿𝐿𝐶𝐼𝑛𝑠𝑡
(𝑃, 𝑅𝑂, 𝑅𝐼)
+𝑀𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝑀𝑎𝑖𝑛_𝑀𝑒𝑚
× 𝐵𝐹𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡(𝑃, 𝑅𝑂, 𝑅𝐼)
(10)
𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, 𝑅𝑂, 𝑅𝐼)
= 𝑀𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝐵𝐹𝑀𝑖𝑠𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, 𝑅𝑂, 𝑅𝐼) (11)
𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(𝑃, 𝑅𝑂, 𝑅𝐼)
= 𝑀𝐿1𝐷𝑎𝑡𝑎(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝐿1 × 𝐵𝐹𝐿1𝐷𝑎𝑡𝑎
(𝑃, 𝑅𝑂, 𝑅𝐼)
+ 𝑀𝐿2𝐷𝑎𝑡𝑎(𝑃, 𝑅𝑂, 𝑅𝐼𝐼) × 𝐿𝐿2 × 𝐵𝐹𝐿2𝐷𝑎𝑡𝑎
(𝑃, 𝑅𝑂, 𝑅𝐼)
+ 𝑀𝐿𝐿𝐶_𝐷𝑎𝑡𝑎(𝑃, 𝑅𝑂, 𝑅𝐼) × 𝐿𝐿𝐿𝐶 × 𝐵𝐹𝐿𝐿𝐶_𝐷𝑎𝑡𝑎(𝑃, 𝑅𝑂, 𝑅𝐼)
(12)
同様に HJ のコスト計算式（式(13)）も式(2)(6)(8)を組み合わせ
ることで得られる．命令キャッシュ，分岐予測ミス，データアク
セス関連のコストは式(14)(15)(16)で表される．キャッシュおよび
主記憶参照回数 (ML1D，ML2, MLLC, MMain_mem)と分岐予測ミス回数
(MMiss_Predict)とブロッキングファクタ BF は，Build フェーズでは選
択率 P と外部表の行数 RO の関数で表され，Probe フェーズでは選
択率 P と内部表の行数 RI の関数で表される．
𝐶{𝐵𝑢𝑖𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝑇𝑜𝑡𝑎𝑙(𝑃, {𝑅𝑂, 𝑅𝐼}})
= 𝐶{𝐵𝑢𝑖𝑙𝑑,𝑃𝑟𝑜𝑏𝑒} 𝐼𝑛𝑠𝑡_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠(𝑃, {𝑅𝑂, 𝑅𝐼}})
+𝐶{𝐵𝑢𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝑀𝑖𝑠𝑝𝑒𝑑𝑖𝑐𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}})
+ 𝐶{𝐵𝑢𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(𝑃, {𝑅𝑂, 𝑅𝐼}})
(13)
𝐶{𝐵𝑢𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝐼𝑛𝑠_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠(𝑃, {𝑅𝑂, 𝑅𝐼}})
= 𝑀𝐿2 𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}}) × 𝐿𝐿2 × 𝐵𝐹𝐿2 𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) +𝑀𝐿𝐿𝐶 𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝐿𝐿𝐶 × 𝐵𝐹𝐿𝐿𝐶 𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) +𝑀𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝑀𝑎𝑖𝑛_𝑀𝑒𝑚
× 𝐵𝐹𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡(𝑃, {𝑅𝑂, 𝑅𝐼})
(14)
𝐶{𝐵𝑢𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}})
= 𝑀𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝐵𝐹𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(𝑃, {𝑅𝑂, 𝑅𝐼}) (15)
𝐶{𝐵𝑢𝑖𝑙𝑑,𝑃𝑟𝑜𝑏𝑒}𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(𝑃, {𝑅𝑂, 𝑅𝐼}})
= 𝑀𝐿1 𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝐿1 𝐷𝑎𝑡𝑎 × 𝐵𝐹𝐿1 𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼}) + 𝑀𝐿2 𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝐿2 × 𝐵𝐹𝐿2 𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼}) + 𝑀𝐿𝐿𝐶_𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼}) × 𝐿𝐿𝐿𝐶 × 𝐵𝐹𝐿𝐿𝐶_𝐷𝑎𝑡𝑎(𝑃, {𝑅𝑂, 𝑅𝐼})
(16)
コスト計算式の精度は，キャッシュや主記憶参照回数，ブロッ
キングファクタの精度に依存する．表 2 に，これらのパラメータ
を求める方法と推定されるメリット・デメリットを示す．
表 2：パラメータ推定方法
パラメータ
推定方法 推定メリット 推定デメリット
パフォーマンスモニ
タを用いた実測
CPU パイプラインの
状態の正確な統計情
報の取得可能
CPU アーキテクチャが変更
時のパラメータ見直しが必要
(再計測など)
ソフトウェアの動作
から机上推定
CPU アーキテクチャ
の違いやソフトのバ
ージョンの影響少
命令キャッシュのモデル化困
難
シミュレーション 計算時間増大，CPU パイプラ
インの状態を分類した評価は
詳細なハードおよびソフトの
エミュレーションが必要
本研究では CPU コスト計算の精度向上が可能にすることが目
的であるため，CPU パイプラインの状態をモデル化が容易なパフ
ォーマンスモニタでの計測値から統計的に計算式のパラメータを
求める方法を用いる．机上推定やシミュレーションを併用した形
でパフォーマンスモニタを用いるケースのデメリットをカバーで
きる可能性があるので今後の検討課題とする．
レイテンシについてはハードウェアの構造に従うもので DBMS
の処理内容とは独立している．一般的に分析系のクエリでは文献
[9]で述べられているようにメモリに対するアクセス集中はほと
んど起こらず，待ち行列によるレイテンシの増大はほとんど起き
ないと仮定した．
3. コスト計算式のパラメータ設定のための実機評価
表 1 のパラメータを求めるために実機計測を行った．計測環境
を表 3 に示す．CPU としては Nehalem と同一のアーキテクチャで
ある Westmere を使用した．2 ソケットのサーバを用いたため，主
記憶はローカルとリモートの二種類あり，アクセスするレイテン
シが異なる NUMA（Non Uniform Memory Access）構成になってい
る．データベースを格納するディスク装置としては実験効率の向
上を目的に，NVMe Flash SSD を用いた．DBMS としてはオープ
ンソースの MariaDB[15]を用いた．MariaDB はマルチスレッド，
非同期 IO 等をサポートしており，最新のハードウェア特性を生
かすことができると考えられることと，複数のジョイン方式（4
種類）をサポートしている点で選択した．なお，MariaDB がサポ
ートする NLJ は正確には NLJ を改善した BNL（Block Nested Loop
Join）であるが，今回用いたクエリとインデックスの条件では一
般的な NLJ と同様の動作をする．また，MariaDB は NUMA をサ
ポートしていないため，OS の起動時パラメータでインターリー
ブの設定にした．本研究で使用したバージョンの MariaDB ではジ
ョイン方式の選択方法は，設定パラメータで固定的に選択する仕
様になっている．
評価対象クエリとその計測条件を図 7 に示す．SQL 文は
TPC-H[13]の Query3 を 2 表ジョインの評価用に改造し，ジョイン
のみ特化した記述になっている．データベースとして TPC-H の
SF100(100GB)を用いた．クエリが検索対象とする．c_acctbal 列へ
の検索条件を変化させることで，参照するデータの選択率を変更
した．
データベースのインデックスは TPC-H の仕様[13]で規定されて
いるうち，主キー，外部キーに設定した．CPU のパフォーマンス
カウンタのデータは，Intel® Vtune™ Amplifier XE を使用して計測
した．カウンタの内容の解釈については文献[14]を参考にした．
今回計測したカウンタは，キャッシュメモリアクセスに関わるも
のとパイプラインの状態（ストールサイクル数）やキャッシュア
クセス回数を主に採取した．
表 3：計測環境
CPU Xeon L5630 2.13GHz 4core, LLC 12MB [Westmere-EP]) x2
Memory DDR3 24GB (4GB x6)
Disk (DB) PCIe NVMe Flash SSD 800GB x 1
Note: Max throughput suppressed by server’s PCIe I/F (ver.1.0a), about 1/4 max throughput.
Disk (OS) SAS 10krpm 600GB,
RAID5 (4 Data + 1 Parity)
Note: DB is stored in the measurement of 図 1.
OS CentOS 6.6 (x64)
DBMS MariaDB 10.1.8
図 7：計測およびコスト計算対象のクエリ
4. 実機計測結果およびコスト計算式
4.1. NLJ の測定結果
実機にて計測した 2 表ジョイン実行時のパフォーマンスモニタ
の 測 定 値 か ら 得 ら れ る デ ー タ を 加 工 ・ 分 析 し ， 式 (9)の
𝐶𝑁𝐿𝐽 𝐼𝑛𝑠_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠，𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 ，𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎_𝐶𝑎𝑐ℎ𝑒_𝐴𝑐𝑐𝑒𝑠𝑠の計算式を求める．
まず，ジョイン処理の外部表の選択率と命令キャッシュミス，分岐予測ミ
ス，キャッシュおよび主記憶上の命令以外のデータへの参照回数の関
係式を求める．次に，キャッシュおよび主記憶への参照回数とレイテン
シの総和と𝐶𝑁𝐿𝐽 𝐼𝑛𝑠_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠 と 𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎_𝐶𝑎𝑐ℎ𝑒_𝐴𝑐𝑐𝑒𝑠𝑠 の実測結果の関係
式を計測結果から求める．𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡については，分岐予測ミス回数
に Front End のパイプライン段数（Nehalem では 12）を掛けた分岐予測
ミスペナルティ（Misprediction Penalty）と𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡の関係式を実測
結果から求める．メモリレイテンシは文献[16]の数値を参照する．
外部表の選択率に対する NLJ の命令のキャッシュヒット回数
（キャッシュアクセス回数）および主記憶アクセス回数の関係を
図 8に示す．計測に使用したサーバは 2ソケット構成であるため，
LLC と主記憶は DBMS が動作した CPU コアと同じソケットに搭
載される LLC や主記憶へのアクセスともう一方のソケットに搭
載されている LLC と主記憶にアクセスするケースがあり，前者を
ローカル（local），後者をリモート（remote）と呼ぶ．
図 8 の測定結果から，いずれのメモリ階層へアクセスする場合
でも選択率に対して線形に増大していくことが分る．図の点線は
回帰直線を示しており，これらのメモリ参照回数は選択率を変数
とする 1 次関数で近似することができることが分る．
図 9(a)に式 (2)の右辺第二項に相当する命令ミスペナルティ
（Instruction Miss Penalty）と命令キャッシュミス時のストールサ
イクル数である𝐶𝑁𝐿𝐽 𝐼𝑛𝑠_𝐶𝑎𝑐ℎ𝑒_𝑀𝑖𝑠𝑠の関係と，点線で回帰直線を示す．
図 8：NLJ における命令参照回数
図 9：メモリ参照回数の合計と CNLJ Inst_Cache_Miss および，
CNLJ Data_Cache_Acces の関係
命令参照のケースと同様にデータ参照についても同様に分析
すると，データ参照についても図 10 に示すように選択率に対して
直線で近似できることが分る．また，図 9(b)に示すように全メモ
リ解消のデータ参照回数とメモリレイテンシの積の合計（Total
Data Access）と𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎_𝐶𝑎𝑐ℎ𝑒_𝐴𝑐𝑐𝑒𝑠𝑠の関係も直線で近似することが
できる（図中の点線は回帰直線）．
図 10：NLJ におけるデータ参照回数
𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡も同様に傾向を分析すると図 11 に示すように選択
率に対して直線（実線）で近似できることが分る．
select count(*)
from customer, orders
where
c_mktsegment = 'MACHINERY'
and c_acctbal > N
and c_custkey = o_custkey
and o_orderdate < date '1995-03-06‘; σ
σ
customer
orders
N 9998 9978 9798 9200 9000 8000 7000
条件1の選択率
3.62E-05 4.00E-04 3.67E-03 1.45E-02 1.82E-02 3.64E-02 5.45E-02
(b) 実行プラン
γ
条件1
条件2
c_custkey=o_custkey
count(*)Join方式をDBMSの設定で指定
(a) SQL
条件1
条件2
(c) 選択条件と選択率
0.00E+00
5.00E+09
1.00E+10
1.50E+10
2.00E+10
2.50E+10
0 0.02 0.04 0.06
参照回数
選択率
命令 L2
0.00E+00
1.00E+09
2.00E+09
3.00E+09
4.00E+09
0 0.02 0.04 0.06
参照回数
選択率
命令 LLC local 命令 LLC remote
命令 主記憶 local 命令 主記憶 remote
0.0E+00
2.0E+11
4.0E+11
6.0E+11
8.0E+11
1.0E+12
0 1E+12 2E+12C
PUサイクル数
[cycle
]ToTal Data Access [cycle]
(b) CNLJ Data_Cache_Access
0.0E+00
1.0E+11
2.0E+11
3.0E+11
4.0E+11
0 1E+12 2E+12
CP
Uサイクル数
[cycle
]
Instruction Miss Penalty [cycle]
(a) CNLJ Inst_Cache_Miss
0.E+00
1.E+09
2.E+09
3.E+09
4.E+09
0 0.02 0.04 0.06
参照回数
選択率L2 LLC (Local)LLC (Remote) 主記憶 (local)主記憶 (Remote)
0.E+00
1.E+11
2.E+11
3.E+11
0 0.02 0.04 0.06
参照回数
選択率
L1D
図 11：分岐予測ミスペナルティと𝑪𝑵𝑳𝑱 𝑴𝒊𝒔𝒑𝒓𝒆𝒅𝒊𝒄𝒕の関係
以上の分析結果から，式(17)(18)(19)が得られる．ただし，𝑆𝑁𝐿𝐽は
計測結果から得られる定数値である．
𝐶𝑁𝐿𝐽 𝐼𝑛𝑠𝑡𝐶𝑎𝑐ℎ𝑒𝑀𝑖𝑠𝑠= 𝑆𝑁𝐿𝐽 𝐿2 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝐿2
+𝑆𝐿𝑁𝐿𝐽 𝐿𝐶 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝑁𝐿𝐽 𝐿𝐿𝐶𝐼𝑛𝑠𝑡+ 𝑆𝑁𝐿𝐽 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡 × 𝑃
× 𝐿𝑀𝑎𝑖𝑛 𝑀𝑒𝑚 𝐼𝑛𝑠𝑡 (17)
𝐶𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 = 𝑆𝑁𝐿𝐽 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝑃 × 𝐿𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 (18)
𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎𝐶𝑎𝑐ℎ𝑒𝐴𝑐𝑐𝑒𝑠𝑠= 𝑆𝑁𝐿𝐽 𝐿1𝐷𝑎𝑡𝑎
× 𝑃 × 𝐿𝐿1 + 𝑆𝑁𝐿𝐽 𝐿2𝐷𝑎𝑡𝑎× 𝑝 × 𝐿𝐿2
+ 𝑆𝑁𝐿𝐽 𝐿𝐿𝐶_𝐷𝑎𝑡𝑎 × 𝑃 × 𝐿𝐿𝐿𝐶 + 𝑆𝑁𝐿𝐽 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚
× 𝑃 × 𝐿𝑀𝑎𝑖𝑛_𝑀𝑒𝑚 (19)
4.2. HJ Build フェーズの測定結果
HJ の Build フェーズでの命令参照，データ参照についても調査
した結果，命令回数については選択率について直線近似できるこ
とが分る（図 12）．
図 12: HJ の Build フェーズにおける命令参照回数
図 13：HJ の Build フェーズにおける命令参照回数
データ参照については一定値になっている（図 13）．これはデ
ータアクセスについては選択率が変化しても外部表全体をスキャ
ンしているためデータアクセス量は変わらないためと考えられる．
一方，命令についてはハッシュテーブルへの登録処理の関数が選
択率増大とともに頻度が増大するために選択率と命令参照回数に
依存関係が生じているためと考えられる．ただし，NLJ ではほぼ
原点を通る直線で近似可能なことがグラフより判断できるが，HJ
では基本的に表の行を全てスキャンするのでグラフの切片にあた
る選択率が 0 のときのデータ参照回数が表の行数と関係があると
考えられる．そこで，HJ の計算式の切片は参照する表の行数に比
例すると仮定した．この仮説の検証については今後の課題とする．
命令ミスペナルティと𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐼𝑛𝑠 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠についてはデータの分
布具合から直線で近似可能と仮定した（図 14(a)）．しかし，ばら
つきが多いためデータの採取方法含め更なる検討が必要である．
𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑒𝑠𝑠については，データ参照(Total Data Access)と
の相関は弱く，一定値をとると考えられる（図 14(b)）．
図 14：メモリ参照回数の合計と CHJ Build Instst_Cache_Miss
および CHJ Build Data_Cache_Acces の関係
𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡も同様に傾向を分析すると図 15 に示すように
選択率に対して直線で近似可能なことが分る．
図 15：分岐予測ミスペナルティと𝑪𝑯𝑱 𝑩𝒖𝒊𝒍𝒅 𝑴𝒊𝒔𝒑𝒓𝒆𝒅𝒊𝒄𝒕の関係
以上の分析結果を踏まえると，式(20)(21)(22)が得られる．ただ
し，𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑は計測結果から得られる定数値である．𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑(0)は
図 14(a)，図 15 の近似直線の切片である．𝐶𝑁𝐿𝐽 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(0)は
図 14(b)に示す計測データの平均である．
𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐼𝑛𝑠𝑡 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠 = (𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐿2 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝐿2
+ 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐿𝐿𝐶 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝐿𝐿𝐶𝐼𝑛𝑠𝑡
+ 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡 × 𝑃
× 𝐿𝑀𝑎𝑖𝑛 𝑀𝑒𝑚 𝐼𝑛𝑠𝑡)
×𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐼𝑛𝑠𝑡 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠(0)
𝐴𝑣𝑔(𝐼𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛 𝑀𝑖𝑠𝑠 𝑃𝑒𝑛𝑎𝑙𝑡𝑦)×
𝑅𝑂
𝑅𝑂_𝑟𝑒𝑓
(20)
𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 = 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝑃 × 𝐿𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡
+ 𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(0) × 𝑃 × 𝑅𝑂 (21)
𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠
= (𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐿1 𝐷𝑎𝑡𝑎 × 𝐿𝐿1 + 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐿2𝐷𝑎𝑡𝑎
× 𝐿𝐿2 + 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐿𝐿𝐶_𝐷𝑎𝑡𝑎 × 𝐿𝐿𝐿𝐶
+ 𝑆𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚 × 𝐿𝑀𝑎𝑖𝑛_𝑀𝑒𝑚)
+𝐶𝐻𝐽 𝐵𝑢𝑖𝑙𝑑 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(0)
𝐴𝑣𝑔(𝑇𝑜𝑡𝑎𝑙 𝐷𝑎𝑡𝑎 𝐴𝑐𝑐𝑒𝑠𝑠)×
𝑅𝑂
𝑅𝑂_𝑟𝑒𝑓
(22)
4.3. J Probe フェーズの測定結果
図 16 の測定結果から，どのメモリ階層に対しても命令参照回
数については NLJ と同様に原点を通る直線で近似可能である．デ
ータ参照回数については HJ Build フェーズと同様にほぼ一定値と
なっている（図 17）．Probe フェーズでも基本的にテーブルスキャ
ンであるためデータ参照については Build フェーズと同じ傾向が
0.0E+00
5.0E+09
1.0E+10
1.5E+10
2.0E+10
0 0.02 0.04 0.06CPUサイクル数
[cycle]
選択率
CNLJ Mispredict
0.E+00
1.E+08
2.E+08
3.E+08
4.E+08
0 0.02 0.04 0.06
参照回数
選択率
命令 L2
0.E+00
2.E+06
4.E+06
6.E+06
8.E+06
0 0.02 0.04 0.06
参照回数
選択率
命令 LLC local 命令 LLC remote
命令 主記憶 local 命令 主記憶 remote
0.E+00
2.E+07
4.E+07
6.E+07
8.E+07
0 0.02 0.04 0.06
参照回数
選択率
L2 LLC (local)
LLC (Remte) 主記憶 (local)
主記憶 (Remote)
0.E+00
2.E+09
4.E+09
6.E+09
8.E+09
1.E+10
1.E+10
0 0.02 0.04 0.06
参照回数
選択率
L1D
0.0E+00
5.0E+09
1.0E+10
1.5E+10
2.0E+10
3.5E+10 4E+10 4.5E+10
CPUサイクル数
[cycle]
ToTal Data Access [cycle]
(b) CHJ Build Data_Cache_Access
CHJ Build Data_Cache_Access(0)
0.0E+00
1.0E+09
2.0E+09
3.0E+09
4.0E+09
5.0E+09
6.0E+09
4.5E+09 5E+09 5.5E+09 6E+09
CP
Uサイクル数
[cycle
]
Instruction Miss Penalty [cycle]
(a) CHJ Build Inst Cache Miss
CHJ Build Inst Cache Miss (0)
5.9E+08
6.1E+08
6.3E+08
6.5E+08
6.7E+08
0.E+00 5.E+05 1.E+06CPUサイクル数
[cycle]
選択率×外部表行数 [行]
CHJ Build Mispredict
あると考えられる．命令参照については，外部表で検索対象の行
が存在しないケースでは参照される内部表の行は存在しないため，
近似曲線が原点を通ると考えられる．
命令ミスペナルティと𝐶𝐻𝐽 𝑝𝑟𝑜𝑏𝑒 𝐼𝑛𝑠 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠 については直線近似
可能である（図 16 (a)）．𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑒𝑠𝑠 についても同様に
データ参照の合計値(Total Data Access)と正の相関があり，直線近
似可能と考えられる（図 18(b)）．
𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡も同様に傾向を分析すると図 19 に示すように
選択率に対して直線で近似可能なことが分る．
図 16: HJ の Probe フェーズにおける命令参照回数
図 17：HJ の Probe フェーズにおけるデータ参照回数
図 18：メモリ参照回数の合計と CHJ Probe Inst Cache Miss
および CHJ Probe Data Cache Access の関係
図 19：分岐予測ミスペナルティと𝑪𝑯𝑱 𝑷𝒓𝒐𝒃𝒆 𝑴𝒊𝒔𝒑𝒓𝒆𝒅𝒊𝒄𝒕の関係
以上の分析結果を踏まえると，式(23)(24)(25)が得られる．ただ
し，𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒は計測結果から得られる定数値である．𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒(0)は
図 14(a)，図 15 の近似直線の切片である．𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(0)
は図 14(b)に示す計測データの平均である．
𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐼𝑛𝑠𝑡 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠
= (𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐿2 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝐿2 + 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐿𝐿𝐶 𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝐿𝐿𝐶𝐼𝑛𝑠𝑡
+ 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚_𝐼𝑛𝑠𝑡 × 𝑃 × 𝐿𝑀𝑎𝑖𝑛 𝑀𝑒𝑚 𝐼𝑛𝑠𝑡)
×𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐼𝑛𝑠𝑡 𝐶𝑎𝑐ℎ𝑒 𝑀𝑖𝑠𝑠(0)
𝐴𝑣𝑔(𝑀𝑒𝑎𝑠𝑢𝑟𝑒𝑑 𝐼𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛 𝑀𝑖𝑠𝑠 𝑃𝑒𝑛𝑎𝑙𝑡𝑦)×
𝑅𝑂
𝑅𝑂_𝑟𝑒𝑓
(23)
𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 = 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡 × 𝑃 × 𝐿𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡
+ 𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑖𝑠𝑝𝑟𝑒𝑑𝑖𝑐𝑡(0) × 𝑃 × 𝑅𝑂 (24)
𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠
= (𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐿1𝐷𝑎𝑡𝑎× 𝐿𝐿1 + 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐿2𝐷𝑎𝑡𝑎
× 𝐿𝐿2 + 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐿𝐿𝐶_𝐷𝑎𝑡𝑎 × 𝐿𝐿𝐿𝐶
+ 𝑆𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝑀𝑎𝑖𝑛_𝑀𝑒𝑚 × 𝐿𝑀𝑎𝑖𝑛_𝑀𝑒𝑚)
+𝐶𝐻𝐽 𝑃𝑟𝑜𝑏𝑒 𝐷𝑎𝑡𝑎 𝐶𝑎𝑐ℎ𝑒 𝐴𝑐𝑐𝑒𝑠𝑠(0)
𝐴𝑣𝑔(𝑇𝑜𝑡𝑎𝑙 𝐷𝑎𝑡𝑎 𝐴𝑐𝑐𝑒𝑠𝑠)×
𝑅𝑂
𝑅𝑂_𝑟𝑒𝑓
(25)
5. コスト計算結果
実測値から推測したパラメータ用いてコスト計算式を求め，
DBMS が自身で計測している CPU 処理時間との比較を行った（図
20）．HJ については，DBMS の統計情報として計測している CPU
処理時間をほぼ再現できている．ジョイン方式を決定する上で特
に重要なグラフの交点は選択率で 0.0006 の差があり，ほぼ再現で
きている．一方，NLJ については，選択率が高い部分でずれが見
られ，今後の改良点である．
図 20：実測結果とコスト計算値の比較
図 21：実測結果とコスト計算値の比較（交点の拡大）
0.00E+00
5.00E+09
1.00E+10
1.50E+10
2.00E+10
2.50E+10
0 0.02 0.04 0.06
参照回数
選択率
命令 L2
0.00E+00
5.00E+08
1.00E+09
1.50E+09
2.00E+09
2.50E+09
0 0.02 0.04 0.06
参照回数
選択率
命令 LLC local 命令 LLC remote
命令 主記憶 local 命令 主記憶 remote
0.E+00
2.E+10
4.E+10
6.E+10
8.E+10
1.E+11
0 0.02 0.04 0.06
参照回数
選択率
L1D
0.E+00
2.E+08
4.E+08
6.E+08
8.E+08
0 0.02 0.04 0.06
参照回数
選択率
L2 LLC (Local)
LLC (Remote) 主記憶 (Local)
主記憶 (Remote)
0.0E+00
2.0E+10
4.0E+10
6.0E+10
8.0E+10
0 5E+11 1E+12
CP
Uサイクル数
[cyc
le]
Instruction Miss Penalty [cycle]
(a) CHJ Probe Inst Cache Miss
CHJ Probe Inst Cache Miss (0)
0.0E+00
4.0E+10
8.0E+10
1.2E+11
1.6E+11
3.5E+11 4E+11 4.5E+11
CP
Uサイクル数
[cyc
le]
ToTal Data Access [cycle]
(b) CHJ Probe Data_Cache_Access
CHJ Probe Data Cache Access(0)
0.0E+00
1.0E+09
2.0E+09
3.0E+09
4.0E+09
0.E+00 5.E+05 1.E+06
CP
Uサイクル数
[cyc
le]
選択率×外部表行数 [行]
CHJ Probe Mispredict
0
100
200
300
400
500
600
0 0.02 0.04 0.06
実行時間
[秒]
選択率
HJ（コスト計算式）[実線]
HJ（実測）[点線]
NLJ（コスト計算式）[実線]
NLJ（実測)[点線]
98
100
102
104
106
108
110
0.009 0.01 0.011
実行時間
[秒]
選択率
HJ
（コスト計算式）
[実線]
HJ（実測）[点線]
NLJ
（コスト計算式）
[実線]
NLJ（実測)
[点線]
約0.0006
また，計測を行った customer 表と orders 表とのジョインのケー
ス以外に，supplier 表と lineitem 表のジョインのケースでコスト計
算式を適用した(図 22)．ジョインのためのキーは s_suppkey と
l_suppkey を用い，選択率は外部表である supplier 表の s_acctbal
で調整した．その結果を図 22 に示す．HJ の再現はほぼできてい
るが，NLJ のずれがあり，グラフの交点が選択率の差で 0.02 のず
れがあった．この差分を調査し HJ の見積り精度を更に向上する
ことが必要である．
図 22: supplier 表と lineitem 表のジョインのケース
6. 関連研究
DBMS の挙動解析に CPU のパフォーマンスモニタを使用して
プロセッサやアプリケーションの性能を評価することは古くから
おこなわれてきた．特に DBMS の動作について評価したケースも
あり意思決定支援システムのベンチマーク TPC-D の評価では L1
命令キャッシュミスと L2 による処理遅延が CPI の構成要素とし
て大きく占めており，性能上重要であることが示されている．し
かし，ボトルネック解析の着眼点の紹介にとどまっている[6]．
一方，インメモリデータベース向けのコスト計算に CPI の考え
方，特にメモリアクセスレイテンシに着目した研究がある[7]．こ
の研究では，データベースのデータアクセスパタンからキャッシ
ュミス回数を予測し，メモリレイテンシとの積でコスト計算して
いる．本研究でもアクセスパタンの部品化をして積み上げていく
アプローチをとっているが机上計算ではなく実測に基づく計算式
の提案である点が本研究と異なっている．
CPU のデータアクセスについて，データベースのデータ構造か
ら解析的にコスト計算を可能にしているが，CPU の挙動は文献[6]
にあるように命令キャッシュの影響が大きいため，精度向上には
命令キャッシュミスの影響も考慮に入れる必要があると考えられ
る．またシミュレーションにより命令キャッシュの状態を推測す
る研究もなされている[12]．しかし，解析的にヒット率などの統
計を計算してはいない．本研究では命令キャッシュ関連の処理に
も着目した CPU コスト計算モデルを検討した．
7. 結論および今後の課題
CPU アーキテクチャを考慮した DBMS の CPU コスト計算式を
データベースのジョイン方式向けに導出方法を提案した．実測値
と計算値を比較したところデータベースの選択率で約 2%実測値
のずれがあり，小規模なデータベースでは問題にならない程度で
あるが，巨大なデータベースに関してはさらに改善の必要性があ
る．Hash Join は実測値に近い予測結果を得られたが，Nested Loop
Join にはまだ改善のよりがあり今後の課題としたい．また，コス
ト計算式のパラメータを本研究では実測値を用いたが，他の方式
を含めて検討していきたい．
文 献
[1] H. Patel, S. Shepler, SFTD015- Next Generation Storage
Architecture: Microsoft* Storage Spaces Direct and Intel® SSD
Data Center Family for NVM Express™, Intel Developer Form
(IDF15) San Francisco, Aug. 2015.
[2] P. G. Selinger, M.M. Astrahan, D.D. Chamberlin, R. A. Lorie,
and T. G. Price, “Access path selection in a relational database
management system,” Proc. 1979 ACM SIGMOD international
conference on Management of data. ACM, pp. 23-34, 1979.
[3] O. Sandstå, MySQL Cost Model, Oct. 2014.
(http://www.slideshare.net/olavsa/mysql-optimizer-cost-model)
[4] S. Manegold, P. A. Boncz, and M. L. Kersten, "Optimizing
database architecture for the new bottleneck: memory access."
The VLDB Journal—The International Journal on Very Large
Data Bases 9.3 (2000): 231-246.
[5] W. Wu, Y. Chi, S. Zhu, J. Tatemura, H. Hacıgumus, and J. F.
Naughton, “Predicting query execution time: Are optimizer cost
models really unusable?.” Data Engineering (ICDE), 2013 IEEE
29th International Conference on. IEEE, pp. 1081-1092, 2013.
[6] A. Ailamaki, D. J. DeWitt, M. D. Hill, and D. A. Wood, “DBMSs
on a modern processor: Where does time go?” P.ro. 25th
International Conference on Very Large Data Bases (VLDB), pp.
266-277, Edinburgh, Scotland, UK. Sept. 1999.
[7] Stefan. Manegold, P. Boncz, and M. L. Kersten, “Generic
Database Cost Models for Hierarchical Memory Systems,” Proc.
28th international conference on Very Large Data Bases (VLDB),
pp. 191-202, Endowment, 2002.
[8] 田中, 石川, CPU アーキテクチャ考慮した性能モデルの導入によるデータベース高速化のためのコスト計算精度向上 ,
信学技法 CPSY2015-116, Jan, 2016.
[9] J. L. Lo, L. A. Barroso, S. J. Eggers, K. Gharachorloo, H. M.
Levy, and S. S. Parekh, "An analysis of database workload
performance on simultaneous multithreaded processors." ACM
SIGARCH Computer Architecture News. Vol. 26. No. 3. IEEE
Computer Society, 1998.
[10] N. Hardavellas, I. Pandis, R. Johnson, N. G. Mancheril, A.
Ailamaki, and B. Falsafi, "Database servers on chip
multiprocessors: Limitations and opportunities." Proceedings of
the Biennial Conference on Innovative Data Systems Research .
No. DIAS-CONF-2007-008. 2007.
[11] A. Ailamaki, D. Slutz, “Processor Performance of Selection
Queries,” Technical Report MSR-TR-99-94, Microsoft Corp.,
1999.
[12] F.Muller, D. B. Whalley, and M.Harmon, “Predicting Instruction
Cache Behavior”, ACM SIGPLAN workshop on Language,
Compiler and Tool Suport for Real-Time Systems, June 1994.
[13] TPC BENCHMARK™ H (Decision Support) Standard
Specification Revision 2.17.1, Transaction Processing
Performance council (TPC), Nov. 2014.
(http://www.tpc.org/tpc_documents_current_versions/pdf/tpch2.1
7.1.pdf)
[14] D. Levinthal, Performance Analysis Guide for Intel® Core™ i7
Processor and Intel® Xeon™ 5500 Processors, Intel Performance
Analysis Guide, 2009.
[15] MariaDB Foundation website, https://mariadb.org/.
[16] D. Molka, D. Hackenberg, R. Schöne, and M. S. Müller,
"Memory performance and cache coherency effects on an intel
nehalem multiprocessor system." Parallel Architectures and
Compilation Techniques, 2009. PACT'09. 18th International
Conference on. IEEE, 2009.
0
200
400
600
800
1,000
0 0.1 0.2 0.3
処理時間
[秒]
選択率
HJ（コスト計算式）[実線]
HJ（実測）[点線]
NLJ（コスト計算式）[実線]
NLJ（実測)[点線]
実測切替点
予想切替点
