AzureにSQLで問い合わせてみましょう。Serverと同じように実行できます。a)まずは簡単なテーブルを作成します。CLUSTERED);b)レコードを3行追加します。(3)GOc)テーブルの状況を確認します。HoLTestTable;3行追加されていることが確認できます。FROM文を使用できることが分かります。続いて、もう少し列数が多いテーブルを作成し、PKとインデックスを作成してみましょう。d)列数が多いテーブル、PK、インデックスを作成します。Customer(EmailAddress);e)同じようにレコードを1行追加します。Azureがリレーショナルデータベースとして機能していることを確認するために、実行計画を表示してみます。SSMSであればボタン一発で表示できますが、コマンドで実行すると下記のようになります。f)SQLの実行計画を表示します。OFFメールアドレスの索引が使われていることを確認できます。続いて、プロシージャーを作成してみましょう。1件ごとにカウントアップしながらレコードを作成する簡単なものです。g)プロシージャーを作成します。ENDh)これを1万回実行してみます。10000程なくレコードが作成されます。Communityで公開しているトレーニングキットに記されていますので、適宜ご参照ください。英語版の本家はこちらで参照できます。Azureを適用しようとするならば、もっと複雑なSQLを実行できる必要があります。Azureによってクラウド上のデータに対してSQLをそのまま使える点については、ご理解いただけたと思います。Azureによって、SQL文は原則そのままにアプリケーションからクラウド上のDBにアクセスできるようになります。Serverとの互換性が完全であるとは言い切れません。小規模アプリケーションにおいては、少なくともデータアクセス部分では、移行工数をかけることなくクラウドに持ち込めます。データ量が急増する可能性がある大規模アプリケーションで使う場合は、システムのアーキテクチャーを考え直す必要があります。Azureは、上位版のビジネスエディションでさえデータ量の上限が10GB(下位エディションでは1GB)に制限されているからです。3つを考えてアプリケーションを設計していますが、これまではサーバー構成などの物理設計についてはあまりかかわってきませんでした。クラウド時代には、この様相が変わってくるでしょう。クラウドの世界には、Consistency(一貫性)とAvailability(可用性)とPartitions(分散)の状態のうち同時に2つまでしか達成できないというCAP定理があります。Azureでは、拡張性(分散)を犠牲にする必要があるでしょう。犠牲を払った部分である拡張性に関して、ソフトウエア設計者が知恵を絞る必要があります。Azureでは、10GBのデータベース・サイズの上限を有効に活用できるよう、データを適切に分割する必要があります。整合性を保つ単位を小さくして、トランザクションを適切に分割します。これらの工夫により、小さく分割したDB群に対する能動的な分散アクセスがやりやすくなります。Azureの初期版においては、単にシステム上の制約条件に対処したという意味しかありません。Azureの将来のバージョンにおいて分散機能や自動拡張がサポートされるようになった暁には、データの可搬性(ポータビリティ)の向上や性能向上に貢献する可能性のあるTipsとなり得ます。Azureが標準で提供するストレージ・サービス)の違いと使い分けについて説明します。この著者の記事一覧クラウドコンピューティングを主な守備範囲とするエバンジェリスト。日本オラクルでERPや新規事業開発を担当した経験を持つ。戦略コンサルタントだった時期もあるが、クラウドやAzureの可能性に惹き付けられマイクロソフトに参画。ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。VeloCloudが選ばれる理由SD-WANとはなにか。Linuxエンジニア育成への思いF5とNGINXの組み合わせで、サービス公開をよりセキュアに。ITがお届けするポッドキャストです。IT(シンクイット)エラーサイトに予期せぬエラーが起こりました。たってから再度お試しください。