データが増えるとRDBMSが遅くなるわけ

データが増えるとRDBMSが遅くなるわけ

～はじめから動かないものは、途中から遅くなることはない～

　今回あらためて感心したのは、RDBMSのテーブルでは検索結果を指定した、任意の列のソート順で表示することができるということです。指定列にインデックスが作成されていない場合、データ量の増加に伴って遅くなることが当然考えられるため、インデックスの追加が必要です。

　このようなケースであれば、単にインデックスを新たに追加作成すればいいのですが、RDBMSにはいくつものテーブルを結合する必要もあるため「実行計画」（図2-1参照）を作成する機能がありますが、運が悪いと追加したインデックスの影響でこの「実行計画」が変更され、別の検索が遅くなることもあります。

　さらにこの実行計画の策定には統計情報が絡むなど、話が複雑になっていきます。そして、さらにけた違いに行数が多いテーブルでは構造的にRDBMSでの対応が難しくなります。

　一方、大量データに強いWindows Azure TableではCTP（Community Technology Preview）なこともあり、インデックスは1組だけで、一度テーブルに格納したデータの検索結果の並び順を変えようとすると最初から登録し直しとなります。

　CTP段階を経た後、Windows Azure Tableにも追加でインデックスが作成できるようになるかも知れません。

　しかし、こうして追加したインデックスは時に再作成が必要となります。応答に制限がある環境下でのバッチ処理がどのような仕組みで実行されるのか興味深いところです。また、作成できるインデックスの数が増えれば使い方も複雑になります。［※3］

Key-Value型とRDBMS型の連携

～RDBMSは内部でデータ処理を行うこともできる～

　正規化（テーブルを小分けに）すれば結合が必要となり、結合した表データの一覧は遅くなるのは当然のことですが、RDBMSが使われ始めたころは正規化できるところを正規化しないのは悪いことであるとした風潮も一部あったようです。

　それはおかしいのではと言っていた筆者も、何年か後にRDBMSを利用したCRMパッケージで「データを非正規化するためのバッチ処理機能」を見た時ににはうならされました。

　まさに、この非正規化処理のパターンは、Windows Azure環境ではSQL Azure DatabaseからスケールするKey-Value型のWindows Azure Tableへのデータ展開に相当します。

　RDBMSはステーラビリティに難がありますが、多くの場合、システムの中で本当にスケールさせる必要があるテーブルは限られていますので、こうした連携は実践的です。非正規化したデータにとどまらず帳票出力データ、時系列データなど、なにも高価なテーブルに格納しておく必要はありません。

　また、テーブル内のデータ行数が1,000行に満たないものばかりなのに、工数をかけてKey-Value型のストレージを利用するのも考えものです。

　Windows Azure以外ではForce.com for Google App Engine［※4］により、Force.com（RDBMS型）とGoogle App Engine（Key-Value型）の連携をJavaやPythonを使用して行うことができます。

　Windows AzureはRuby［※5］にも対応していく予定のようですが、Ruby on Railsなどのフレームワークにより、既にRDBMSの違いは隠ぺいされています。

　さらにこのことが本格的にクラウドのストレージシステムに対応していけば、RDBMSと合わせたKey-Value型のストレージの活用も容易になることでしょう。

　PHP用のフレームワークも複数出てきており、フレームワークとそれを支持するオープンソース・コミュニティーとクラウドの関係が、今後の動向を左右するひとつのキーとなりそうです。

　また、2009年9月現在オープンソースの流れはERPソフトまで到達しており、この分野のランク1位にあるOpenbravo ERP［※6］のMRPなどの処理プログラムは、Stored Procedureで記述されOracle、PostgreSQLの2つのデータベースをサポートしています（図2-2参照）。

　データの処理はデータベース内（Stored Procedure）で行うことがオーバーヘッドも少なく理想的ですが、これは同時に特定のデータベースへの依存性を高めるという欠点もあります。

　データベース内部まではフレームワークの隠ぺい化も及ばないとしても、フレームワークにより同時に複数のデータベースを利用し、連携することはできます。

［※3］Google App Engineインデックス作成の仕組み（http://code.google.com/intl/ja/appengine/articles/index_building.html）（アクセス：2009.09）
Google App Engineクエリとインデックス（http://code.google.com/intl/ja/appengine/docs/python/datastore/queriesandindexes.html）（アクセス：2009.09）

［※4］Force.com for Google App Engine（http://developer.force.com/appengine）（アクセス：2009.09）
Force.com for Google App Engine動作テスト例（http://iis.museum-in-cloud.com/joomla/index.php?option=com_content&view=article&id=92:cloud-cloud&catid=18:connect&Itemid=114）（アクセス：2009.09）

［※5］強まるRuby標準化を求める声～RubyWorld Conference2009（http://enterprise.watch.impress.co.jp/docs/news/20090909_314346.html）（アクセス：2009.09）

［※6］SourceForge のERPカテゴリーのランキング（http://sourceforge.net/softwaremap/trove_list.php?form_cat=577）（アクセス：2009.09）