データベースを速くする「フラッシュストレージ」の種類：Database Expert基礎用語解説（1）（1/2 ページ）

データベースアプリケーションを速くする際に、SQLチューニングの次に考えておきたいのがハードウエアによるパフォーマンス向上です。本稿ではストレージ領域を中心に用語を簡単に整理しておきます。

[＠IT]

はじめに

　データベースアプリケーションの処理能力を高めるためには、いくつかの方法があります。代表的なものは、データベースクエリの中に潜む、無駄な処理を効率化するために行う「SQLチューニング」です。データベースアプリケーションがどのようにデータを取り出すか、書き込むかを考慮して、より処理が速くなるようにクエリを書き直す方法です。例えばfor文で1行ごとに読み込み／書き出しを繰り返す処理は、一度に読み出して処理をした方が効率が良くなります。また、データベースソフトウエア側のパラメーターを、サーバーの構成――例えばメモリサイズなどに即して変更する、といった方法もあります。

　一方で、リレーショナルデータベースソフトウエアが誕生した時代と比較して、現在ではハードウエア性能が飛躍的に向上したことから、ソフトウエア以外の部分で処理性能を高める方法も主流となり始めています。その代表的なものがフラッシュストレージによるI/O性能の向上です。従来のデータベースチューニングではストレージI/Oのボトルネックを考慮するために、メインメモリやCPUの性能に頼った処理を行うことも少なくありませんでしたが、ストレージI/Oボトルネックを解消するハードウエアが普及してきたことで、従来の常識が変わりつつあります。例えば、既存のSATA接続などのハードディスク ドライブ（HDD）をフラッシュストレージに置き換えるだけでも一定の性能向上が期待できます。

　では、HDDを置き換えただけでも効果が期待できるフラッシュストレージに対して、各企業はどのような差別化を図っているのでしょうか？　一言で「フラッシュストレージ」といっても、その構成や仕組みにはさまざまな“違い”があるのです。

　本稿では、データベース管理者（DBA）を目指す方、インフラ技術を学ぼうと考えている方々に向けて、主にストレージ領域のキーワードとなる情報をざっと整理していきます。DBAの皆さんならば、「当たり前」に理解しておきたい知識です。

まず考えるべき、「何を高速化すべきか」

　ハードウエアを活用したデータベースの高速化ついて論じる前に、データベースアプリケーションのワークロードの違いによって、どの部分を高速にするべきかの判断が分かれますので、その点を整理しておきましょう。

トランザクション処理の高速化

　一つは、細かなトランザクションが頻繁に発生するために、データの読み込み（Read）／書き込み（Write）の際の待ち時間が問題となるケースです。データベースソフトウエア側で行ロックが発生しないようにする仕組みを持つものもありますが、それでも応答速度が不十分なケースです。現在、こうした問題が発生する原因として指摘されているのはストレージI/O待ちによる遅延です。このストレージI/O時間を短縮する目的で、フラッシュストレージを「キャッシュ」ないしデータベース全体の格納に利用すると、それだけでシステムの処理能力が高まることがあります。

　キャッシュとしてフラッシュストレージを持つ場合でも、要件によって適用方法は異なります。データの更新頻度が低く、データの読み込み速度を高めたい場合はReadキャッシュのみでも良いでしょう。ただし、Readキャッシュが使えなかった場合の読み込み先がHDDなどの遅いストレージであった場合には、応答速度に遅れが発生する可能性が考えられますので、「どのようなシーンで、どのような場合にキャッシュするか」を事前によく設計しておく必要があります。

　書き込みの性能も高めたい場合は、Writeキャッシュによって書き込みリクエストをある程度キャッシュしておく仕組みを検討できるかもしれません。Writeの場合はデータの更新を伴うことから、書き込み終了後にデータの整合性が正しく保てているかを検証する必要があります。この場合は高速な応答だけでなく、ログデータなどを含め、どこまでのデータ整合性を維持するかを判断する必要があります。

データロードの高速化

　もう一つは、データベース全体に対して処理が発生するような、大きなバッチ処理プログラムを実行する際に時間がかかるというケースです。こうした問題を解決するには、データベースファイルをフラッシュストレージ上に置き、かつ通信帯域を広くする方法による対策が考えられます。フラッシュストレージで構成されたNAS（Network Attached Storage）などにデータベースを格納し、データI/Oをまんべんなく高速化しつつ、帯域幅も確保することで処理の高速化を期待できます。

　また、カラムストア型データベースが注目されてから、データベース全体を大容量メモリにロードしておく「インメモリデータベース」という考え方も広まりつつあります。この場合、メモリにデータベースをロードする時間がかかることもありますが、例えばインデックスデータを事前に生成しておく、あるいは、インメモリで行われることの多いカラム（列）データ処理などではカラムインデックスをメモリ上に配置しておくといった方法を採用しているものもあります。

　本稿では、データベースアプリケーションを高速化する際に語られることの多いストレージ領域を中心に解説しますが、データベースアプリケーション全体の高速化には、この他にも、CPU性能、ネットワーク帯域幅、ストレージI/Oやメモリ容量などを総合的にバランス良く高めていく必要があります。

　次ページからは、前述のワークロードの違いを踏まえた上で、より詳細に各要素を見ていきましょう。