SlideShare a Scribd company logo
1 of 34
Download to read offline
© Hitachi, Ltd. 2014. All rights reserved. 
株式会社日立製作所 
ITプラットフォーム事業本部 
2014/11/12 
SSDとHDDの混在環境での Oracleの超効率的利用方法 
db tech showcase Tokyo 2014 
Session 3 B23
© Hitachi, Ltd. 2014. All rights reserved. 
1.従来DBシステムの問題点
© Hitachi, Ltd. 2014. All rights reserved. 
ソフト/ハード別原因と対策方法は 
ソフト的な要因 
ハード的な要因 
CPU 
メモリー 
I/O 
SQL 
機能 
パラメータ 
構造 
CPU/メモリー追加は簡単にできる対策。 
CPUがボトルネックになっているとしても それは一瞬のことが多い。 
I/O、ストレージネックの場合は、それを 解消すればCPU/メモリーをもっと使え、 大きく性能向上の可能性あり。 
簡単に高速化するにはリプレース時にI/Oやストレージを強化 
パラメータチューニングは、実はほとん ど効果なし。 
性能が良くなる機能なら最初から導入 している。 
構造やSQLで性能は大きく変わるが、 そう簡単には変えられない。 
ストレージ 
CPU 
メモリー 
I/O 
SQL 
機能 
パラメータ 
構造 
ストレージ 
性能への効果 
変更の難易度 
性能への効果 
変更の難易度 
難易度・工数大 
1-1. DBが遅い原因 
リプレース時は難易度同じ
© Hitachi, Ltd. 2014. All rights reserved. 
1 
10 
20 
相対性能 
2005 
2006 
2007 
2008 
2009 
2010 
2011 
5 
15 
2012 
25 
30 
2013 
10倍 
HDD回転数 
1倍 
 CPU性能はコア数の増加と共に劇的に向上している。 
 CPU性能の伸びに比べ、HDD回転数やFC帯域は伸びていない 
システム構成は今でも2005年と同じ作りだが、それで良いのか 
※CPU性能はSAP SDベンチ マークをベースにした値 
4倍 
4core 
6core 
2core 
32倍 
8core 
12core 
2005年を1とした時の性能推移 
1-2. H/Wの性能進化の不均衡
© Hitachi, Ltd. 2014. All rights reserved. 
100 
90 
80 
70 
60 
50 
40 
30 
20 
10 
0 
(%) 
CPU,LAN,FC,HDDの使用率の状況は 
 CPUはあまり稼働率が上がらず、底辺を這っている様な状態。 
 HDDは常に稼働し続けており、ほぼ100%張りつきの状態。 
 LANは使っている時と使っていない時の差が激しい状態。 
 FCの帯域はまだまだ余裕があるが、CPUよりは使われている状態。 
HDDとLANの高速化を行えば、システム性能が上がる 
HDDの使用率は 
OSの性能モニタでは 
直接表示されない 
パーツ使用率のイメージ 
1-3. 2005年と同じ構成のシステムでは 
HDDの使用率が 
ボトルネックなのが 
実は分かりにくい!
© Hitachi, Ltd. 2014. All rights reserved. 
ス 
トレ 
ー 
ジ 
キャッ 
シュ 
円盤に書かれたデータが来るまで待つ 
データ 
要求 
日付 都市 時間 気温 
7/8 東京 12:00 28° 
7/8 大阪 14:00 32° 
7/8 名古屋 14:00 35° 
7/9 甲府 13:00 37° 
7/9 京都 14:00 36° 
 HDDは円盤にデータが記録されている。 
 円盤は1分間に15,000回転している。 
 目的のデータがヘッドまで来ると読み出せる。 
例えば、 7/9の京都の最高気温が知りたい 
 ヘッドの移動(データのあるトラックまで移動) 
 回転待ち(最大1回転:1/15,000分=1/250秒) 
アプリケーション 
サーバ 
データベース 
サーバ 
要求 
データ 
要求 
要求 
データ データ 
つまりHDDは1秒間に最悪250件しか読めないから遅い。 
1-4. HDDのデータリード処理の問題点
© Hitachi, Ltd. 2014. All rights reserved. 
1-5. HDD I/O性能基本データ 
570 MB/s 
HDDはランダムアクセスが苦手 
73 MB/s 
360 MB/s 
SAS 15,000回転/s, RAID5:4D+1P 
ブロックサイズ:512KB, 多重度:8 
1 
7.8 
リード帯域性能 
シーケンシャル 
ランダム 
19 MB/s 
1 
19 
ライト帯域性能 
シーケンシャル 
ランダム 
少しでもランダムアクセスがあるとHDD性能はガタ落ち
© Hitachi, Ltd. 2014. All rights reserved. 
※DMA: Direct Memory Access 
メモリー空間 
PCI-Eバス 
メモリーバス 
 HDDからデータを読む場合、CPUはHDD 
のアドレスとメモリーのアドレスを指定。 
 転送開始を指示したら、CPUは何もしなく 
ても良い。FCカードがDMAで処理する。 
 データ転送中はバスが競合しなければ、 
CPUは他の計算などをすることが可能。 
 FCカードから完了報告が上がれば終了。 
