ワークロードの特性 - AWS 規範ガイダンス
読み取り/書き込み比率非リレーショナルワークロード

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ワークロードの特性

これまで、特殊なデータベースコンピューティングプラットフォームは、オンライントランザクション処理 (OLTP) やオンライン分析処理 (OLAP) などの特定のワークロード向けに設計されていましたが、これらの特定の設計パターンにより、他のワークロードでは選択が難しくなりました。たとえば、決定サポートシステムをホストする Oracle データベースは、通常、より大きなブロックサイズを使用して、より少ない I/O オペレーションでキャッシュからより多くのデータを読み取ることをサポートします。一方、OLTP ワークロードでは、ブロックサイズを小さくすることで、小さな行へのランダムなアクセスを優先し、ブロックの競合を減らすことができます。Exadata は、OLTP トランザクションのパフォーマンスを向上させる永続メモリ (PMEM) や Exadata スマートフラッシュキャッシュ、分析クエリを優先するハイブリッド列圧縮 (HCC) やスマートスキャンなどの機能により、任意のタイプの Oracle データベースワークロードまたは任意のワークロードの組み合わせの実行に効果的です。ただし、Exadata ワークロードを移行すると、既存のデータベースタイプやインスタンスを使用する代わりに、ワークロードに専用のデータベースエンジンを使用することを検討できます。 AWS 専用のデータベースを使用すると、複数のワークロードを同じプラットフォームに強制するのではなく、消費ベースのモデルで特定のワークロードに特定のタイプのサービスを簡単に選択できます。前述のように、 は、リレーショナルデータベース、キーバリューデータベース、ドキュメントデータベース、インメモリデータベース、グラフデータベース、時系列データベース、ワイド列データベースなど、さまざまなデータモデルをサポートするために 15 以上の専用エンジン AWS を提供しています。

従来、意思決定サポートシステム用に最適化されたデータベースは、次のような特定の設計パターンとワークロード特性に従います。

  • データベースブロックサイズが大きい (16K または 32K)

  • ファクトテーブルとディメンションテーブルがあり、 star_transformation_enabledパラメータが に設定されているスタースキーマ TRUE

  • HCC、高度な圧縮、基本圧縮などの圧縮機能

  • OLAP 機能

  • が query_rewrite_enabledに設定されているデータベース内のマテリアライズドビューの存在 TRUE

  • 大規模な並列処理

  • 重い I/O フットプリント

