社内サーバインフラ勉強会(DB)

サーバインフラ勉強会データベース編

今回の目的1. 「データを保存する」ということが、実際にどういうことなのかを知る。2. 中の動作を踏まえることで、効率のよいアプリを書けるようになる。3. 問題が起きたときに、その原因を突き止められるようになる。一般論をメインとし、MySQL等の細かい個別ノウハウは取り上げません。

おしながき1. 「データを保存する」とはどういうことか2. MySQLがディスクに書くまで3. 仮想メモリとページキャッシュ4. とっても複雑なストレージの動作5. MySQLのインデックスとメモリの関係

「データを保存する」とは• システム内のデータを、それを必要とする期間にわたり、読み書きできるようにすること書き込み必要な期間だけデータを保持読み取り

「データを保存する」とは• システム内のデータを、それを必要とする期間にわたり、読み書きできるようにすること書き込みどれぐらいの期間なのかどのようなデータなのかどのデータを必要な期間だけ読み取るのかデータを保持読み取り

「データを保存する」とは• システム内のデータを、それを必要とする期間にわたり、読み書きできるようにすること一般的なRDBMSの場合書き込み消すまで残す複数の数値や文字列が集まったかたまり（行）データのかたまり必要な期間だけ毎に振られたデータを保持数値(PKEY)を指定読み取り

じゃあ実際どうなっているのか（Linux+MySQLの場合）ウェブサーバ DBサーバ MySQL アプリ SQL処理ストレージエンジンクエリキャッシュバッファ本体システムコールネットワークネットワークカーネルカーネル VFS・キャッシュスタックスタックファイルシステム (EXT3) デバイスドライバ NICドライバデバイスドライバ (NIC) (SATA) ネットワークネットワークネットワークルータ・スイッチ SATAハードディスクインターフェースインターフェース

ネットワーク部分を省略（Linux+MySQLの場合） MySQL アプリ SQL処理ストレージエンジンクエリキャッシュバッファ本体システムコールサーバ内の場合でも、カーネル VFS・キャッシュ実際にはカーネルの EXT3 ファイルシステムネットワークスタックをデバイスドライバ通るので注意（あくまで簡略化） SATAハードディスク

MySQLからハードディスクまで MySQL アプリ SQL処理ストレージエンジンクエリキャッシュバッファ本体まずはこの部分に注目しますシステムコールカーネル VFS・キャッシュ EXT3 ファイルシステムデバイスドライバ SATAハードディスク

MySQLがディスクに書くまでのおおまかな流れ1. MySQL→カーネルシステムコールを用いて、書き込むデータをカーネルに送る。2. システムコール→VFS （以下カーネル内）システムコールのルーチン内で、LinuxのVFS（仮想ファイルシステム）に書き込み指示を送る。3. VFS→EXT3 VFSは、書き込み先ディレクトリがEXT3でマウントされたファイルシステムであることを特定し、EXT3のモジュールに書き込み指示を送る。4. EXT3→デバイスドライバここでようやく実際にファイルの記録方法が実装されているため、ハードディスク上における記録先アドレスを算出し、デバイスドライバに書き込み指示を送る。5. デバイスドライバ→SATA HBA（コントローラ）デバイスドライバは、記録先アドレスをハードディスクのパーティション情報などを踏まえた物理的な書き込み先アドレスに変換し、HBAに指示6. SATA HBA→ハードディスク HBAはメモリから書き込み内容を受け取り、SATAのコマンドとしてハードディスクに書き込み内容を送信7. 書き込み成功したら、その結果を今までの逆順でMySQLまで戻す。実際にはもっと複雑です。（ディスクへの書き込みは非同期、など）

仮想メモリ• Unix環境では、仮想メモリを利用します。 – 物理的なメモリのアドレスを、仮想的なメモリの空間にマッピング – プロセスごとに仮想メモリ空間が用意され、そこに開けられた「窓」を通じて物理メモリにアクセス – 窓のあいていない仮想メモリにアクセスすると「Segmentation fault」