1-6. I/OとCPUの関係 
I/OはCPUを使わずに処理される 
DMAでHDDからメモリーにデータ移動 
FC 
FCカード 
データ転送中は他の計算が無ければ 
CPUはやることが無く使用率は下がる。 
I/Oを多用する処理は、CPU使用率が下がる! 
割込み 
(終了)
© Hitachi, Ltd. 2014. All rights reserved. 
バッチ処理こうなってますよね 
I/Oが滞らない様に、Flashで一気にストレージ能力を高めてしまう 
バッチはオンラインの何倍ものデータにア クセスし、リードもライトも発生する。 
1つのデータベースに数十のバッチを一夜 で流し、多重処理は当たり前。 
月末/期末処理は日次バッチに更に追加 する為、想定を超えた遅さになってしまう。 
I/Oが大量に滞ると 
CPU使用率が下がる 
CPUが空いているので、 
更にバッチを多重化する 
月askfdi 
月hfewhfw 
月dafhf 
月iufif 
月iofif 
月dafhf 
月次バッチ 
17:00 18:00 19:00 20:00 21:00 22:00 23:00 24:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 
s;lkfjdsk 
dfiefdh 
uewrh 
cvhvu 
fvn 
efhdcdgj 
vdisdifj 
eiruw 
cvkj 
gori 
sdiufiowuifkej 
kdfvjakfd 
kdj 
vjadijiafke 
dfjdiauid 
cxdkvjvk 
fdksjf 
eifwjeifkf 
svid 
dviajidgjidgigjg 
difdsadifiew 
HDDが追い付かずI/Oが滞る 
1-7. バッチ処理のやりがちなこと
© Hitachi, Ltd. 2014. All rights reserved. 
2.フラッシュを使った高速化構成
© Hitachi, Ltd. 2014. All rights reserved. 
ストレージ 
サーバ 
P 
P 
今までのシステム構成は 
サーバからFCケーブルが2本ストレージ に接続されている。 
HDDはRAID構成で組まれている。 
サーバ1台(またはActive-Standby)の構成 
★単純にHDDをSSDに 
置き換えただけだと... 
コントローラ 
コントローラ 
P 
P 
P 
P 
P 
P 
P 
P 
RAID構成 
ストレージの内部バス帯域限界を超える。 
コントローラーの処理性能が不足する 
FCポートの帯域限界を超える せっかくのSSDの高速性が、今までの構成では引き出せない! 
2-1. SSDに変えるとどうなるか
© Hitachi, Ltd. 2014. All rights reserved. 
ボトルネックを極力排除する 
ストレージ 
サーバ 
サーバ 
10G 
NIC 
10G 
LANSW 
10G 
LANSW 
10G 
NIC 
10G 
NIC 
10G 
NIC 
Bonding 
Bonding 
RAC Interconnect 
Ctrl0 
Ctrl1 
Ctrl2 
Ctrl3 
8Gbps x 16 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
FC 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
P 
1G 
NIC 
1G 
NIC 
Bonding 
1G 
NIC 
1G 
NIC 
Bonding 
Public LAN 
サーバは2台以上で 
Oracle RAC構成に 
可用性と性能を両立 
処理性能ネックを回避 
する為にSSD数に 
応じたコントローラ数を 
処理能力が上がるため、 
RACインターコネクトは、 
10Gの冗長構成が必要 
内部バスがボトルネック 
にならない様なSSDの 
スロット配置を行う 
FCはSSDの数に応じ 
帯域を確保できる本数 
並列性と可用性に効果 
これが理想のSSDシステム 
2-2. 高速化を実現するハードウェア構成
© Hitachi, Ltd. 2014. All rights reserved. 
ストレージ 
使い 過ぎ 
少な 過ぎ 
FC 
利用率 
100% 
0% 
SSDは1本当たり6Gbps(600MB/s)に近い帯域を出すことが 可能であり、SSDが多いとFCも それに応じた本数が必要。 
FCが増えるとRAIDから切り出 すLUも複数必要になる。 
しかしLUが複数になると、どの データをどのLUに割り当てるか 検討が必要になる。 
検討不十分だとLUのデータ占 有量が不揃いになったり、アクセ ス頻度が偏る。 
高速化構成の副作用 
LU 
サーバ 
HBA 
(FCカード) 
TableC 
TableA 
TableD 
TableB 
2-3. 複数LUへのDB配置
© Hitachi, Ltd. 2014. All rights reserved. 
LU 
Oracle ASM 
最高のパフォーマンス 
複数LUをうまく使うには、 
Oracle ASMを使用すること 
で対応が可能。 
複数LUがストライピングされ、 
全てのLUを均等に利用可能。 
FC帯域も均等に利用でき、パ 
フォーマンスも向上。 
遅いLUが混在していると性能 
が引きずられ、DB全体が遅く 
なることがある。 
理想構成では全てSSDで統一 
しており、最高のパフォーマン 
スを発揮可能。 
FC 
利用率 
100% 
0% 
HBA 
(FCカード) 
複数LUをまとめて管理 
TableA TableB TableC TableD 
2-4. サイズやアクセス頻度の偏りの無いASM
© Hitachi, Ltd. 2014. All rights reserved. 
3.HDDとFlashの混在環境をOracleで使う
© Hitachi, Ltd. 2014. All rights reserved. 
3-1. フラッシュの価格は今後どうなるのか 
ビットコストの動向 
‘05 
’06 
’07 
’08 
’09 
’10 
’11 
’12 
’13 
’14 
’15 
’16 
’17 
’18 
’19 
‘20 
デバイス技術動向調査結果(日立調べ) 
各デバイスのビットコスト推移予想 
ビットコスト($/GB) 
100 
10 
1 
0.1 
0.01 
0.001 
MLC SSDと 
SAS HDDが 
逆転する 
数年後にはSAS HDDよりSSDの方が安くなる。 
しかし今時点では、まだSSDが高いのでオールSSDは無理
© Hitachi, Ltd. 2014. All rights reserved. 
アクセス頻度の高い領域のみ、 
Flashを使用すれば、性能は改 
善されるはず。 
例えば、常にアクセスのある 
RedoやTempは必ずFlashに配 
置する。 
容量が確保できればアクセスの 
多いデータやインデックスも 
Flash化したい。 
実際に本構成で性能測定した 
所、RedoとTempだけでは、 
37%しか性能向上しなかったが、 
データまで入れると数倍の性能 
向上が確認できた。 
Flashを別領域として管理 
TableD 
TableA 
TableB 
TableC 
3-2. HDDとFlashを混在で使用する 
Oracle ASM 
Redo 
Temp
© Hitachi, Ltd. 2014. All rights reserved. 
Oracleのレポートから配置を考える 
statspackやAWRレポートからアクセス頻度の高いテーブルやインデックスをフラッシュに配置。 
3-3. アクセス頻度からHDD/Flashに配置 
Segments by Physical Reads DB/Inst: TPCCDB/tpccdb Snaps: 1-2 
-> End Segment Physical Reads Threshold: 1000 
Subobject Obj. Physical Pct 
Owner Tablespace Object Name Name Type Reads Total 
---------- ---------- -------------------- ------------ ----- ------------ ----- 
ABCC TPCC_STOCK SYS_IOT_OVER_18164 TABLE 1,316,772 36.4 
ABCC TPCC_OTHER CUSTOMER TABLE 1,275,890 35.3 
ABCC TPCC_USERS S_PK INDEX 358,444 9.9 
ABCC TPCC_USERS C_WDI INDEX 130,404 3.6 
ABCC TPCC_USERS O_WDCI INDEX 117,105 3.2 
------------------------------------------------------------- 
statspackの例 
既存DBからの移行の場合は事前に調査できる為、フラッシュの搭載容量の検討が可能だが、 新規DBの場合にはサイジングが難しい。 
大きなテーブルではアクセス頻度にムラがあっても、テーブル全部を乗せる必要あり。 
テーブル数が少ない場合は、SSDの容量とテーブルの容量を考えて配置しなければならない。 
定期的に見直しをして、性能が不十分の場合には配置換えや容量追加も検討する必要あり。 
欠点も 
結構手間もかかり手動はいまいち。自動でうまくできないか。
© Hitachi, Ltd. 2014. All rights reserved. 
Flashをキャッシュとして利用する 
3-4. HDDとFlash混載利用の自動化(1) 
・LSI-LogicのRAIDカード搭載Cache-Cade Ver.1を利用 
・キャッシュクリア後の測定結果 
・HDDは10K回転×3D+1Pのライトバック設定(ライトキャッシュ有効) 
1.49倍 
Flashにデータを自動的にキャッシュする為、アク セス頻度調査やデータ選択の必要無い。 
Flash溢れの心配が無く、データの見直し等の煩わ しさも発生しない。 
アクセスに追従するのが速く、効果が表れやすい。 
利点 
欠点 
全体的なアクセス頻度は見ていない為、単発の アクセスでもFlashに上がったり、少しアクセスが 無いと消されることがある。 
キャッシュクリア後測定の影響もあるが、2倍に満 たない性能しか得られなかった。 
Flashの性能向上効率としては、これはかなり悪い 
SSDキャッシュ(リード)を使用した場合のOLTP性能
© Hitachi, Ltd. 2014. All rights reserved. 
アクセス回数に応じてFlashに配置する 
3-5. HDDとFlash混載利用の自動化(2) 
キャッシュと違い長期統計で配置する為、DB等の蓄積型データに最適 
アクセス頻度 
高 
低 
 データをブロックに分割し、ブロック毎にアクセ 
ス頻度を計測し、アクセスの激しいブロックは 
Flashに配置する。 
 具体的にはブロック毎のアクセスカウンターを持ち、 
アクセス毎にカウントアップする。 
 アクセス頻度は時間と共に変化する為、一定期間 
毎に再計測し、頻度が変化したものは再配置する。 
効果 
機能 
 アクセス頻度の激しいブロックはFlashに配置され 
