SQL Azureの使い勝手をSQL Serverと比較する
DDL、DML、プロシージャを実行してみる
SQL Azure ManagerやSSMSによる接続環境が整ったら、実際にSQL AzureにSQLで問い合わせてみましょう。
まずはテーブルを作ります。CREATE TABLEなどのDDL（データ定義言語）系のSQL構文はもちろん、型やPK（プライマリ・キー）、インデックスの指定なども含め、SQL Serverと同じように実行できます。
a）まずは簡単なテーブルを作成します。
CREATE TABLE HoLTestTable
(
MyRowID int PRIMARY KEY CLUSTERED
);
b）レコードを3行追加します。
INSERT INTO HoLTestTable VALUES (1)
GO
INSERT INTO HoLTestTable VALUES (2)
GO
INSERT INTO HoLTestTable VALUES (3)
GO
c）テーブルの状況を確認します。
SELECT * FROM HoLTestTable;
3行追加されていることが確認できます。クラウドにあるDBに対しても、使い慣れたSELECT * FROM文を使用できることが分かります。
続いて、もう少し列数が多いテーブルを作成し、PKとインデックスを作成してみましょう。
d）列数が多いテーブル、PK、インデックスを作成します。
CREATE TABLE [Customer](
[CustomerID] [int] IDENTITY(1,1)NOT NULL PRIMARY KEY CLUSTERED,
[Title] [nvarchar](8)NULL,
[FirstName] [nvarchar](50)NOT NULL,
[LastName] [nvarchar](50)NOT NULL,
[EmailAddress] [nvarchar](50)NULL,
[Phone] [nvarchar](30)NULL,
[Timestamp] [timestamp] NOT NULL
);
CREATE INDEX IX_Customer_EmailAddress
ON Customer(EmailAddress);
e）同じようにレコードを１行追加します。
INSERT INTO [Customer]
([Title],[FirstName],[LastName],[EmailAddress],[Phone])
VALUES
('Mr','David','Alexander','davida@fabrikam.com','555-1234-5555');
SQL Azureがリレーショナルデータベースとして機能していることを確認するために、実行計画を表示してみます。SSMSであればボタン一発で表示できますが、コマンドで実行すると下記のようになります。
f）SQLの実行計画を表示します。
SET SHOWPLAN_ALL ON
GO
SELECT * FROM Customer WHERE EmailAddress ='davida@fabrikam.com'
GO
SET SHOWPLAN_ALL OFF
メールアドレスの索引が使われていることを確認できます。
続いて、プロシージャーを作成してみましょう。1件ごとにカウントアップしながらレコードを作成する簡単なものです。
g）プロシージャーを作成します。
CREATE PROCEDURE AddData
@NumRows int
AS
DECLARE @counter int
SELECT @counter = 1
WHILE (@counter < @NumRows)
BEGIN
INSERT INTO [Customer]
([Title],[FirstName],[LastName],[EmailAddress],[Phone])
VALUES
('Mr','David','Alexander',CAST(@counter as nvarchar)+'davida@fabrikam.com','555-1234-5555')
SELECT @counter = @counter + 1
END
h）これを1万回実行してみます。
EXEC AddData 10000
程なくレコードが作成されます。
この手順の詳細は、有志が翻訳に取り組んでWindows Azure Communityで公開しているトレーニングキットに記されていますので、適宜ご参照ください。英語版の本家はこちらで参照できます。
既存のSQL Serverのアプリケーションをクラウドに移行するシナリオにSQL Azureを適用しようとするならば、もっと複雑なSQLを実行できる必要があります。しかし、SQL Azureによってクラウド上のデータに対してSQLをそのまま使える点については、ご理解いただけたと思います。
SQLはそのまま使えるが、アーキテクチャーは変更すべき
ここまで簡単に説明した通り、SQL Azureによって、SQL文は原則そのままにアプリケーションからクラウド上のDBにアクセスできるようになります。実際には、分散クエリなどいくつかの機能の提供が遅れているためSQL Serverとの互換性が完全であるとは言い切れません。ですが、小規模アプリケーションにおいては、少なくともデータアクセス部分では、移行工数をかけることなくクラウドに持ち込めます。
ただし、データ量が急増する可能性がある大規模アプリケーションで使う場合は、システムのアーキテクチャーを考え直す必要があります。なぜならSQL Azureは、上位版のビジネスエディションでさえデータ量の上限が10GB（下位エディションでは1GB）に制限されているからです。
リレーショナルデータベースの設計者は、整合性、可用性、拡張性の3つを考えてアプリケーションを設計していますが、これまではサーバー構成などの物理設計についてはあまりかかわってきませんでした。クラウド時代には、この様相が変わってくるでしょう。
クラウドの世界には、Consistency（一貫性）とAvailability（可用性）とPartitions（分散）の状態のうち同時に2つまでしか達成できないというCAP定理があります。これを正しいものとすると、可用性と整合性を重視しているSQL Azureでは、拡張性（分散）を犠牲にする必要があるでしょう。
犠牲を払った部分である拡張性に関して、ソフトウエア設計者が知恵を絞る必要があります。特に、分散クエリや分散トランザクションなどの機能がサポートされない初期版のSQL Azureでは、10GBのデータベース・サイズの上限を有効に活用できるよう、データを適切に分割する必要があります。さらに、整合性を保つ単位を小さくして、トランザクションを適切に分割します。これらの工夫により、小さく分割したDB群に対する能動的な分散アクセスがやりやすくなります。
データベースを複数のデータベースに分割するという対処方法は、SQL Azureの初期版においては、単にシステム上の制約条件に対処したという意味しかありません。しかし、SQL Azureの将来のバージョンにおいて分散機能や自動拡張がサポートされるようになった暁には、データの可搬性（ポータビリティ）の向上や性能向上に貢献する可能性のあるTipsとなり得ます。
次回は、SQL AzureとAzure Storage Services（Windows Azureが標準で提供するストレージ・サービス）の違いと使い分けについて説明します。
