Windows Azure TableをRDBMSと比較する

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」について解説します。