ており、高速に処理可能。 
 テーブル丸ごとでは無く、小さなブロック毎に配置さ 
れる為、効率良くFlashに配置することが可能。 
 自動で配置される為、ユーザはアクセス頻度の検 
討が必要無く、新規のシステムでも利用可能。 
3 6 2 5 3 7 1 5 
2 3 253 36 48 4 9 59 
1 67 6 8 2 1 94 8 
77 4 1 74 182 82 5 69 
9 75 85 2 58 1 83 71 
65 44 110 39 53 87 68 95 
55 235 210 137 196 173 188 47 
74 101 183 86 245 256 145 205
© Hitachi, Ltd. 2014. All rights reserved. 
仮想ボリューム 
HDDとのハイブリッドでも高速アクセス Hitachi 
Dynamic 
Tiering 
Tier1 
プール 
3-6 日立ストレージのボリューム自動階層制御 
自動 
再配置 
新しいデータ 
古いデータ 
Tier2 
サーバに見せるLU。 
容量は自由に設定可能。 
実データはブロック単位でプール 
の領域が割り当てられる。 
SSDとHDDでTierを構成。 
新規データはTier1のSSD領 
域が割り当てられる。 
Tier1の空容量を一定に保つ 
様に再配置が行われる。 
再配置で古くなったデータは、 
HDDに移動される。
© Hitachi, Ltd. 2014. All rights reserved. 
カウンターはアクセス回数-経過時間 
3-7. HDTはデータの新鮮度も加算して移動 
何をFlashに残したいかにより、再配置タイミングを設定 
 カウンターはアクセス回数で上 
昇するが、時間が経過すること 
で下降する機構となっている。 
 カウンター値はアクセスされな 
ければ次第に下がってゆく。 
 設定したSSDの空き容量になる 
様に、再配置で調整される。 
運用と動作 
アルゴリズム 
 カウンターの計測とSSD⇔HDDの再配置タ 
イミングは設定可能。 
 バッチ終了後に再配置をすることで、SSDに 
データが残り、バッチの高速化が可能。 
 マスター表等のデータは常にアクセスされ 
