Azure SQL Database を使用して最新のデータベース要件に対処する

5 分

環境を構成したら、潜在的なソリューションアーキテクチャの特定コンポーネントの分析およびテストをいつでも開始できます。バス乗車のシナリオを始め、他の多くの最新アプリケーションでは、データを格納して処理し、提供するための最新のデータベースが必要です。最新のアプリケーションのニーズを Azure SQL Database でどのように満たせるか、見てみましょう。

柔軟な Azure SQL Database オプションを使用して需要に合わせてスケーリングする

最新のアプリケーションの主要な要素の 1 つに、ワークロードの使用状況に正しく対応するために、簡単にスケールアップまたはスケールダウンできる機能があります。ソリューションを簡単に更新して進化させる機能と、決定論的な自動デプロイも、最新のアプリケーション開発の基礎となる柱です。さらに、この原則により、必要なときに必要な分だけ支払いを行う機能がアプリケーションに提供されます。

Azure SQL Database では、これらのすべての必要な機能を強力にサポートします。将来性と拡張性に優れ、セキュリティで保護された高パフォーマンスのデータベースが必要な場合、Azure SQL Hyperscale を使用すれば、必要なすべての機能と、追加の機能が提供されます。最大 100 TB までスケールアップでき、分散アーキテクチャにより、スケールアップとスケールアウトが容易になります。これはトランザクションワークロードとハイブリッドのトランザクション分析ワークロードに最適なデータベースです。

開発と開発者をサポートするために、Azure SQL Database サーバーレスコンピューティングレベルを使用できます。これは、定義した範囲内で自動的にスケールアップおよびスケールダウンでき、使用していない場合に自動的に一時停止できるため、ソリューションの開発とテストを最もコスト効率よく行うことができます。 Azure SQL Database の背後にあるエンジンは同じであるため、Azure SQL Database サーバーレスコンピューティングレベルと Azure SQL Hyperscale に移行する際に、コードの変更や追加の作業は必要ありません。

GitHub Actions を使用して開発ワークフローをサポートする

現在は DevOps プラクティスが広く普及しているため、最新のソリューションで適切にサポートし、正常な継続的インテグレーションと継続的デリバリーまたは継続的デプロイ (CI/CD) パイプラインを使用できるようにすることが重要です。 Azure SQL Database では GitHub Actions がネイティブでサポートされています。これを使うと、開発データベースに対する変更を、テストデータベースと運用データベースの準備ができたときにこれらにデプロイできます。 Azure SQL Database アクションでは状態ベースのアプローチを使います。データの DevOps は興味深いトピックです。このトピックの詳細については、モジュールの最後に参照されている公開されているデータのエピソードをご覧ください。

最新のデータベースのもう 1 つの重要な要件は、最新の開発トレンドとイノベーションを扱い、これらに対応していることです。 Azure SQL Database では多くの機能が提供されているため、特定のユースケースに最適なテクノロジやモデルを使用できます。使用可能なすべての機能の概要については、このモジュールの最後のブログ記事を参照してください。

Azure SQL Database を使ってアプリケーションの将来性を確保する

アプリケーションの有効期間中は、可能な限り効率的になるようさまざまなテクノロジを使用することをお勧めします。たとえば、グラフモデルを使用して、ソーシャルネットワークや送電網などの複雑なネットワーク関係を簡単に追跡およびモデル化することができます。また、場合によっては、膨大な量のデータをすばやく集計して、特定の値の増加率を計算する必要があります。これらのすべてのケースや、その他の多くのケースが Azure SQL Database で対処されています。これは、グラフモデル、列ストアインデックス、最大限のスループットに対するメモリ最適化テーブルに対応しています (これらのテーブルは、ハイパフォーマンスを実現するためにインプロセスで読み込まれるコンパイル済みのデータ構造です)。

バス乗車のシナリオでは、Azure SQL Database サーバーレスコンピューティングレベルを使うことで、自動スケールと自動一時停止のサポートにより、必要な分と使った分だけ支払うことができます。必要に応じてデータベースを更新するデプロイパイプラインを作成するには、GitHub Actions を使用します。このシナリオに必要な機能が他にもいくつかあります。それらについて詳しく見てみましょう。次の演習では、これらの機能を実際に使用します。

ネイティブ JSON 機能を使用して JSON データを処理する

Azure SQL Database では、開発者はデータベースとのデータ交換と JSON ドキュメントの格納の両方に JSON を使用できます。これにより、JSON を効率的なトランスポートメカニズムとして使用して、配列やオブジェクトなどのデータのセットをストアドプロシージャに送信して処理することができます。 JSON ドキュメントを作成したら、JSON_VALUE、JSON_MODIFY、OPENJSON などのネイティブ JSON 関数を使用して簡単に操作できます。次に例を示します。

DECLARE @json NVARCHAR(MAX) = '[{"user":{"id": 1, "name": "Anna"}},{"user":{"id": 2, "name": "Davide"}}]'
SELECT * FROM
    OPENJSON(@json) WITH (
        [Id] INT '$.user.id', 
        [Name] NVARCHAR(100) '$.user.name'
    )

Azure SQL Database で JSON を使う方法を示すその他のサンプルは、このモジュールの最後にあります。

ネイティブの地理空間エンジンを使用して地理空間データを分析する

Azure SQL Database には、外部ライブラリをインストールしたりデータを移動したりせずに地理空間クエリを実行するために使用できるネイティブの地理空間エンジンがあります。このエンジンは、データの量が多い場合にコストがかかることがあります。 Azure SQL Database では Open Geospatial Consortium (OGC) 標準が完全にサポートされているため、エクスポートされたデータは OpenLayers のようなライブラリで使用できます。

バス乗車のシナリオでジオフェンスとして機能する多角形を作成し、バスのリアルタイムのデータポイントとして機能するポイントが多角形内にあるかどうかを確認する方法の例を次に示します。

-- Microsoft Building 44
declare @bldg44 as geography = geography::STGeomFromText('POLYGON((-122.13403149305233 47.64136608877112,-122.13398769073248 47.64058891712273,-122.13319924946629 47.64011342667547,-122.13285369830483 47.640106868176076,-122.13254221532335 47.640834858789844,-122.13257628383073 47.6410086568205,-122.13334039023833 47.64144150986729,-122.13403149305233 47.64136608877112))', 4326)

-- A point you want to check
declare @p as geography = geography::STPointFromText('POINT(-122.13315058040392 47.64101193601368)', 4326)

-- Is the point within the perimeter?
select @p.STWithin(@bldg44)