RDBMSでも大規模データをあきらめないためには
第2回 最大の課題「I/Oボトルネック」の原因と分析法
I/ Oの 「レスポンス」 と 「スループット」 とは?
連載第1回でご紹介したように,
ここでは,
- I/
Oレスポンス=I/ O要求処理にかかる応答時間 - I/
Oスループット=単位時間当たりのI/ O処理量
Oracle Databaseに当てはめると,
- I/
Oレスポンス=1データブロックの読み出しや書き込みにかかる時間 - I/
Oスループット=単位時間あたりの読み出しや書き込みの量
レスポンスにフォーカスすべき場合, スループットにフォーカスすべき場合
I/
レスポンスにフォーカスするケース
オンライントランザクション
このように,
スループットにフォーカスするケース
売上分析など,
したがって,
まとめると以下のとおりです。
- ミクロなI/
O性能を論じる場合 ⇒レスポンスを考える - マクロなI/
O性能を論じる場合 ⇒スループットを考える
大規模データ処理の場合は,
ディスクI/ Oボトルネックのパターンを知る
ディスクI/
そもそも,
- I/
O時間 = ストレージがデータを取得する時間 - + ストレージからデータベースへデータを転送する時間
- + データベースサーバでI/
O処理を行う時間
ここでは,
ストレージがI/ Oボトルネックとなる場合
ケース1 ストレージのI/ O帯域幅やCPUの性能限界を超える
たとえば,
大規模なデータ処理が必要となるシステムの場合,
ケース2 同一ディスクへのアクセス競合が発生する
同一のディスクにアクセスが集中すると,
ストレージ―データベース間のネットワークがI/ Oボトルネックとなる場合
意外と盲点になりやすいですが,
データベースがI/ Oボトルネックとなる場合
ケース1 SQL, もしくはSQLの実行計画が不適切で, 不要なI/ Oを実施している
CPUやI/
- 実行計画に直積が選択された場合
- 同一データに複数回アクセスしてしまうSQLがある場合
ケース2 索引, エクステント, ブロックが断片化している
Oracle Databaseにおいては,
大規模データ処理を行うデータベースにおいては,
I/ Oボトルネックを分析するには
Oracle Databaseにて,
AWRでOracle Databaseの性能を分析する
AWR
I/
おもに以下の待機イベントによる待機時間の割合が大きい場合には,
- db file sequential read
- db file scattered read
- direct path read
- log file sync
vmstat/ iostatでOS観点からI/ O性能を分析する
UNIX系OSの場合,
vmstatの場合,
iostatの場合,
では,
次回は,
この記事に関連する書籍
-
データベースの限界性能を引き出す技術 ~NoSQLに飛びつく前に知っておきたい原理と最新テクニック
「RDBMSだと大規模データをうまく扱えない」といわれ,NoSQLのような代替技術が生まれてきていますが,本当でしょうか? ビッグデータ時代でもシステムの中核として...