カウンターが下がらず、常にFlashに配置。 
▲ 
再配置 
▲ 
再配置 
1日 
オンライン バッチ オンライン バッチ オンライン 
アクセス頻度 
この枠内は 高 低 
アクセスあり 
枠外は無し 
… 
1日 1ヶ月 
▲ 
日時バッチ 
▲ 
月次バッチ 
▲ 
再配置
© Hitachi, Ltd. 2014. All rights reserved. 
4.HDDとFlashの混在環境の性能
© Hitachi, Ltd. 2014. All rights reserved. 
4-1. 一般的な企業データの傾向 
課題は、Flashに格納すべきデータの判断 
頻繁にアクセスされるデータがFlashに格納されていれば 
性能要件は満たせ、コストも最適化できる。 
一般的な企業データの傾向 
・履歴データが蓄積されていき、SQLのほとんどは直近データを参照する 
・実際に業務で扱うデータは全容量の数%~20%程度なことが多い 
企業DBでは格納された全てのデータが用いられるわけではない 
必要なデータだけをFlashに格納することが出来れば十分な高速化 
5年前 
3年前 
1年前 
3ヶ月前 
1ヶ月前 
現在 
・履歴表とマスタ表(ユーザ、商品等)があり、履歴表は日々増加する
© Hitachi, Ltd. 2014. All rights reserved. 
4-2. Flashを用いたDBの高速化方式 
採用方式を事前に検討する必要がある 
Flashを用いたDBの高速化方式は様々 
導入の手間/コスト/性能を考慮して採用しないと、効果が薄いことも 
手動配置 
(REDO/TEMP) 
SSD 
キャッシュ 
手動配置 
(高アクセス領域) 
Hitachi Dynamic 
Tiering (HDT) 
ALL-Flash 
導入の手間 △(設定要) ○ ×(設計要) △(設定要) ○ 
価格 ○ ○ △ ○ × 
HDD性能比(OLTP) △ △ ○ ◎ ◎ 
コスト 
パフォーマンス 
△ △ △ ◎ △ 
REDO 
TEMP 
Cache 
REDO 
TEMP 
USER_H 
USER_L 
USER_H 
USER_L 
REDO 
TEMP 
USER_H 
USER_L 
REDO 
TEMP 
USER_H 
USER_L 
REDO 
TEMP 
USER_H 
USER_L 
USER_H: 高アクセス表 
USER_L: 低アクセス表 
※ 日立測定環境での数値。性能は、構成により異なります
© Hitachi, Ltd. 2014. All rights reserved. 
内蔵HDD 高アクセスTop5表をPCI-Flash格納ALL-内蔵PCI Flash 
4-3. 手動配置によるHDD/FlashのHybrid構成 
手動配置によるハイブリッド構成には限界がある 
Obj. Physical 
Owner Object Name Type Reads 
--------- ---------------------------------- ---------- -------------- 
TPCC SYS_IOT_OVER_18164 TABLE 1,316,772 
TPCC CUSTOMER TABLE 1,275,890 
TPCC S_PK INDEX 358,444 
TPCC C_WDI INDEX 130,404 
TPCC O_WDCI INDEX 117,105 
乗り切らなかった分 
高アクセス表のFlash手動配置で得られる効果は限定的 
DBの統計レポートを見ても、Flash格納が必要なデータを解析するのは困難 
REDO 
TEMP 
USER01 
USER02 
一般的なオンライン処理のトランザクション処理数/分 
(3D+1P) HDD(3D+1P) PCI-Flash(1D+1D) (1D+1D) 
※ 日立測定環境での数値。性能は、構成により異なります
© Hitachi, Ltd. 2014. All rights reserved. 
100% 107% 
183% 
0% 
100% 
200% 
ALL-HDD HDT(SSD10%) ALL-SSD 
ALL-HDD 
HDT(SSD10%) 
ALL-SSD 
ALL-HDD HDT(SSD10%) ALL-SSD 
トランザクション処理数/分 
4-4. OracleDBにおけるHDTの効果 
HDTを用いて低コストでDB高速化を実証 
Oracle DatabaseにおけるHDTの費用対効果 
一般的なオンライン処理を模したベンチマークで、 
HDTでDB領域の10%をFlash(SSD)化することで約19倍の高速化を実現 
導入コスト比較 
Hitachi 
Dynamic 
Tiering 
(4D+1P)×4 (4D+1P)×4 SSD(4D+1P) (6D+1P)×4 
※ 日立測定環境での数値。性能は、構成により異なります
© Hitachi, Ltd. 2014. All rights reserved. 
400 
600 
1000 
1200 
800 
4-5 手動配置に対するHDTの優位性 
Name 
Reads 
Reads 
%Total 
Table/Index 
Size[GB] 
Size 
%Total 
S_OV_TS001 
26,433,536 
41.1% 
102.9 
8.2% 
C_TS001 
17,985,689 
27.9% 
54.8 
4.3% 
OL_TS001 
8,643,158 
13.4% 
78.3 
6.2% 
O_WDCI_TS001 
5,353,041 
8.3% 
5.6 
0.4% 
OL_WDO_TS001 
2,164,236 
3.4% 
32.3 
2.6% 
Top5 
94% 
273.9 
22% 
Total 
100% 
1261.6 
100% 
120GB = 10% 
274GB = 22 >> 
Oracle 統計レポート AWR [Top5 Disk Read統計] 
Oracleの統計レポートから確認できるDisk Read Top5(Read全体の94%)の領域はDB全体の 22% 
HDTから確認できるアクセス頻度境界は1000[IOPH ]、10%で前述の通りALL-SSDと同程度の性能 
一般的に履歴表は最近のデータのみ高アクセス 
全てをFlashに載せる必要はない。 
効率的なFlash活用 
性能が安定 
手動配置 
× 表全体を移動する必要有 
移動もSE作業 
× アクセス傾向が変化するたびに 
対応が必要 
HDT使用 
○ ページ単位で 
配置場所を判断 
○ 定期的に自動で再配置するため、 
性能が安定 
120 
(10%) 
HDTによるアクセス頻度に応じた自動配置の優位性
© Hitachi, Ltd. 2014. All rights reserved. 
約5倍高速 
約40倍高速 
4-6. Flash活用の次はIn-Memory機能の活用 
更なる高速化にはOracle 12c In-Memory Optionも 
Oracle Databaseの機能を最大限に引き出す 
標準機能のみ 
2Node RAC環境における, 分析系業務SQLの処理時間比較 
*1:テーブルをバッファキャッシュ上に 
キャッシュする 
*2:複数ノードでの分散処理 
分析系SQLで約40倍の性能向上を実証 
In-Memory Option 
In-Memory 
※ 日立測定環境での数値。性能は、構成により異なります 
検証構成 
HDD:15Krpm RAID5(9D+1P) 
Memory:256GB(In-Memory時はDB全て格納) 
新機能の列格納メモリ空間の使用 
In-Memory Option 
インターノードパラレルクエリ(*2) 
既存の行バッファメモリ空間へのキープ 
Buffer Pool:Keep(*1) 
インターノードパラレルクエリ(*2)
© Hitachi, Ltd. 2014. All rights reserved. 
バッチSQL実行時間 
4-7. Flash+In-Memoryの実力 
Flash+In-Memoryはさらなる高速化を実現 
バッチ処理で実施される集計演算と検索更新を実施 
バッチ処理などの複雑な処理の高速化はFlash+In-Memoryで実現可能 
… 
SSD(7D+1P)×2 
・・・ 
HDD(6D+1P) 7,200rpm 
… 
SSD(7D+1P)×2 
In-Memory 
HDD 
Flash 
Flash 
※ 日立測定環境での数値。性能は、構成により異なります 
Memoryは全て256GB 
約3.1倍高速化(バッチ合計) 
約4.0倍高速化(バッチ合計) 
(ALL-Flashの更に1.3倍) 
集計 
集計 
集計 
検索更新 
検索更新 
検索更新 
約9.3倍高速化(集計) 
約39倍高速化(集計) 
(ALL-Flashの更に4.2倍)
© Hitachi, Ltd. 2014. All rights reserved. 
4-8. DBを階層化するにあたって重要なこと 
要件に応じて最適なFlash/Memory/機能の選択が重要 
In-Memory 
コスト 
導入の 
手間 
+ 性能 
コスト 
パフォーマンス 
将来の 
DB要件 
増加量 + 性能劣化 
手動配置? 
自動配置? 
ALL-Flash? 
In-Memory?
© Hitachi, Ltd. 2014. All rights reserved. 
•OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標です。 
•Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。 
•Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。 
•その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。 
•製品の改良により予告なく記載されている仕様が変更になることがあります。 
他社商品名、商標等の引用に関する表示
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法  by 株式会社日立製作所 福井正志
[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法  by 株式会社日立製作所 福井正志

More Related Content

What's hot

TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望Kohei KaiGai
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCacheKohei KaiGai
 
20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDBKohei KaiGai
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_BetaKohei KaiGai
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstromKohei KaiGai
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントCloudera Japan
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdwKohei KaiGai
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpuKohei KaiGai
 
Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Yuki Gonda
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】Kohei KaiGai
 
Db2 Warehouse セッション資料 db tech showcase
Db2 Warehouse セッション資料 db tech showcase Db2 Warehouse セッション資料 db tech showcase
Db2 Warehouse セッション資料 db tech showcase IBM Analytics Japan
 
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用についてハイシンク創研 / Laboratory of Hi-Think Corporation
 
マルチコアとネットワークスタックの高速化技法
マルチコアとネットワークスタックの高速化技法マルチコアとネットワークスタックの高速化技法
マルチコアとネットワークスタックの高速化技法Takuya ASADA
 
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanBOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanAtsushi Suzuki
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsKohei KaiGai
 
20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrowKohei KaiGai
 
Hadoopを用いた大規模ログ解析
Hadoopを用いた大規模ログ解析Hadoopを用いた大規模ログ解析
Hadoopを用いた大規模ログ解析shuichi iida
 
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか  by 日本ヒューレット・パッカード株式会社 後藤宏[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか  by 日本ヒューレット・パッカード株式会社 後藤宏
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏Insight Technology, Inc.
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)Kohei KaiGai
 
Linux packet-forwarding
Linux packet-forwardingLinux packet-forwarding
Linux packet-forwardingMasakazu Asama
 

What's hot (20)

TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache
 
20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom
 
Hadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイントHadoopのシステム設計・運用のポイント
Hadoopのシステム設計・運用のポイント
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpu
 
Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-Hadoop -NameNode HAの仕組み-
Hadoop -NameNode HAの仕組み-
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
 
Db2 Warehouse セッション資料 db tech showcase
Db2 Warehouse セッション資料 db tech showcase Db2 Warehouse セッション資料 db tech showcase
Db2 Warehouse セッション資料 db tech showcase
 
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
 
マルチコアとネットワークスタックの高速化技法
マルチコアとネットワークスタックの高速化技法マルチコアとネットワークスタックの高速化技法
マルチコアとネットワークスタックの高速化技法
 
BOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA JapanBOSTON Viridis for Hadoop by ELSA Japan
BOSTON Viridis for Hadoop by ELSA Japan
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
 
20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow
 
Hadoopを用いた大規模ログ解析
Hadoopを用いた大規模ログ解析Hadoopを用いた大規模ログ解析
Hadoopを用いた大規模ログ解析
 
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか  by 日本ヒューレット・パッカード株式会社 後藤宏[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか  by 日本ヒューレット・パッカード株式会社 後藤宏
[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)
 
Linux packet-forwarding
Linux packet-forwardingLinux packet-forwarding
Linux packet-forwarding
 

Similar to [db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作所 福井正志

FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化Kazunori Sato
 
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi FukuiInsight Technology, Inc.
 
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji FujiwaraInsight Technology, Inc.
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)Insight Technology, Inc.
 
RDMA for Windows Server 2012
RDMA for Windows Server 2012RDMA for Windows Server 2012
RDMA for Windows Server 2012Naoto MATSUMOTO
 
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Web Services Japan
 
プログラマ目線から見たRDMAのメリットと その応用例について
プログラマ目線から見たRDMAのメリットとその応用例についてプログラマ目線から見たRDMAのメリットとその応用例について
プログラマ目線から見たRDMAのメリットと その応用例についてMasanori Itoh
 
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明Insight Technology, Inc.
 
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...Insight Technology, Inc.
 
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみたNissho Lab
 
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...Insight Technology, Inc.
 
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu MorinakaD23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu MorinakaInsight Technology, Inc.
 
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....Insight Technology, Inc.
 
Web Service on SSD
Web Service on SSDWeb Service on SSD
Web Service on SSDKazuho Oku
 
IDCFクラウドセミナー RDB活用
IDCFクラウドセミナー RDB活用IDCFクラウドセミナー RDB活用
IDCFクラウドセミナー RDB活用IDC Frontier
 
Scale flux roi&performance_acri
Scale flux roi&performance_acriScale flux roi&performance_acri
Scale flux roi&performance_acri直久 住川
 
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)Kazuyuki Sato
 
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~griddb
 

Similar to [db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作所 福井正志 (20)

FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
 
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
[C13] フラッシュドライブで挑むOracle超高速化と信頼性の両立 by Masashi Fukui
 
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
[C14] 超高速データベースエンジンを用いたTPC-Hベンチマーク100TBクラス世界初登録への挑戦 by Shinji Fujiwara
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
 
RDMA for Windows Server 2012
RDMA for Windows Server 2012RDMA for Windows Server 2012
RDMA for Windows Server 2012
 
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデートAmazon Redshift パフォーマンスチューニングテクニックと最新アップデート
Amazon Redshift パフォーマンスチューニングテクニックと最新アップデート
 
プログラマ目線から見たRDMAのメリットと その応用例について
プログラマ目線から見たRDMAのメリットとその応用例についてプログラマ目線から見たRDMAのメリットとその応用例について
プログラマ目線から見たRDMAのメリットと その応用例について
 
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
B14 SQL Server over SMB using infiniBand and SSD by Mario Broodbakker/市川明
 
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
 
POWER8ここだけの話
POWER8ここだけの話POWER8ここだけの話
POWER8ここだけの話
 
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた
【MySQL編】サーバ環境が進化する今話題のPCIe SSDを評価してみた
 
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
[db tech showcase Tokyo 2015] D13:PCIeフラッシュで、高可用性高性能データベースシステム?! by 株式会社HGSTジ...
 
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu MorinakaD23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
D23 SSDで挑むOracle超高速化と信頼性の両立 by Yuu Morinaka
 
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....
[db tech showcase Tokyo 2016] B22: 超高速NoSQLデータベースと超高速SSDの融合 by Aerospike Inc....
 
Web Service on SSD
Web Service on SSDWeb Service on SSD
Web Service on SSD
 
IDCFクラウドセミナー RDB活用
IDCFクラウドセミナー RDB活用IDCFクラウドセミナー RDB活用
IDCFクラウドセミナー RDB活用
 
Scale flux roi&performance_acri
Scale flux roi&performance_acriScale flux roi&performance_acri
Scale flux roi&performance_acri
 
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)
「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(仮)
 
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
サイバーフィジカルシステム(CPS)に必要なデータ基盤を考える ~ NoSQL/SQLハイブリット型GridDB ~
 
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
[dbts-2014-tokyo] 目指せExadata!! Oracle DB高速化を目指した構成
 

More from Insight Technology, Inc.

グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?Insight Technology, Inc.
 
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Insight Technology, Inc.
 
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明するInsight Technology, Inc.
 
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーンInsight Technology, Inc.
 
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとMBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとInsight Technology, Inc.
 
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?Insight Technology, Inc.
 
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームDBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームInsight Technology, Inc.
 
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門Insight Technology, Inc.
 
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 Insight Technology, Inc.
 
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也Insight Technology, Inc.
 
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー Insight Technology, Inc.
 
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?Insight Technology, Inc.
 
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Insight Technology, Inc.
 
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?Insight Technology, Inc.
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...Insight Technology, Inc.
 
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 Insight Technology, Inc.
 
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Insight Technology, Inc.
 
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]Insight Technology, Inc.
 

