Viva Developer!

マイケル・ヒチワが語る　
「NoSQLに足りないもの」はなにか？

11月9日から2日間にわたって実施された日本オラクルの今年最大の技術トレーニングイベント「Oracle DBA & Developer Days 2010」では、オラクル・コーポレーション ソフトウェア開発部門 バイスプレジデントである マイケル・ヒチワ氏が「データベースのチカラをアプリケーション開発に最大限活用するために」と題して講演を行った。この講演の内容をさらに深く掘り下げ るべく、同氏にインタビューを行った。（編集部）
《マイケル・ヒチワ》シリーズをお見逃しなく！
■オラクルが考える「NoSQLに足りないもの」とは

tc_101107-01_01.jpg
　今回の講演の冒頭では、とりわけOracle Databaseに備わる「SQL」と「PL/SQL」に関する能力が紹介された。数々の最新機能がある中で、これらの基本機能を改めて取り上げた理由 を、ヒチワは次のように説明する。「ご存じの通り最近では、SQLを使わずにデータベースアプリケーションを構築する『NoSQL（Not Only SQL）』のムーブメントも広がっています。そうした今、SQLの持つ能力にいま一度光をあてるべきだと思いました」。

　「NoSQLの問題は、SQLとは異なり、すべてが物理的な実装と密に結びついてしまっている点です。NoSQLデータベースの多くは、デー タに対して物理的な配置に依存したアクセス手段しか利用できず、柔軟性に欠けています。もちろん、NoSQLデータベースが適している用途も存在します が、すべての用途に最適とは言えません」。

　「一方、SQLではデータの論理的な側面と物理的な側面が明確に分離されています。私は1996年から14年間に渡ってOracle Databaseの開発に携わっていますが、当時Oracle 4向けに記述したSQLが現在でもそのままOracle Database 11g上でも動作します。SQLは一行も変更していません。しかし現在は、パーティション機能やデータ圧縮、コストベース最適化、マルチバージョニングに よる一貫性確保、データベーストリガーなど多彩な機能を、その同じSQLに対して適用できます」。

　「例えば、私が最初のOracleデータベースアプリケーションの開発を始めた当時は、DECのVAX/VMSプラットフォームが世の中を席 巻していました。しかしその後UNIXが主役の座を奪い、さらにはLinuxへと変遷を続けます。その間、SQLはほとんど変化せずに使われ続けました が、プラットフォームに依存したデータストアが生き残ることはありませんでした。今やSQLとRDBの技術は、マイクロソフトやSAP、IBM、そしてオ ラクルを含め、業界全体がサポートする標準技術として位置づけられています」。

■いま考えるPL/SQLの意義
　また最近では、PL/SQLをはじめとするストアドプロシージャ機能が脚光を浴びる機会が少なくなっている。しかしヒチワは「PL/SQLに よるストアドプロシージャは、アプリケーションに固有のAPIをデータベース上に構築する手段として、いまだ大多数のオラクルユーザーによって利用されて います。データベーストリガーも、生産性の向上に重要な役割を果たしています」と述べる。

　「一般にデータベースアプリケーションでは、アプリケーションサーバーとデータベース間の通信をできるだけ減らすことが重要です。ストアドプ ロシージャを利用することで、必要最低限のパラメータだけをデータベースに渡せば、あとのロジックはデータベース上で高速に実行されます。これにより、 『データベースのロジックはデータベース上で記述する』、『アプリケーションのロジックはアプリケーションサーバー上で記述する』という役割分担が可能に なり、両者間のトラフィックを劇的に減らすことができます」。

　「例えば、すべての社員データを取得して、個々の社員についてどの程度の昇給を実施すべきか判断するロジックを実行するケースを考えます。こ のロジックをアプリケーションサーバー側に記述するとデータベースとの間にたくさんのトラフィックが生じます。一方、同じロジックをデータベース上のスト アドプロシージャで実装することで、たった1回の関数呼び出しをデータベースに対して実施するだけで、同じ処理を格段に高速に実行できます」。

■データブロックではなく検索結果をキャッシュする「Result Set Cache」のメカニズム
tc_101107-01_02.jpg
　Oracle Database 11g R2の数ある新機能の中で、とりわけ開発者にとって目を引くのが各種のキャッシュ技術である。そのひとつ「Result Set Cache」のメカニズムについて、ヒチワは次のように解説する。

　「Result Set Cacheは次のような仕組みで動きます。Oracle Database上でSQLによる検索を実行すると、関連する各テーブルを構成するデータブロックをディスクドライブから読み取り、メモリ上の SGA（バッファキャッシュ）へ格納します。そのデータブロックから、検索結果をメモリ上で集めていきます。ここで、他のユーザーが全く同じ検索を実行し たとします。データブロック自体はSGA上に残っているのでディスクドライブから読み取る時間は発生しませんが、検索結果を集約する処理自体は繰り返す必 要があります。例えばGROUP BY節で集計処理をする場合は、何千ものデータブロックをメモリ上で処理して集計結果をまとめる必要があります」。

　「Result Set Cacheでは、データブロックではなく検索結果そのものをメモリ上にキャッシュ保存します。これにより、一度実行した検索を繰り返し処理する必要がなく なり、劇的な速度の向上が実現できます。これは口で言うのは簡単ですが、実際に実装するのは容易ではありません。例えば、キャッシュ上にデータが残ってい ても、そのデータが他のユーザーによって更新されているともはや役に立ちません。キャッシュ上のデータが古くなっていないか判断するには、対象となるテー ブルへのアクセスを監視し、データが更新されたらキャッシュ内容を破棄して検索処理を再実行します。またPL/SQLの関数についても、Result Set Cacheと同様に、処理結果のキャッシュ機能を実装しました。関数呼び出しの結果をキャッシュ保存することで、同じ結果が得られる関数呼び出しを何度も 繰り返すムダを解消できます」。

　こうした数々の技術の進化によって、アプリケーション開発者とデータベース管理者それぞれの負担を下げていくのがオラクルのビジョンであるという。

　「例えば多くのデータベース管理者は、個々のテーブルをユーザーがどのように利用するかといった、アプリケーションの詳細について理解してい ません。そのため、データベース管理者は開発者に対して『このアプリケーションが遅いから直して』と依頼することがしばしばあります。一方で開発者は、ア プリケーションレベルの知識に基づいてSQLにヒントを書き加えるなどの対策を講じます。しかしOracle Databaseでは、コストベース最適化やResult Set Cacheのような自動的な最適化技術の進化を推進しており、今後は上述のような最適化の作業の大半が自動化されていくはずです」。

前の記事 <<　　最初の記事へ　　>> 次の記事