一方、OLTP に最適化されたデータベースは、データベースブロックサイズが小さく (8K 以下）、単一ブロック読み取り、同時実行性が高く、バッファキャッシュヒット率が高く、トランザクションのシリアル実行があります。Exadata では、OLTP ワークロード用に設計されたデータベースが分析クエリに頻繁に使用されるアンチパターン、またはその逆が一般的です。Oracle データベースが純粋な OLTP ワークロードに使用される可能性はほとんどありません。これは、便宜上、トランザクションデータベースでレポートクエリを実行するのが一般的であるためです。

Oracle の動的パフォーマンスビューで使用できるさまざまなシステム統計、自動ワークロードリポジトリ (AWR) レポート、および Statspack レポートでは、データベースワークロードが OLTP または OLAP システムとどの程度類似しているかを確認できます。統計は、リクエストごとに 2 つ以上のデータベースブロックで読み取られた読み取りリクエストの合計数Physical read total multi block requestsを示します。Physical read total IO requests と の差は、データベースによって発行された単一ブロック読み取りリクエストの合計数Physical read total multi block requestsを示します。通常、マルチブロックリクエストの数が多いと OLAP システムを示し、シングルブロック読み取りリクエストの数が多いと OLTP システムを示します。さらに、AWR レポートの次の統計は、Oracle データベースで実行されているワークロードが主に OLTP ワークロードか OLAP ワークロードかを明らかにすることもできます。

  • user commits – トランザクションの境界で発行されたコミットの数を反映します。通常、OLTP システムは小さなトランザクションの数が多いため、ユーザーコミットの数が多くなります。一方、OLAP システムは少数の重いトランザクションを実行します。

  • Buffer hit – リクエストされたブロックがディスクアクセスを必要とせずにバッファキャッシュで検出される頻度を示します。通常、OLTP システムのバッファヒット率は 99% を超えていますが、OLAP システムのバッファヒット率は低くなります。

次の表は、OLTP システムと OLAP システム間のワークロード特性の一般的な違いをまとめたものです。

特性

OLTP

OLAP

ブロックサイズ

<= 8K

> 8K

コミットレート

高

低

バッファキャッシュヒット率

> 99%

< 99%

顕著な I/O 待機イベント

DB ファイルのシーケンシャル読み取り、ログファイル同期

DB ファイルの分散読み取り、直接パス読み取り

平均 I/O リクエストサイズ (I/O スループット/IOPS)

< 120K

> 400K

スタースキーマ

存在しない

存在する可能性がある

star_transformation_enabled パラメータ

誤

正

並列処理

低度または無効

高度で有効

データベースが主に OLAP ワークロードをサポートしている場合は、ワークロードを移行するときに Amazon Redshift などの専用データウェアハウスソリューションが適している可能性があります AWS。その後、Amazon S3、Amazon AthenaAmazon Athena Amazon QuickSight などのサービスを使用して、 で分析ソリューション AWSを構築できます。OLTP ワークロードの場合、Oracle データベースに依存している場合は、Amazon RDS for Oracle を含む 6 つのリレーショナルエンジンから選択できます。そうでない場合は、Amazon RDS for PostgreSQL や Aurora PostgreSQL 互換などのオープンソースエンジンを選択できます。Amazon DynamoDB は、リレーショナルモデルを必要とせず、キーバリューストアで提供できる、高度にスケーラブルなトランザクションシステムをホストすることもできます。

読み取り/書き込み比率

もう 1 つの重要な要因は、移行するデータベースでホストされているワークロードの読み取り/書き込み比率です。ほとんどの OLTP システムはレポート目的にも使用され、リソースを大量に消費するアドホックなクエリは重要なトランザクションデータベースに対して実行されます。これにより、重要なアプリケーションコンポーネントでパフォーマンスの問題が発生することがよくあります。これらの重要度が低く、リソース集約型のレポートクエリは、重要な本番稼働用アプリケーションのパフォーマンスへの影響を回避するために、本番稼働用インスタンスのコピーにリダイレクトできます。AWR physical writes統計はディスクに書き込まれたデータブロックの総数を反映し、physical reads統計はディスクから読み取られたデータブロックの総数を指定します。これらの統計を使用して、ワークロードの読み取り割合を次のように判断できます。

Read percentage = physical reads/(physical reads + physical writes)*100

トランザクションがデータベースで読み取りオペレーションを発行する方法に応じて、リードレプリカソリューションまたは Amazon ElastiCache などのデータベース外部のキャッシュソリューションをターゲットアーキテクチャにデプロイできます。これにより、プライマリデータベースインスタンスが読み取りワークロードを処理するために必要なリソースを減らすことができます。Amazon RDS ファミリーの一部であるクラウドネイティブのリレーショナルデータベースエンジンである Amazon Aurora は、最大 15 個の読み取りインスタンスを持つ高度にスケーラブルな読み取り専用ワークロードをサポートする自動スケーリングオプションを提供します。Aurora グローバルデータベースを使用して、各リージョンで高速なローカル読み取りオペレーションと低レイテンシーで複数の AWS リージョンにまたがることもできます。

非リレーショナルワークロード

Oracle Database バージョン 12.c は、リレーショナルデータベース機能を使用した JSON データのネイティブストレージをサポートしています。21c では、Oracle Database が JSON データ型を導入しました。さらに、Simple Oracle Document Access (SODA) 機能を使用すると、NoSQL APIs を使用してドキュメントのコレクションを作成、保存、取得できます。グラフワークロードに Oracle Graph Server を使用することもできます。ただし、Amazon DynamoDB、Amazon Amazon DocumentDB Amazon Neptune などの AWS 専用データベースを使用すると、これらの非リレーショナルワークロードを最も効率的に実行できます。これらのサービスは、特に NoSQL アクセスパターンと特殊なユースケース向けに最適化されています。