仮想メモリでコピーを抑止1. MySQL→カーネル2. システムコール→VFS 書き込みデータの3. VFS→EXT3 アドレスのみを渡しデータ自身のコピーは行わない4. EXT3→デバイスドライバ5. デバイスドライバ→SATA HBA 書き込みデータの6. SATA HBA→物理ディスクアドレスを受け取り、 HBAがメモリから直接データを持って行く（DMA）

ページキャッシュ• 仮想メモリ上でやりとりしたデータを、消さずにそのまま再利用→ページキャッシュ• VFS内で、1ページ＝4KBごとにキャッシュ – ファイル1個ずつに振られたiノード番号 – ファイル内の位置（オフセット）• Linuxではメモリが足りる限りページキャッシュを残す。• 実際にはページキャッシュに書いた時点で、システムコールはアプリに処理を戻す。

ページキャッシュhttp://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_01c.html より引用

MySQLからハードディスクまで MySQL アプリ SQL処理ストレージエンジンクエリキャッシュバッファ本体システムコールカーネル VFS・キャッシュ EXT3 ファイルシステム次はここデバイスドライバ SATAハードディスク

SATAハードディスクへの読み書き• 基本的な動作（単体のSATAディスクの場合） 1. デバイスドライバがSATAのコマンドを作成 2. SATAインターフェースカードがコマンドをSATA ケーブルに送信 3. ハードディスクがSATAコマンドを受信 4. 書き込み位置にヘッドを移動 5. 回り続けるディスクで、ヘッドの下に書き込み位置が来たところで磁気を使って書き込み

複雑になる要因コマンドキューイング• ハードディスクが遅い最大要因： • 「回り続けるディスクで、ヘッドの下に書き込み位置が来たところで磁気を使って書き込み」• 物理的に近いものをまとめて読み書き →コマンドをいったん待ち行列に入れ（キューイング）、都合の良い順序に入れ替え

複雑になる要因コマンドキューイングhttp://ascii.jp/elem/000/000/346/346448/index-2.html より引用

複雑になる要因 RAIDコントローラ• ハードディスクが遅いなら並べれば早くなる• データを細切りにして複数のハードディスクに分散して読み書き• RAIDコントローラ内のキャッシュに保存したら、もう書き込み終わったことにしてしまう（ライトバックキャッシュ） – 停電したら書いたはずのデータが実は未保存 → RAIDコントローラに電池を搭載（BBWC）電源復帰したら書き込み（バッテリーなしでは危険！）

複雑になる要因 SSD• フラッシュメモリを使った記録メディア – 物理的な可動部分がないので反応が早い。 – 同じ場所を何度も書き込みすると寿命が来る。 – インターフェースはSATA,SAS等• ウェアレベリング – 仮想メモリのように、実際の記録先を入れ替える。 – 寿命が来たブロックを切り離し、代替ブロックと差し替える。 – どちらも、SATAコントローラ側からは関知しない

複雑になる要因 FusionIO ioDrive等の出現• 性能特性が全く異なる（ディスクとメモリの中間） – 量が多く全体を舐める集計処理 – 運用コスト削減（台数削減） – 開発の省力化（チューニング等） http://monoist.atmarkit.co.jp/feledev/news/2011/01/13ted.html より引用

複雑になる要因階層型ストレージ• アクセス頻度に応じて、物理メディアを変更 – アクセス頻度が低い：回転数の低いSATAディスク – アクセス頻度が普通：SASディスク – アクセス頻度が高い：SSDやFusionIO – アクセス頻度が極めて高い：キャッシュを併用

MySQLからハードディスクまで MySQL アプリ SQL処理ストレージエンジンクエリキャッシュバッファ本体 MySQL システムコールストレージカーネル VFS・キャッシュ EXT3 エンジンファイルシステムデバイスドライバ SATAハードディスク

MySQLサーバの内部構造クライアント管理 SQLのパースや、クエリの最適化、クエリキャッシュ等ファイルシステムにデータを保存するストレージエンジン Linuxカーネルのファイルシステム

MySQLサーバの内部構造クライアント管理 MySQLストレージ SQLのパースや、エンジンクエリの最適化、クエリキャッシュ等ファイルシステムにデータを保存するストレージエンジン Linuxカーネルのファイルシステム

