PR

SQL Azureの使い勝手をSQL Serverと比較する

2009年10月19日(月)
砂金 信一郎

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)同じようにレコードを1行追加します。

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が標準で提供するストレージ・サービス)の違いと使い分けについて説明します。

クラウドコンピューティングを主な守備範囲とするエバンジェリスト。日本オラクルでERPや新規事業開発を担当した経験を持つ。戦略コンサルタントだった時期もあるが、クラウドやAzureの可能性に惹き付けられマイクロソフトに参画。
ブログ  http://blogs.itmedia.co.jp/isago/
twitter http://twitter.com/shin135/

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

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

SQL Azureの使い勝手をSQL Serverと比較する | Think IT(シンクイット)

Think IT(シンクイット)

サイトに予期せぬエラーが起こりました。しばらくたってから再度お試しください。