Oracle Databaseのスマートな開発/運用の鉄則
第3回 「本当に効くデータベースチューニング ~索引よりもCPUとHDDのバランスを~」
データウェアハウスのような大規模データベースでは、高性能化するハードウェアの性能をいかに活かしきるかが、重要な課題となってきている。高性能なハードウェアの性能をOracle Databaseの機能でフルに使い切っている好例が「Oracle Exadata」だ。今回は、Oracle Exadataの技術検証を担当するエンジニアが、Oracle Databaseのパフォーマンスアップ機能を紹介する(編集部)。
日本オラクル
テクノロジー製品事業統括本部
データベースソリューション本部
Exadata技術部プリンシパルエンジニア
柴田竜典
「サーバーは高性能化している。しかし、CPUのマルチコア化、HDDの大容量化が、アンバランスなデータベース・システムを増やしている。それが、データベースのパフォーマンスを悪くする要因となっている」と柴田氏は説明する。どういうことだろうか。
ストレージの高性能化が進んでいるとはいえ、CPUの性能向上に比して速度は向上していない。しかも大容量化、低コスト化が進んでいるため、ストレージは少ないディスク本数で構成される傾向にある。CPUのマルチコア化で複数スレッドを高速に処理できるようになったが、その相手となるストレージのディスク本数が少ない。データベース・システムにおいて、CPUが遊んでしまい、せっかくの高性能が生かされていないというのだ。「この傾向は、国内だけではない。例えば米国でも同じ。ITのトレンドとしてそうなっている」と柴田氏は言う。
パフォーマンスのボトルネックはCPUにあるのではない。CPUを使い切れていないことに実は問題がある。
解決策としてはOracle Databaseの「ASM」(Automatic Storage Management)を使って、ストレージのパフォーマンスを上げてCPUの性能とのバランスを取る方法がある。
さらには、「パラレル処理を使うことで、マルチコアを生かすことができる」(柴田氏)。
■複数のディスクを抽象化しスループットを上げる「ASM」
「データウェアハウスのような大規模データベースでは、RACで複数のOracleインスタンスを一つにまとめるとともに、ストレージにおいても複数ディスクをディスク・グループとしてまとめて管理し、スループットを向上させたい」(柴田氏)。
データベースを構成するファイルの管理をユーザー自らが行うのではなく、Oracle Databaseに任せることで可用性とパフォーマンスを向上させる機能がASMだ。これはOracle Database 10gから提供されている機能だ。
ASMによって、ディスクI/Oのスループットを向上させることができるので、CPUの利用効率も上げることができる。さらにASMは、ディスク管理の高い柔軟性を提供する。運用するうちに、データ量の増加によってディスクを追加したり、故障等によって交換したいケースが出てくる。「ASMを使うと、ディスクを追加すると動的に再配置が行われる。ディスクが故障すればリバランスする。ストレージ移行の場合でもリバランスが活用できる。非常に使い勝手がよく、性能の向上と柔軟な運用が両立できる。しかも、ASMはOracle Databaseを使っていれば無償で利用できる機能だ」(柴田氏)。
例えばOracle Exadataでは、RAC構成とASM管理をフル活用している。「最大で8ノードのRAC構成を持ち、ASM管理で168本のディスクを1つの大きなストレージに見せている」(柴田氏)
オラクルエンジニア通信:「Oracle ASMを1から学ぶ - マニュアル、インストール・構築、設定・管理」
■パラレル処理でコア数を活かす!
CPUのコア数を生かすには、1つのSQL文を複数のプロセスで同時に処理することができるパラレル処理を活用したい。パラレル処理も、Oracle Exadataで頻繁に利用さている。「パラレル処理によって100近いコアをバランスよく使っているよい例だ」(柴田氏)。
パラレルと言うと、同時に複数のSQLが実行された際にそれぞれの並列度をどの程度減らすかを手動で調整する必要があるという課題があった。
「しかしOracle Database 11g R2からは、データベース側で最適な並列度に調整してくれるので、同時実行を気にせず、自動設定された並列度でそのまま運用できるようになった」(柴田氏)。
全てのクエリーに対して単一の並列度が最適とは限らない。この点がパラレルを難しくている要因だった。しかし11gR2以降では並列度をOracle自身が設定するため、パラレルを活用しやすくなっている。
ところで、パラレル・クエリーは、RAC環境で使うことでさらに効果を発揮する。1つのSQLを1台のノードで並列化するのが通常のパラレル・クエリーだが、RAC環境において、1つのSQLを複数のノードにまたがって並列化するのが、インターノード・パラレル・クエリーだ。
インターノード・パラレル・クエリーでは、常に複数インスタンで実行されるわけではない。インターコネクト上のトラフィックを最小限にするため、クエリー・スレーブ数が単一のインスタンス上では不足する場合、自動的に複数ノードのインスタンスを利用し、実行される。
ノード追加に伴いリニアに性能を向上させることができるのがインターノード・パラレル・クエリーだ。
「クエリーに限らず、InsertやUpdateでもパラレル処理が使えるのがOracle Databaseのメリットだ。実行計画取得、Data Pumpを利用したデータのインポート/エキスポート。外部表を利用したデータのローディング。これらも全部パラレルでできる。データウェアハウスでは、ぜひ積極的に使ってほしい」(柴田氏)。
オラクルエンジニア通信:「【セミナー資料】ここまでできる!! Oracle Databaseのパラレル処理」
■大量データの処理にはパーティションも有効
パーティションは、表や索引を内部的に分割する機能だ。分割しても1つの表として扱われるが、SQLなどが扱うデータ量を削減することができる。
「パーティション大規模データベースを扱う際にはマストとなる機能だ。データウェアハウスでの多くの場合、索引は役に立たないと言い切ってよいだろう」(柴田氏)。
例えばデータベース全体の1%未満がヒットする場合は索引が有効だが、データウェアハウスにあるような、過去1年間の売上データから1カ月分の売上合計を見るといったケースでは、索引ではデータベースの性能向上は望めない。このような場合では、売上年や月ごとにデータベースをパーティション化すれば、特定年月のデータを参照するだけでよくなるため、集計作業などの処理における性能向上が期待できるのだ。
さらに、「索引スキャンは、1ブロックずつ読むので、どうしてもストレージの性能を出しづらいが、表スキャンは複数ブロックをまとめて読めるのでストレージの性能を最大限引き出せる。"同じブロック数を読むのであれば"、索引スキャンするよりも一部のパーティションだけを表スキャンするほうが速い」(柴田氏)。
表スキャンは常に悪者というイメージがあるが、実はそうでないのだ。パーティションは、取り出す行数が非常に多い場合に大きな効果を発揮し、索引とは違った方法で読み取りブロック数を大幅に削減する機能だ。
パーティションのメリットについて、さらにいくつか触れていこう。通常、表の一部をDelete文で削除すると時間がかかる。しかし、例えば売上データを月単位でパーティション表にしておけば、月単位でパーティションをドロップすることで、すぐにデータを削除できる。さらに、パーティション表はパーティション単位で圧縮することができるため、例えば過去の売上データは圧縮するとよい。古いデータに対してInsertやUpdateを行うことは少ないだろう。圧縮しておけばディスクの節約にもなるし、Selectが速くなるというメリットもある。
Oracle Databaseのパーティションには、レンジ、リスト、ハッシュの3通りの分割方法があるが、それらを組み合わせることもできる。「例えば月単位、支店単位の2つのパーティションを組み合わせることで、月別支店別の売上データに瞬時にアクセスできる。ほかにもレンジ+レンジ、レンジ+ハッシュというように自在に使えるので、ぜひ使いこなしてほしい」と柴田氏は説明する。
オラクルエンジニア通信:「Oracle Partitioning 技術資料」
■大規模データベースのチューニングノウハウはExadataがお手本に
Oracle Exadataは、8台の2ソケット・データベース・サーバーと14台のOracle Exadata Storage Server、InfiniBandスイッチを備え、大規模データベース・システムとして最適なバランスを最初から考えてハードウェアとソフトウェアが構成されている。マシンの性能をフルに発揮するために、特別なチューニングは必要ない。Oracle Exadataのアドバンテージの一つは、世界中に同じ構成の大規模システムがあるということだ。さまざまなケースで培われたノウハウをOracle Exadataのユーザーが共有できることが大きなメリットだ。
そのノウハウの中には、一般のOracle Databaseのユーザーにも参考になる情報が多い。これらのノウハウをまとめた、より詳しいOracle Databaseによる大規模データベース、とくにデータウェアハウスについての技術情報はオラクルエンジニア通信から入手できるので、参考にしてほしい。
オラクルエンジニア通信:「Oracle DWH(データウェアハウス)構築・設計 技術資料」
(第4回に続く)