データベース高速化のための性能改善

データベース高速化へのアプローチ

　「データベースの高速化」というキーワードを聞いた時、皆さんはどのような解決策を思いつくでしょうか。ハードウエアやソフトウエアによるさまざまな解決策を思い浮かべられるかと思いますし、高速化という言葉自体の受け取り方もさまざまかと思います。

　本連載では、高速化についてのアプローチを大きく2つに分けて考えていきます。

　まず1つ目は、既存のOLTPやバッチ処理で動いているデータベースサーバーの性能が劣化してきたために行われる、「性能改善＝高速化」のケースです。

　ここでの対処方法としては、まずチューニングやHW増強など従来までの解決策が挙げられます。そのほか、最近のトレンドとしてSSDやネットワークの高速化も登場しつつありますので、それらを第1回目で紹介していきます。

　2つ目は、1つ目のケースでは対応できないような圧倒的な性能要件を持つケースです。

　1つ目の対応策だけでは解決できない性能要件に対しては、従来は開発による作りこみによって対応してきたケースもあるでしょう。しかし、最近は高速化を売りにした製品が続々と登場しており、それらが採用されるケースも徐々に増えてきました。第2回目以降ではこうした高速化製品を取り上げて紹介してきます。

　本題に入る前に、性能改善について大事なポイントをお伝えしておきます。

　性能改善や高速化に一番重要なことは、ボトルネックをきちんと把握することです。このステップを無視してやみくもにCPUやメモリを増強しても、期待通りの効果が得られるとは限りません。

　そして、次に重要なことは明確な数値目標を持つことです。システム全体としてのパフォーマンスが遅くなってきたからなんとなく改善したい、そのような話を聞くことがあります。

　しかし、あいまいな目標設定では解決策にきりがありません。かけられるコストやリソースは限られていますので、明確なゴールを持つことは大事な要素となります。性能改善の目的は何か、本当に高速化が必要なのか、その辺りの整理は事前に行っておく必要があります。

　どちらも説明すると当たり前のことなのですが、意外と考慮されていないケースもありますので、この2点はよく意識するようにしてください。

従来の性能改善手法

　それでは、まず1つ目のケースから考えていきましょう。

　まずはボトルネックの洗い出しです。ボトルネックは必ずしもデータベースサーバーが原因とは限らず、APサーバー側が原因となることもありますが、ここではデータベースサーバー側でボトルネックとなる事象について洗い出してみます。一般的に考えられるボトルネックをまとめたのが図1です。

　最も重要なのは1番上のチューニングによる解決策です。他がボトルネックに見えても、実は根本原因がチューニング不足となるケースは多くあります。

　極端な例ですが、適切な索引が付与されていなければテーブルフルスキャンが行われ、結果としてディスクアクセスがボトルネックと見えます。このようなケースでディスクI／O削減のためのSSD導入や、キャッシュヒット率を上げるためのメモリ増設はそれほど効果が見込めません。

　問題となるSQLが見つかるのであれば、適切な索引が付与されているか、SQLチューニングによる改善が見込めないかなどをまずは検討するべきです。

　続いてCPUやメモリの増設です。

　CPUは年々マルチコア化が進み、最近では1ソケットで6coreや8coreといったものまで出てきています。クロック数も数年前に比べれば2倍近い製品も登場しています。CPUリソースがボトルネックとなる場合は、最新機種にリプレースするだけで劇的な性能改善が見込めるかもしれません。

　メモリは年々価格の低下が進んでいますし、ミドルクラスのサーバーでも最大メモリ搭載量が増えてきています。そのため、64GBや128GBのメモリを搭載し、データベースのキャッシュ領域に数十GB以上割り当てると言った話も聞くようになりました。キャッシュヒット率の低下が見られる場合は、思い切った大容量メモリを検討するのも効果的でしょう。

　次のディスクについては、最近のトレンドとして一般的に聞くようになってきた、SSDを紹介します。