次の方法で共有

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

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

トランザクション データ

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

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

トランザクション データベースでは、ペシミスティック ロックなど、さまざまなロック戦略を使用して、トランザクションの強力な整合性をサポートできます。 これらの戦略は、すべてのユーザーとプロセスについて、すべてのデータがワークロードのコンテキスト内で一貫性を保つのに役立ちます。

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

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

トランザクション データには、次のような特徴があります。

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

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

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

OLTP システムは、トランザクションを効率的に処理して格納し、トランザクション データにクエリを実行するように設計されています。 OLTP システムによる個々のトランザクションの効率的な処理と格納の目標は、データの正規化によって部分的に達成され、データがより小さく冗長なチャンクに分割されます。 この手順により、OLTP システムは多数のトランザクションを個別に処理できます。 また、冗長データが存在する場合にデータの整合性を維持するために必要な追加のプロセスも回避されます。

課題

OLTP システムでは、いくつかの課題が発生する可能性があります。

  • 何百万もの個々のトランザクションにわたって集計計算に依存するデータに対して分析を実行する場合、OLTP システムではリソースが非常に多くなります。 実行が遅くなることがあり、データベース内の他のトランザクションをブロックすることで全体のパフォーマンスが低下する原因となる可能性があります。 そのため、OLTP システムは、大量の分散データに対する集計の処理に常に最適とは限りません。 ただし、適切に計画されたスキーマなどの例外があります。

  • 高度に正規化されたデータに対して分析とレポートを実行する場合、ほとんどのクエリでは結合を使用してデータを非正規化する必要があるため、クエリは複雑になる傾向があります。 正規化を増やすと、データベース管理者 (DBA) またはデータ開発者の助けを借りずに、ビジネス ユーザーがクエリを実行することが困難になる可能性があります。

  • トランザクションの履歴を無期限に格納したり、1 つのテーブルに格納するデータが多すぎると、格納するトランザクションの数によってはクエリのパフォーマンスが低下する可能性があります。 一般的な解決策は、OLTP システムで関連する時間枠 (現在の会計年度など) を維持し、履歴データをデータ マートや データ ウェアハウスなどの他のシステムにオフロードすることです。

Azure の OLTP

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

実際には、ほとんどのワークロードは完全に OLTP ではありません。 多くの場合、分析コンポーネントも含まれており、運用システムに対してレポートを実行するなど、リアルタイムのレポートが必要です。 このワークロードは、ハイブリッド トランザクションおよび分析処理 (HTAP) と呼ばれます。 詳細については、「 オンライン分析処理 (OLAP)」を参照してください。

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

主要な選択条件

選択肢を絞り込むには、まず次の質問に答えます。

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

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

  • 書き込みスループットの要件は高いですか? "はい" の場合は、メモリ内テーブルまたは Azure Cosmos DB などのグローバル分散機能を提供するオプションを選択します。

  • ソリューションはマルチテナントですか。 その場合は、容量プールをサポートするオプションを検討してください。 複数のデータベース インスタンスは、データベースあたりの固定リソースではなく、リソースのエラスティック プールから取得されます。 エラスティック プールは、すべてのデータベース インスタンスに容量を分散し、ソリューションのコスト効率を高めるのに役立ちます。 Azure Cosmos DB には、マルチテナント シナリオ用の複数の分離モデルが用意されています。

  • 複数のリージョンで待機時間の短いデータの読み取りが可能である必要がありますか。 "はい" の場合は、読み取り可能なセカンダリ レプリカまたはグローバル分散をサポートするオプションを選択します。

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

  • ワークロードには保証された ACID トランザクションが必要ですか? 非リレーショナル データを使用する場合は、Azure Cosmos DB を検討してください。これにより、論理パーティション内のトランザクション バッチ操作による ACID の保証が提供されます。

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

  • ソリューションには分散トランザクションが必要ですか? "はい" の場合は、Azure SQL Database と SQL Managed Instance 内のエラスティック トランザクションを検討してください。 SQL Managed Instance では、Microsoft 分散トランザクション コーディネーター (MSDTC) を介した従来の呼び出しもサポートされています。

次のステップ