More from Insight Technology, Inc. (20)

グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
 
Docker and the Oracle Database
Docker and the Oracle DatabaseDocker and the Oracle Database
Docker and the Oracle Database
 
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
Great performance at scale~次期PostgreSQL12のパーティショニング性能の実力に迫る~
 
事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する事例を通じて機械学習とは何かを説明する
事例を通じて機械学習とは何かを説明する
 
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
仮想通貨ウォレットアプリで理解するデータストアとしてのブロックチェーン
 
MBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごとMBAAで覚えるDBREの大事なおしごと
MBAAで覚えるDBREの大事なおしごと
 
グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?グラフデータベースは如何に自然言語を理解するか?
グラフデータベースは如何に自然言語を理解するか?
 
DBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォームDBREから始めるデータベースプラットフォーム
DBREから始めるデータベースプラットフォーム
 
SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門SQL Server エンジニアのためのコンテナ入門
SQL Server エンジニアのためのコンテナ入門
 
Lunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL ServicesLunch & Learn, AWS NoSQL Services
Lunch & Learn, AWS NoSQL Services
 
db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉 db tech showcase2019オープニングセッション @ 森田 俊哉
db tech showcase2019オープニングセッション @ 森田 俊哉
 
db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也db tech showcase2019 オープニングセッション @ 石川 雅也
db tech showcase2019 オープニングセッション @ 石川 雅也
 
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
db tech showcase2019 オープニングセッション @ マイナー・アレン・パーカー
 
難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?難しいアプリケーション移行、手軽に試してみませんか?
難しいアプリケーション移行、手軽に試してみませんか?
 
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
Attunityのソリューションと異種データベース・クラウド移行事例のご紹介
 
そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?そのデータベース、クラウドで使ってみませんか?
そのデータベース、クラウドで使ってみませんか?
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
 
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。 複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
複数DBのバックアップ・切り戻し運用手順が異なって大変?!運用性の大幅改善、その先に。。
 
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
Attunity社のソリューションの日本国内外適用事例及びロードマップ紹介[ATTUNITY & インサイトテクノロジー IoT / Big Data フ...
 
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
レガシーに埋もれたデータをリアルタイムでクラウドへ [ATTUNITY & インサイトテクノロジー IoT / Big Data フォーラム 2018]
 

Recently uploaded

バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析sugiuralab
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。iPride Co., Ltd.
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))yoshidakids7
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版Takayuki Nakayama
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313ssuserf8ea02
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りiPride Co., Ltd.
 
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」IGDA Japan SIG-Audio
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024Hideki Saito
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~honeshabri
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜Naomi Yamasaki
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG-Audio
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整えるonozaty
 

Recently uploaded (12)

バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作り
 
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整える
 

