PR

Windows Azure TableをRDBMSと比較する

2009年9月8日(火)
田中 主夫

1,000行を越える検索結果にどう対応するか

 Windows Azure Tableにおける検索結果の最大数は1,000行で、これ以上の行数に対応するためにはheadersに継続トークンを設定する必要があります。

 テーブルIISLog2には1,000行以上のデータが格納されていますので、条件指定せずに単純にテーブルの全件検索を行うと、前ページで記述した今回のプログラムでは以下のようなエラーとなります。
---------------------------------------------------
C:\PHPAzure-0.2.0[1]\library>c:\php\php.exe t03.php
・・・
Fatal error: Uncaught exception 'Microsoft_Azure_Exception' with message 'Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:bcd3bb80-e3c3-4014-9ff6-e695df8b9e13
・・・
---------------------------------------------------

 試しにAzure Storage Explorer v2.1で、このIISLogs2テーブルをクリックすると数分間待ち状態となり、結果として表示される件数は100行までです。

 行数以外にもWindows Azure Tableの検索結果にはいくつかの制限があります。資料「Windows Azure テーブル - テーブル ストレージのプログラミング」[※3]の継続トークンの項で説明されています。

□継続トークン
クエリで返されるエンティティの数は、次の理由のいずれかによって制限される場合があります。

・返されるエンティティの最大数が要求で指定されている。

・エンティティの数が、サーバーによる応答に含めることができるエンティティの最大数(現在は1000)を超えている。

・応答に含まれるエンティティの合計サイズが応答の最大サイズ(現在は4MB。この4MBには、プロパティ名は含まれるが、RESTで使用されるxmlタグは含まれない)を超えている。

・クエリの実行時間が、サーバーで定義されているタイムアウトの時間30秒を超えた。
 クライアントは継続トークンがなくなるまでこれを繰り返します。継続トークンがなくなった時点で、一致する結果はすべて取得されたということになります。

 Windows Azureではタイムアウト時間が60秒から30秒に変更されたようです[※2]。ここからもわかるようにWindows Azure Tableでは、最後までページ送りしてみないと該当テーブルのデータの合計件数はわかりません。

 1,000行以上のデータの対応にはPagination(改ページ)機能の利用が必要で、対応するためにはREST APIを利用します(PHP Azure verion0.2.0ではサンプルコードにPagination機能を行ったものは添付されていません)。

 REST APIについては英文ですが、ブログ「Demystifying The Code(http://blogs.msdn.com/bags/archive/2009/07/10/working-with-azure-table-storage-from-php.aspx)」にYouTubeの動画付きで説明されています。Windows Azure TableのPaginationを行うPHPのサンプルプログラムもダウンロードが可能です。

 図3は、動画の中でプログラムを説明している部分の画面ショットですが、認証情報やテーブル名、PartitionKey($nextPartition)、RowKey($nextRow)をheader経由で受け渡しする様子が見てとれます[※2]。1,000行以下のテーブルであれば特に必要ありませんが、それ以上の行数からなるテーブルでは複数パーティション作成の際、作成したパーティション名は自分で管理しておく必要があります。

 また、Fiddlerという通信内容を監視するツールでheadersの中身を確認しながらREST APIについて説明したページも別途作成されており、こうしたページを見ると当初マイクロソフト社がSQL ServerがベースのAzure SQLもデータ操作はREST APIにした背景が感じられるような気がします。

 1,000行というエンティティの最大数の外にも、30秒、4MBなど数字が「継続トークン」の項で挙げられていますが、Windows Azure Tableに限らず、クラウド環境では1トランザクションで処理可能なデータボリュームはいろいろな制限が設けられています。これらが低コストでスケールさせる秘訣(ひけつ)のようです。

※2「Query Timeout and Pagination」(http://msdn.microsoft.com/en-us/library/dd135718.aspx)(アクセス:2009/09)

※3「Windows Azure テーブル - テーブル ストレージのプログラミング(PDF)」(http://download.microsoft.com/download/E/C/6/EC6779BB-C153-4590-B7D8-44FE6A879DC8/Windows%20Azure%20Table%20-%20Dec%202008.pdf)(アクセス:2009/09)

キー項目の抜粋とその留意点

 そのほか、前述した資料[※3]から、いくつかのキー項目を抜粋し留意点をメモしておきます。

・Windows Azureテーブル
 サービスの状態を保持するための構造化ストレージ。
構造化ストレージ:システムは、トラフィックの増加に応じて自動的に何千台ものサーバーへとスケール。構造化ストレージはテーブルの形で提供されます。
【留意点】テーブルの形だがリレーショナルではないので複数のテーブルを結合するようなことはできない。

・エンティティ(行)
 “行”と似ています。必須のシステムプロパティ(PartitionKey、RowKey、およびTimestamp)を含む最大255個のプロパティを持つ。同じパーティション内のエンティティは1か所に格納されます。これにより、パーティション内での効率的な照会が可能。
【留意点】複数のPartitionにまたがる検索は避けた方がよい。

・並べ替え順序
 CTPでは1つのインデックスが提供されており、テーブル内のすべてのエンティティは、まずPartitionKeyに基づいて並べ替えられ、次に、同じPartitionKeyを持つエンティティがRowKeyに基づいて並べ替えられます。
【留意点】検索結果は必ずOrder by PartitionKey、RowKeyとなる。

 以上、RDBMSと比較しながらWindows Azure Tableを見てきましたが、SQLなど必要ないという人にはスケーラビリティーに優れたストレージ・システムであっても、SQLに慣れてしまっている人にはWindows Azure Tableはまだ扱いが面倒なテーブルであるように感じます。

 データ量が膨大となるシステムには低コストでスケーラビリティーを備えたWindows Azure Tableが間違いなく適しているのですが、クラウド環境のストレージへのデータのローディングには時間がかかるため、既存システムから短期間でデータ移行が必要な場合はこの点が課題となります。

 次回はSQLが利用できる「SQL Azure」について解説します。

ERPの導入支援に携わりOracle, SQL Server, DB2などのRDBMSを扱う。クラウドの出現により、これで速度劣化のトラブルから開放されるかと思いきや、ストレージ面ではRDBMSの便利さにあらためて感心する面も。インストールマニアックス2008では苦労の甲斐(http://iis.museum-in-cloud.com)あって勝利。褒美のマイクロソフト本社訪問でWindows AzureのSQL機能を知る。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています