次の方法で共有

オンライン トランザクション処理 (OLTP)

  • [アーティクル]

コンピューター システムを使用したトランザクション データの管理は、オンライン トランザクション処理 (OLTP) と呼ばれます。 OLTP システムは、組織の日常的な業務でビジネス インタラクションが発生したときに記録し、そのデータに対してクエリを実行して推論する処理をサポートします。

トランザクション データ

トランザクション データは、組織の活動に関連するインタラクションを追跡する情報です。 これらのインタラクションは、通常は、顧客から受け取った支払い、業者に対して行われた支払い、在庫の移動、受注、提供されたサービスなどのビジネス トランザクションです。 トランザクション イベントはトランザクション自体を表し、通常は、時間ディメンション、何らかの数値、および他のデータへの参照が含まれます。

トランザクションは、通常は "アトミック" かつ "一貫性がある" 必要があります。 アトミックとは、トランザクション全体が 1 つの作業単位として常に成功するか失敗し、半分完了した状態のままになることがないことを意味します。 トランザクションを完了できない場合、データベース システムは、トランザクションの一部として既に実行されたすべての手順をロールバックする必要があります。 従来のリレーショナル データベース管理システム (RDBMS) では、このロールバックは、トランザクションを完了できない場合に自動的に発生します。 一貫性とは、トランザクションが、常に有効な状態でデータを確保することを意味します (これらは、アトミックと一貫性の非常に砕けた説明です。これらのプロパティの正式な定義については、ACID などを参照してください)。

トランザクション データベースは、ペシミスティック ロックなどのさまざまなロック戦略を使用してトランザクションの強力な一貫性をサポートすることで、すべてのユーザーとプロセスのすべてのデータがエンタープライズのコンテキスト内で厳密に一貫性があることを保証できます。

トランザクション データを使用する最も一般的な展開アーキテクチャは、3 層アーキテクチャ内のデータ ストア層です。 3 層アーキテクチャは、通常、プレゼンテーション層、ビジネス ロジック層、およびデータ ストア層で構成されます。 関連する展開アーキテクチャは N 層アーキテクチャであり、ビジネス ロジックを処理する複数の中間層を持つことができます。

トランザクション データの一般的な特徴

トランザクション データは、次の特徴を持つ傾向があります。

要件 説明
正規化 高度に正規化
スキーマ 書き込み時のスキーマ。厳密に適用
一貫性 強力な一貫性。ACID を保証
整合性 高い整合性
トランザクションの使用 はい
ロック戦略 ペシミスティックまたはオプティミスティック
更新可能 はい
追加可能 はい
ワークロード 高負荷の書き込み。中程度の読み取り
インデックス作成 プライマリ インデックスとセカンダリ インデックス
データ サイズ 小～中のサイズ
モデル リレーショナル
データ シェイプ 表形式
クエリの柔軟性 高い柔軟性
スケール 小 (MB) ～ 大 (数 TB)

このソリューションを使用する状況

ビジネス トランザクションを効率的に処理して保存し、一貫した方法でクライアント アプリケーションですぐに利用できるようにする必要がある場合は、OLTP を選択します。 処理が明らかに遅れた場合に日常業務に悪影響が及ぶ場合は、このアーキテクチャを使用します。

OLTP システムは、トランザクションを効率的に処理および格納し、トランザクション データに対してクエリを実行できるように設計されています。 OLTP システムで個々のトランザクションを効率的に処理して保存するという目標は、データの正規化 (つまり、データを冗長性の低い小さなチャンクに分割する処理) によって部分的に達成されます。 OLTP システムを使用して大量のトランザクションを独立して処理できるようになり、冗長データが存在する場合は、データ整合性を維持するために必要な余計な処理が回避されるため、効率的でもあります。

課題

OLTP システムを実装して使用すると、いくつかの課題が生じる可能性があります。

  • OLTP システムは、入念に計画された SQL Server ベースのソリューションなどの例外はありますが、大量のデータに対する集計の処理には必ずしも適していません。 データに対する分析は、数百万単位の個々のトランザクションを集計する計算に依存しており、OLTP システムにとっては非常にリソースを消費する処理です。 実行に時間がかかり、データベース内の他のトランザクションをブロックして速度の低下が発生する可能性があります。
  • 高度に正規化されたデータの分析とレポート作成を行う場合、クエリは複雑になる傾向があります。なぜなら、ほとんどのクエリでは、結合を使用してデータを正規化する必要があるためです。 また、OLTP システムのデータベース オブジェクトの名前付け規則は簡潔な傾向があります。 正規化の増加と簡潔な名前付け規則の組み合わせにより、ビジネス ユーザーが DBA やデータの開発者から支援を受けずに OLTP システムでクエリを実行することは困難になっています。
  • トランザクションの履歴を無期限に格納し、1 つのテーブルに格納されるデータ量が多くなりすぎると、格納されるトランザクション数に応じてクエリのパフォーマンスが低下する可能性があります。 一般的な解決策は、OLTP システムで関連する時間枠 (現在の会計年度など) を維持し、履歴データをデータ マートやデータ ウェアハウスなどの他のシステムにオフロードすることです。

Azure の OLTP

App Service Web Apps でホストされている Web サイト、App Service で実行されている REST API、モバイル アプリケーションやデスクトップ アプリケーションなどのアプリケーションは、通常、REST API の中継ぎを介して OLTP システムと通信します。

実際には、ほとんどのワークロードは純粋には OLTP ではありません。 分析コンポーネントに近い傾向もあります。 さらに、運用システムに対してレポートを実行するなど、リアルタイム レポートの需要が高まっています。 これは、ハイブリッド トランザクション/分析処理 (HTAP: Hybrid Transactional and Analytical Processing) とも呼ばれます。 これは、HTAP (ハイブリッド トランザクション/分析処理) とも呼ばれます。 詳細については、「Online Analytical Processing (OLAP) (オンライン分析処理 (OLAP))」を参照してください。

Azure では、次のすべてのデータ ストアが OLTP とトランザクション データの管理のコア要件を満たします。

主要な選択条件

選択肢を絞り込むために、まず次の質問に答えてください。

  • 独自のサーバーを管理するのではなく、管理されたサービスが必要ですか。

  • ソリューションには、Microsoft SQL Server、MySQL、または PostgreSQL との互換性について特定の依存関係がありますか。 アプリケーションによってデータ ストアが制限される場合があり、データ ストアとの通信をサポートするドライバーや、使用されるデータベースに関する仮定に基づいて選択できます。

  • 書き込みスループットの要件が特に高いですか。 答えが「はい」の場合は、インメモリ テーブルを提供するオプションを選びます。

  • ソリューションはマルチテナントですか。 その場合は、複数のデータベース インスタンスがデータベースごとに固定のリソースではなくリソースのエラスティック プールから取り込まれる容量プールをサポートするオプションを検討してください。 これにより、すべてのデータベース インスタンス間での容量の分配が向上し、ソリューションのコスト効果が向上する可能性があります。

  • 複数のリージョンで待機時間の短いデータの読み取りが可能である必要がありますか。 答えが「はい」の場合は、読み取り可能なセカンダリ レプリカをサポートするオプションを選びます。

  • データベースは地理的なリージョン全体で可用性が高い必要がありますか。 答えが「はい」の場合は、地理的なレプリケーションをサポートするオプションを選びます。 また、プライマリ レプリカからセカンダリ レプリカへの自動フェールオーバーをサポートするオプションも検討します。

  • データベースには特定のセキュリティ ニーズがありますか。 答えが「はい」の場合は、行レベル セキュリティ、データ マスキング、透過的なデータ暗号化などの機能を提供するオプションを確認します。

機能のマトリックス

次の表は、機能の主な相違点をまとめたものです。

一般的な機能

機能 Azure SQL データベース Azure 仮想マシン内の SQL Server Azure Database for MySQL Azure Database for PostgreSQL
マネージド サービス はい いいえ イエス はい
実行するプラットフォーム 該当なし Windows、Linux、Docker 該当なし 該当なし
プログラミング 1 T-SQL、.NET、R T-SQL、.NET、R、Python SQL SQL、PL/pgSQL、PL/JavaScript (v8)

[1] 多くのプログラミング言語が OLTP データ ストアに接続して使用できるクライアント ドライバー サポートは含まれません。

スケーラビリティ機能

機能 Azure SQL データベース Azure 仮想マシン内の SQL Server Azure Database for MySQL Azure Database for PostgreSQL
データベース インスタンスの最大サイズ 4 TB 256 TB 16 TB 16 TB
容量プールをサポート はい はい いいえ いいえ
クラスターのスケールアウトをサポート いいえ 有効 いいえ いいえ
動的スケーラビリティ (スケールアップ) はい いいえ イエス はい

分析ワークロード機能

機能 Azure SQL データベース Azure 仮想マシン内の SQL Server Azure Database for MySQL Azure Database for PostgreSQL
テンポラル テーブル はい はい いいえ いいえ
インメモリ (メモリ最適化) テーブル はい はい いいえ いいえ
列ストアをサポート はい はい いいえ いいえ
アダプティブ クエリ処理 はい はい いいえ いいえ

可用性に関する機能

機能 Azure SQL データベース Azure 仮想マシン内の SQL Server Azure Database for MySQL Azure Database for PostgreSQL
読み取り可能なセカンダリ はい イエス イエス はい
地理的なレプリケーション はい イエス イエス はい
セカンダリへの自動フェールオーバー はい いいえ いいえ いいえ
ポイントインタイム リストア はい イエス イエス はい

セキュリティ機能

機能 Azure SQL データベース Azure 仮想マシン内の SQL Server Azure Database for MySQL Azure Database for PostgreSQL
行レベルのセキュリティ はい イエス イエス はい
データ マスク はい はい いいえ いいえ
透過的なデータ暗号化 はい イエス イエス はい
特定の IP アドレスへのアクセスを制限 はい イエス イエス はい
VNet アクセスのみを許可するようにアクセスを制限 はい イエス イエス はい
Microsoft Entra 認証 はい いいえ イエス はい
Active Directory 認証 いいえ 有効 いいえ いいえ
多要素認証 はい いいえ イエス はい
Always Encrypted をサポート はい はい いいえ いいえ
プライベート IP いいえ 有効 いいえ いいえ

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

次のステップ