[db tech showcase Tokyo 2014] B23: SSDとHDDの混在環境でのOracleの超効率的利用方法 by 株式会社日立製作所 福井正志

  • 1. © Hitachi, Ltd. 2014. All rights reserved. 株式会社日立製作所 ITプラットフォーム事業本部 2014/11/12 SSDとHDDの混在環境での Oracleの超効率的利用方法 db tech showcase Tokyo 2014 Session 3 B23
  • 2. © Hitachi, Ltd. 2014. All rights reserved. 1.従来DBシステムの問題点
  • 3. © Hitachi, Ltd. 2014. All rights reserved. ソフト/ハード別原因と対策方法は ソフト的な要因 ハード的な要因 CPU メモリー I/O SQL 機能 パラメータ 構造 CPU/メモリー追加は簡単にできる対策。 CPUがボトルネックになっているとしても それは一瞬のことが多い。 I/O、ストレージネックの場合は、それを 解消すればCPU/メモリーをもっと使え、 大きく性能向上の可能性あり。 簡単に高速化するにはリプレース時にI/Oやストレージを強化 パラメータチューニングは、実はほとん ど効果なし。 性能が良くなる機能なら最初から導入 している。 構造やSQLで性能は大きく変わるが、 そう簡単には変えられない。 ストレージ CPU メモリー I/O SQL 機能 パラメータ 構造 ストレージ 性能への効果 変更の難易度 性能への効果 変更の難易度 難易度・工数大 1-1. DBが遅い原因 リプレース時は難易度同じ
  • 4. © Hitachi, Ltd. 2014. All rights reserved. 1 10 20 相対性能 2005 2006 2007 2008 2009 2010 2011 5 15 2012 25 30 2013 10倍 HDD回転数 1倍  CPU性能はコア数の増加と共に劇的に向上している。  CPU性能の伸びに比べ、HDD回転数やFC帯域は伸びていない システム構成は今でも2005年と同じ作りだが、それで良いのか ※CPU性能はSAP SDベンチ マークをベースにした値 4倍 4core 6core 2core 32倍 8core 12core 2005年を1とした時の性能推移 1-2. H/Wの性能進化の不均衡
  • 5. © Hitachi, Ltd. 2014. All rights reserved. 100 90 80 70 60 50 40 30 20 10 0 (%) CPU,LAN,FC,HDDの使用率の状況は  CPUはあまり稼働率が上がらず、底辺を這っている様な状態。  HDDは常に稼働し続けており、ほぼ100%張りつきの状態。  LANは使っている時と使っていない時の差が激しい状態。  FCの帯域はまだまだ余裕があるが、CPUよりは使われている状態。 HDDとLANの高速化を行えば、システム性能が上がる HDDの使用率は OSの性能モニタでは 直接表示されない パーツ使用率のイメージ 1-3. 2005年と同じ構成のシステムでは HDDの使用率が ボトルネックなのが 実は分かりにくい!
  • 6. © Hitachi, Ltd. 2014. All rights reserved. ス トレ ー ジ キャッ シュ 円盤に書かれたデータが来るまで待つ データ 要求 日付 都市 時間 気温 7/8 東京 12:00 28° 7/8 大阪 14:00 32° 7/8 名古屋 14:00 35° 7/9 甲府 13:00 37° 7/9 京都 14:00 36°  HDDは円盤にデータが記録されている。  円盤は1分間に15,000回転している。  目的のデータがヘッドまで来ると読み出せる。 例えば、 7/9の京都の最高気温が知りたい  ヘッドの移動(データのあるトラックまで移動)  回転待ち(最大1回転:1/15,000分=1/250秒) アプリケーション サーバ データベース サーバ 要求 データ 要求 要求 データ データ つまりHDDは1秒間に最悪250件しか読めないから遅い。 1-4. HDDのデータリード処理の問題点
  • 7. © Hitachi, Ltd. 2014. All rights reserved. 1-5. HDD I/O性能基本データ 570 MB/s HDDはランダムアクセスが苦手 73 MB/s 360 MB/s SAS 15,000回転/s, RAID5:4D+1P ブロックサイズ:512KB, 多重度:8 1 7.8 リード帯域性能 シーケンシャル ランダム 19 MB/s 1 19 ライト帯域性能 シーケンシャル ランダム 少しでもランダムアクセスがあるとHDD性能はガタ落ち
  • 8. © Hitachi, Ltd. 2014. All rights reserved. ※DMA: Direct Memory Access メモリー空間 PCI-Eバス メモリーバス  HDDからデータを読む場合、CPUはHDD のアドレスとメモリーのアドレスを指定。  転送開始を指示したら、CPUは何もしなく ても良い。FCカードがDMAで処理する。  データ転送中はバスが競合しなければ、 CPUは他の計算などをすることが可能。  FCカードから完了報告が上がれば終了。 1-6. I/OとCPUの関係 I/OはCPUを使わずに処理される DMAでHDDからメモリーにデータ移動 FC FCカード データ転送中は他の計算が無ければ CPUはやることが無く使用率は下がる。 I/Oを多用する処理は、CPU使用率が下がる! 割込み (終了)
  • 9. © Hitachi, Ltd. 2014. All rights reserved. バッチ処理こうなってますよね I/Oが滞らない様に、Flashで一気にストレージ能力を高めてしまう バッチはオンラインの何倍ものデータにア クセスし、リードもライトも発生する。 1つのデータベースに数十のバッチを一夜 で流し、多重処理は当たり前。 月末/期末処理は日次バッチに更に追加 する為、想定を超えた遅さになってしまう。 I/Oが大量に滞ると CPU使用率が下がる CPUが空いているので、 更にバッチを多重化する 月askfdi 月hfewhfw 月dafhf 月iufif 月iofif 月dafhf 月次バッチ 17:00 18:00 19:00 20:00 21:00 22:00 23:00 24:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 s;lkfjdsk dfiefdh uewrh cvhvu fvn efhdcdgj vdisdifj eiruw cvkj gori sdiufiowuifkej kdfvjakfd kdj vjadijiafke dfjdiauid cxdkvjvk fdksjf eifwjeifkf svid dviajidgjidgigjg difdsadifiew HDDが追い付かずI/Oが滞る 1-7. バッチ処理のやりがちなこと
  • 10. © Hitachi, Ltd. 2014. All rights reserved. 2.フラッシュを使った高速化構成
  • 11. © Hitachi, Ltd. 2014. All rights reserved. ストレージ サーバ P P 今までのシステム構成は サーバからFCケーブルが2本ストレージ に接続されている。 HDDはRAID構成で組まれている。 サーバ1台(またはActive-Standby)の構成 ★単純にHDDをSSDに 置き換えただけだと... コントローラ コントローラ P P P P P P P P RAID構成 ストレージの内部バス帯域限界を超える。 コントローラーの処理性能が不足する FCポートの帯域限界を超える せっかくのSSDの高速性が、今までの構成では引き出せない! 2-1. SSDに変えるとどうなるか
  • 12. © Hitachi, Ltd. 2014. All rights reserved. ボトルネックを極力排除する ストレージ サーバ サーバ 10G NIC 10G LANSW 10G LANSW 10G NIC 10G NIC 10G NIC Bonding Bonding RAC Interconnect Ctrl0 Ctrl1 Ctrl2 Ctrl3 8Gbps x 16 FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC P P P P P P P P P P P P P P P P 1G NIC 1G NIC Bonding 1G NIC 1G NIC Bonding Public LAN サーバは2台以上で Oracle RAC構成に 可用性と性能を両立 処理性能ネックを回避 する為にSSD数に 応じたコントローラ数を 処理能力が上がるため、 RACインターコネクトは、 10Gの冗長構成が必要 内部バスがボトルネック にならない様なSSDの スロット配置を行う FCはSSDの数に応じ 帯域を確保できる本数 並列性と可用性に効果 これが理想のSSDシステム 2-2. 高速化を実現するハードウェア構成
  • 13. © Hitachi, Ltd. 2014. All rights reserved. ストレージ 使い 過ぎ 少な 過ぎ FC 利用率 100% 0% SSDは1本当たり6Gbps(600MB/s)に近い帯域を出すことが 可能であり、SSDが多いとFCも それに応じた本数が必要。 FCが増えるとRAIDから切り出 すLUも複数必要になる。 しかしLUが複数になると、どの データをどのLUに割り当てるか 検討が必要になる。 検討不十分だとLUのデータ占 有量が不揃いになったり、アクセ ス頻度が偏る。 高速化構成の副作用 LU サーバ HBA (FCカード) TableC TableA TableD TableB 2-3. 複数LUへのDB配置
  • 14. © Hitachi, Ltd. 2014. All rights reserved. LU Oracle ASM 最高のパフォーマンス 複数LUをうまく使うには、 Oracle ASMを使用すること で対応が可能。 複数LUがストライピングされ、 全てのLUを均等に利用可能。 FC帯域も均等に利用でき、パ フォーマンスも向上。 遅いLUが混在していると性能 が引きずられ、DB全体が遅く なることがある。 理想構成では全てSSDで統一 しており、最高のパフォーマン スを発揮可能。 FC 利用率 100% 0% HBA (FCカード) 複数LUをまとめて管理 TableA TableB TableC TableD 2-4. サイズやアクセス頻度の偏りの無いASM
  • 15. © Hitachi, Ltd. 2014. All rights reserved. 3.HDDとFlashの混在環境をOracleで使う
  • 16. © Hitachi, Ltd. 2014. All rights reserved. 3-1. フラッシュの価格は今後どうなるのか ビットコストの動向 ‘05 ’06 ’07 ’08 ’09 ’10 ’11 ’12 ’13 ’14 ’15 ’16 ’17 ’18 ’19 ‘20 デバイス技術動向調査結果(日立調べ) 各デバイスのビットコスト推移予想 ビットコスト($/GB) 100 10 1 0.1 0.01 0.001 MLC SSDと SAS HDDが 逆転する 数年後にはSAS HDDよりSSDの方が安くなる。 しかし今時点では、まだSSDが高いのでオールSSDは無理
  • 17. © Hitachi, Ltd. 2014. All rights reserved. アクセス頻度の高い領域のみ、 Flashを使用すれば、性能は改 善されるはず。 例えば、常にアクセスのある RedoやTempは必ずFlashに配 置する。 容量が確保できればアクセスの 多いデータやインデックスも Flash化したい。 実際に本構成で性能測定した 所、RedoとTempだけでは、 37%しか性能向上しなかったが、 データまで入れると数倍の性能 向上が確認できた。 Flashを別領域として管理 TableD TableA TableB TableC 3-2. HDDとFlashを混在で使用する Oracle ASM Redo Temp
  • 18. © Hitachi, Ltd. 2014. All rights reserved. Oracleのレポートから配置を考える statspackやAWRレポートからアクセス頻度の高いテーブルやインデックスをフラッシュに配置。 3-3. アクセス頻度からHDD/Flashに配置 Segments by Physical Reads DB/Inst: TPCCDB/tpccdb Snaps: 1-2 -> End Segment Physical Reads Threshold: 1000 Subobject Obj. Physical Pct Owner Tablespace Object Name Name Type Reads Total ---------- ---------- -------------------- ------------ ----- ------------ ----- ABCC TPCC_STOCK SYS_IOT_OVER_18164 TABLE 1,316,772 36.4 ABCC TPCC_OTHER CUSTOMER TABLE 1,275,890 35.3 ABCC TPCC_USERS S_PK INDEX 358,444 9.9 ABCC TPCC_USERS C_WDI INDEX 130,404 3.6 ABCC TPCC_USERS O_WDCI INDEX 117,105 3.2 ------------------------------------------------------------- statspackの例 既存DBからの移行の場合は事前に調査できる為、フラッシュの搭載容量の検討が可能だが、 新規DBの場合にはサイジングが難しい。 大きなテーブルではアクセス頻度にムラがあっても、テーブル全部を乗せる必要あり。 テーブル数が少ない場合は、SSDの容量とテーブルの容量を考えて配置しなければならない。 定期的に見直しをして、性能が不十分の場合には配置換えや容量追加も検討する必要あり。 欠点も 結構手間もかかり手動はいまいち。自動でうまくできないか。
  • 19. © Hitachi, Ltd. 2014. All rights reserved. Flashをキャッシュとして利用する 3-4. HDDとFlash混載利用の自動化(1) ・LSI-LogicのRAIDカード搭載Cache-Cade Ver.1を利用 ・キャッシュクリア後の測定結果 ・HDDは10K回転×3D+1Pのライトバック設定(ライトキャッシュ有効) 1.49倍 Flashにデータを自動的にキャッシュする為、アク セス頻度調査やデータ選択の必要無い。 Flash溢れの心配が無く、データの見直し等の煩わ しさも発生しない。 アクセスに追従するのが速く、効果が表れやすい。 利点 欠点 全体的なアクセス頻度は見ていない為、単発の アクセスでもFlashに上がったり、少しアクセスが 無いと消されることがある。 キャッシュクリア後測定の影響もあるが、2倍に満 たない性能しか得られなかった。 Flashの性能向上効率としては、これはかなり悪い SSDキャッシュ(リード)を使用した場合のOLTP性能
  • 20. © Hitachi, Ltd. 2014. All rights reserved. アクセス回数に応じてFlashに配置する 3-5. HDDとFlash混載利用の自動化(2) キャッシュと違い長期統計で配置する為、DB等の蓄積型データに最適 アクセス頻度 高 低  データをブロックに分割し、ブロック毎にアクセ ス頻度を計測し、アクセスの激しいブロックは Flashに配置する。  具体的にはブロック毎のアクセスカウンターを持ち、 アクセス毎にカウントアップする。  アクセス頻度は時間と共に変化する為、一定期間 毎に再計測し、頻度が変化したものは再配置する。 効果 機能  アクセス頻度の激しいブロックはFlashに配置され ており、高速に処理可能。  テーブル丸ごとでは無く、小さなブロック毎に配置さ れる為、効率良くFlashに配置することが可能。  自動で配置される為、ユーザはアクセス頻度の検 討が必要無く、新規のシステムでも利用可能。 3 6 2 5 3 7 1 5 2 3 253 36 48 4 9 59 1 67 6 8 2 1 94 8 77 4 1 74 182 82 5 69 9 75 85 2 58 1 83 71 65 44 110 39 53 87 68 95 55 235 210 137 196 173 188 47 74 101 183 86 245 256 145 205
  • 21. © Hitachi, Ltd. 2014. All rights reserved. 仮想ボリューム HDDとのハイブリッドでも高速アクセス Hitachi Dynamic Tiering Tier1 プール 3-6 日立ストレージのボリューム自動階層制御 自動 再配置 新しいデータ 古いデータ Tier2 サーバに見せるLU。 容量は自由に設定可能。 実データはブロック単位でプール の領域が割り当てられる。 SSDとHDDでTierを構成。 新規データはTier1のSSD領 域が割り当てられる。 Tier1の空容量を一定に保つ 様に再配置が行われる。 再配置で古くなったデータは、 HDDに移動される。
  • 22. © Hitachi, Ltd. 2014. All rights reserved. カウンターはアクセス回数-経過時間 3-7. HDTはデータの新鮮度も加算して移動 何をFlashに残したいかにより、再配置タイミングを設定  カウンターはアクセス回数で上 昇するが、時間が経過すること で下降する機構となっている。  カウンター値はアクセスされな ければ次第に下がってゆく。  設定したSSDの空き容量になる 様に、再配置で調整される。 運用と動作 アルゴリズム  カウンターの計測とSSD⇔HDDの再配置タ イミングは設定可能。  バッチ終了後に再配置をすることで、SSDに データが残り、バッチの高速化が可能。  マスター表等のデータは常にアクセスされ カウンターが下がらず、常にFlashに配置。 ▲ 再配置 ▲ 再配置 1日 オンライン バッチ オンライン バッチ オンライン アクセス頻度 この枠内は 高 低 アクセスあり 枠外は無し … 1日 1ヶ月 ▲ 日時バッチ ▲ 月次バッチ ▲ 再配置
  • 23. © Hitachi, Ltd. 2014. All rights reserved. 4.HDDとFlashの混在環境の性能
  • 24. © Hitachi, Ltd. 2014. All rights reserved. 4-1. 一般的な企業データの傾向 課題は、Flashに格納すべきデータの判断 頻繁にアクセスされるデータがFlashに格納されていれば 性能要件は満たせ、コストも最適化できる。 一般的な企業データの傾向 ・履歴データが蓄積されていき、SQLのほとんどは直近データを参照する ・実際に業務で扱うデータは全容量の数%~20%程度なことが多い 企業DBでは格納された全てのデータが用いられるわけではない 必要なデータだけをFlashに格納することが出来れば十分な高速化 5年前 3年前 1年前 3ヶ月前 1ヶ月前 現在 ・履歴表とマスタ表(ユーザ、商品等)があり、履歴表は日々増加する
  • 25. © Hitachi, Ltd. 2014. All rights reserved. 4-2. Flashを用いたDBの高速化方式 採用方式を事前に検討する必要がある Flashを用いたDBの高速化方式は様々 導入の手間/コスト/性能を考慮して採用しないと、効果が薄いことも 手動配置 (REDO/TEMP) SSD キャッシュ 手動配置 (高アクセス領域) Hitachi Dynamic Tiering (HDT) ALL-Flash 導入の手間 △(設定要) ○ ×(設計要) △(設定要) ○ 価格 ○ ○ △ ○ × HDD性能比(OLTP) △ △ ○ ◎ ◎ コスト パフォーマンス △ △ △ ◎ △ REDO TEMP Cache REDO TEMP USER_H USER_L USER_H USER_L REDO TEMP USER_H USER_L REDO TEMP USER_H USER_L REDO TEMP USER_H USER_L USER_H: 高アクセス表 USER_L: 低アクセス表 ※ 日立測定環境での数値。性能は、構成により異なります
  • 26. © Hitachi, Ltd. 2014. All rights reserved. 内蔵HDD 高アクセスTop5表をPCI-Flash格納ALL-内蔵PCI Flash 4-3. 手動配置によるHDD/FlashのHybrid構成 手動配置によるハイブリッド構成には限界がある Obj. Physical Owner Object Name Type Reads --------- ---------------------------------- ---------- -------------- TPCC SYS_IOT_OVER_18164 TABLE 1,316,772 TPCC CUSTOMER TABLE 1,275,890 TPCC S_PK INDEX 358,444 TPCC C_WDI INDEX 130,404 TPCC O_WDCI INDEX 117,105 乗り切らなかった分 高アクセス表のFlash手動配置で得られる効果は限定的 DBの統計レポートを見ても、Flash格納が必要なデータを解析するのは困難 REDO TEMP USER01 USER02 一般的なオンライン処理のトランザクション処理数/分 (3D+1P) HDD(3D+1P) PCI-Flash(1D+1D) (1D+1D) ※ 日立測定環境での数値。性能は、構成により異なります
  • 27. © Hitachi, Ltd. 2014. All rights reserved. 100% 107% 183% 0% 100% 200% ALL-HDD HDT(SSD10%) ALL-SSD ALL-HDD HDT(SSD10%) ALL-SSD ALL-HDD HDT(SSD10%) ALL-SSD トランザクション処理数/分 4-4. OracleDBにおけるHDTの効果 HDTを用いて低コストでDB高速化を実証 Oracle DatabaseにおけるHDTの費用対効果 一般的なオンライン処理を模したベンチマークで、 HDTでDB領域の10%をFlash(SSD)化することで約19倍の高速化を実現 導入コスト比較 Hitachi Dynamic Tiering (4D+1P)×4 (4D+1P)×4 SSD(4D+1P) (6D+1P)×4 ※ 日立測定環境での数値。性能は、構成により異なります
  • 28. © Hitachi, Ltd. 2014. All rights reserved. 400 600 1000 1200 800 4-5 手動配置に対するHDTの優位性 Name Reads Reads %Total Table/Index Size[GB] Size %Total S_OV_TS001 26,433,536 41.1% 102.9 8.2% C_TS001 17,985,689 27.9% 54.8 4.3% OL_TS001 8,643,158 13.4% 78.3 6.2% O_WDCI_TS001 5,353,041 8.3% 5.6 0.4% OL_WDO_TS001 2,164,236 3.4% 32.3 2.6% Top5 94% 273.9 22% Total 100% 1261.6 100% 120GB = 10% 274GB = 22 >> Oracle 統計レポート AWR [Top5 Disk Read統計] Oracleの統計レポートから確認できるDisk Read Top5(Read全体の94%)の領域はDB全体の 22% HDTから確認できるアクセス頻度境界は1000[IOPH ]、10%で前述の通りALL-SSDと同程度の性能 一般的に履歴表は最近のデータのみ高アクセス 全てをFlashに載せる必要はない。 効率的なFlash活用 性能が安定 手動配置 × 表全体を移動する必要有 移動もSE作業 × アクセス傾向が変化するたびに 対応が必要 HDT使用 ○ ページ単位で 配置場所を判断 ○ 定期的に自動で再配置するため、 性能が安定 120 (10%) HDTによるアクセス頻度に応じた自動配置の優位性
  • 29. © Hitachi, Ltd. 2014. All rights reserved. 約5倍高速 約40倍高速 4-6. Flash活用の次はIn-Memory機能の活用 更なる高速化にはOracle 12c In-Memory Optionも Oracle Databaseの機能を最大限に引き出す 標準機能のみ 2Node RAC環境における, 分析系業務SQLの処理時間比較 *1:テーブルをバッファキャッシュ上に キャッシュする *2:複数ノードでの分散処理 分析系SQLで約40倍の性能向上を実証 In-Memory Option In-Memory ※ 日立測定環境での数値。性能は、構成により異なります 検証構成 HDD:15Krpm RAID5(9D+1P) Memory:256GB(In-Memory時はDB全て格納) 新機能の列格納メモリ空間の使用 In-Memory Option インターノードパラレルクエリ(*2) 既存の行バッファメモリ空間へのキープ Buffer Pool:Keep(*1) インターノードパラレルクエリ(*2)
  • 30. © Hitachi, Ltd. 2014. All rights reserved. バッチSQL実行時間 4-7. Flash+In-Memoryの実力 Flash+In-Memoryはさらなる高速化を実現 バッチ処理で実施される集計演算と検索更新を実施 バッチ処理などの複雑な処理の高速化はFlash+In-Memoryで実現可能 … SSD(7D+1P)×2 ・・・ HDD(6D+1P) 7,200rpm … SSD(7D+1P)×2 In-Memory HDD Flash Flash ※ 日立測定環境での数値。性能は、構成により異なります Memoryは全て256GB 約3.1倍高速化(バッチ合計) 約4.0倍高速化(バッチ合計) (ALL-Flashの更に1.3倍) 集計 集計 集計 検索更新 検索更新 検索更新 約9.3倍高速化(集計) 約39倍高速化(集計) (ALL-Flashの更に4.2倍)
  • 31. © Hitachi, Ltd. 2014. All rights reserved. 4-8. DBを階層化するにあたって重要なこと 要件に応じて最適なFlash/Memory/機能の選択が重要 In-Memory コスト 導入の 手間 + 性能 コスト パフォーマンス 将来の DB要件 増加量 + 性能劣化 手動配置? 自動配置? ALL-Flash? In-Memory?
  • 32. © Hitachi, Ltd. 2014. All rights reserved. •OracleとJavaは,Oracle Corporation 及びその子会社,関連会社の米国及びその他の国における登録商標です。 •Intel Xeonは,アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。 •Linuxは,Linus Torvalds氏の日本およびその他の国における登録商標または商標です。 •その他、記載の会社名、製品名は、それぞれの会社の商標または登録商標です。 •製品の改良により予告なく記載されている仕様が変更になることがあります。 他社商品名、商標等の引用に関する表示