Windows Azure TableをRDBMSと比較する
Windows Azure Table ストレージの「テーブル」
今回の解説に入る前に一つお知らせがあります。これまで1週間程度かかっていたWindows Azureのトークンの取得ですが、2009年9月3日よりプロダクトコードが即時発行されるようになりました。これで今までより容易にWindows Azureを体験できるようになったのではないかと思います。
前回は、Windows Azureの簡単な紹介と、クラウドOSの要となるストレージを中心に解説しました。第2回となる今回は、Windows Azureの「テーブル」とはどのようなものなのか、リレーショナル・データベース・マネージメント・システム（以降RDBMS）のものと比較しながら見ていくことにします。
ハードウエアの性能向上により、今日ではRDBMSのテーブルに画像ファイルを格納することも多くなりましたが、以前はファイル名はテーブル、本体ファイルは外部、といった具合に分けて保存することが多かったのです。
Windows Azureストレージでは従来こうした使い分けが行われており、画像を格納するBlob、そしてファイル名などを保存するTableという構成になっています。このWindows Azure Table（Key-Valueストア型）は低コストでスケーラビリティーに優れますが、機能や操作性については、やはりSQL ServerがベースのSQL Azure（リレーショナル型）に一日の長があるようです。
スケーラビリティーのための分散処理の仕組みの詳細については、3ページの資料をご参照いただくとして、ここでは実際にWindows Azure Tableにテーブルを作成しデータを格納、その検索を行うことで、このストレージの特徴を把握していくことにします。
Windows Azure Table ストレージにテーブルを作成する
Windows Azure Tableは、Partition KeyとRow Keyの2つのキー項目の組み合わせで一意になるように設計されています。まずは単純に「Partition Keyが番号付きのテーブル名」で「Row Keyがシリアル番号」ととらえて進みます。図1-2をご参照ください。
前回記事（http://thinkit.jp/article/1019/1/）のBlobストレージの操作で利用したAzure Storage Explorerでテーブルを作成します。作成の際に指定するのはテーブル名のみです。テーブルにデータを登録することもできますが、ここで設定できる値はPartition KeyとRow Keyだけです（図1-3参照）。
データ本体となるのはEntitiesの部分ですが、この構造の定義はプログラムファイル内で行います。Azure Table ExplorerではEntitiesの値を登録することはできません。
このあたりは、はじめ筆者もかなり戸惑ったところなのですが、Windows Azure Tableでは固定のスキーマはなく、スキーマ情報はWindows Azure Tableには格納されていません。つまりRDBMSにあるような辞書テーブルはWindows Azure Tableでは存在しません。
従って、RDBMSでテーブルの構造を参照するための「describe テーブル名」のようなコマンドを実装するとしたなら、構造確認のために実際にサンプルとなるデータを取得する必要があります。また同じテーブルであっても、サンプルとして採用したデータによりEntitiesの構成が異なって見えることもある、ということです。