ストレージエンジンの仕事• 表形式のデータを保存する。 – 複数のカラム（数値、文字列等）が集まった行 – 複数の行が集まった表 – 複数の表が集まったデータベース• 表から、検索条件に見合う行（に含まれるカラム）を検索・取得する。

ストレージエンジンの仕事• 表形式のデータを保存する。 – 複数のカラム（数値、文字列等）が集まった行 – 複数の行が集まった表 – 複数の表が集まったデータベース• 表から、検索条件に見合う行（に含まれるカラム）を検索・取得する。• 検索しやすい形式でデータを記録する。

検索の仕方1. 順次走査検索（grep型） – データの内容を一件ずつ検索条件と比較する。 – 挿入のコストはO(1)、検索のコストはO(n)2. インデックス検索 – あらかじめ、検索用の小さな索引（インデックス）を作成しておき、高速に検索する。 – インデックスの作成方法がたくさんある – MySQLであれば原則B木(B-tree) 挿入・検索のコストはO(log n)

データ本体の格納場所• クラスタードインデックス(InnoDB等) – プライマリキーのB木の末端に、直接その行のデータ本体を記録する。 – プライマリキーからの検索であれば、B木を一回たどるだけで取得可能 – プライマリキー以外での検索は、セカンダリーインデックスの末端にプライマリキーを格納し、2回 B木をたどる。

インデックスが高速な理由1. そもそも検索コストが低い – O(n)に対して、O(log n)しか計算量が増えない。 – データ量が、1MB→10MBに増えたときに検索時間が0.01秒から0.1秒に10倍に増えたと仮定。 – 10MB→100MBに増えた場合：逐次検索：さらに10倍に増えて、1秒インデックス検索：2倍しか増えず、0.2秒

インデックスが高速な理由2. アクセスするデータ量が少ない – OSのページキャッシュに残る可能性が上がる – 1GBのデータ本体、100MBのインデックス逐次検索：毎回、平均500MBを読み取りインデックス検索：毎回、平均50MBを読み取り（実際はB木の辿った部分のみでさらに少ない） – インデックスがページキャッシュからあふれると、一気に性能が务化

インデックスの更新• インデックスが更新されるケース – データの追加・削除 – インデックスを張っているデータの変更• 何が起きるか – B木が深くなり、効率が下がる – インデックスを詰めるのは大変 →削除マークをつけて無視する – インデックスのサイズが増える→メモリから溢れる• 不必要なインデックスは作らないことも重要

MySQLサーバの内部構造クライアント管理 SQLのパースや、クエリの最適化、クエリキャッシュ等ファイルシステムにデータを保存する MySQL ストレージエンジンパース等 Linuxカーネルのファイルシステム

SQLのパース処理• SQLのパースは案外重い – 上半分をまるまる差し替える DeNA Handlersocket plugin• クエリキャッシュをうまく使う – プリペアドステートメントはキャッシュ効かないorz この辺は個別ノウハウのかたまりなので今回は割愛

http://paper.li	451
http://d.hatena.ne.jp	412
http://snip-snap.posterous.com	246
http://snip-snap.posterous.com	246
http://a0.twimg.com	51
http://strawberryj.am	28
http://nuevospowerpoints.blogspot.com	19
http://nuevospowerpoints.blogspot.com	19
http://us-w1.rockmelt.com	15
http://snipsnaptmae.wordpress.com	13
http://tweetedtimes.com	13
http://tweetedtimes.com	13
http://s.deeeki.com	11
http://twitter.com	7
http://twitter.com	7
http://mundo-powerpoints.blogspot.com	2
http://slide.yoshiday.net	2
http://webcache.googleusercontent.com	2
http://picturetube.deldig.com	2
http://tube.deldig.com	1
http://b.hatena.ne.jp	1
http://www.moriwaki.net	1
http://tube.deldig.com	1

社内サーバインフラ勉強会(DB)

by Masahiro Nakayama

Accessibility

Categories

Upload Details

Usage Rights

23 Embeds 1,563

Statistics