キュー テーブルは、特別なデータベース オブジェクトです。 それは、イベント処理および非同期データ ロード アプリケーションなどのキュー指向のデータ処理、およびその後のバッファ データ ロードの複雑な処理に使用される永続テーブルです。キュー テーブルの特性は通常の実テーブルの特性と似ていますが、非同期の先入れ先出し(FIFO)キューのように動作するための追加の固有特性もあります。
- MPPシステムの各ノードのシステム クロックが同期されていない。
- 行のQITS値はユーザーが設定または更新できるため、キュー内での行の位置が変わる可能性がある。
- トランザクション ロールバックによって元のQITS値を持つ行が復元された場合、すでに消費された行よりも前の値になる可能性がある。
- 同じ複数文リクエストに含まれる複数の挿入操作に、同じQITS値が割り当てられる可能性がある。
- Teradata Workload Managerが使用可能な場合、1つ以上のルールによってCONSUMEモード操作の実行が延期される可能性があります。原則として、SELECT AND CONSUME操作に影響を与えるルールは作成しないでください。そのようなワークロードの制限を設定すると、キュー テーブルの行が「本当の意味での」先入れ先出し(FIFO)順序と異なる度合いが大きくなります。
キュー テーブルは、通常のテーブルに、FIFOキュー順に配列された行の記録を保持するメモリ常駐キャッシュが割り当てられたものと考えることができます(キュー テーブル キャッシュを参照)。さらに、使用済みの行は検索と同時にデータベースから削除されるので、行に対して複数回の処理が行なわれないことが保証されます。
指定のキュー テーブルのほとんどの行(すべてではない)はPE上のメモリに常駐しているので、非キュー テーブルに対するプライマリ インデックス操作と似た方法で処理され、行ハッシュWRITEロックを行に適用した単一のAMP操作になります。
- カーディナリティが低い(行が挿入されるのとほぼ同じ割合で消費されることを暗示する)。
- 行に対するUPDATE操作の頻度が低い。
- 行に対するDELETE操作の頻度が低い。
標準の永続テーブル定義とは異なり、キュー テーブル定義にはユーザー定義の挿入タイムスタンプ(QITS)がテーブルの最初の列として常に含まれている必要があります。QITS列には、行がキュー テーブルに挿入された時刻が含まれます。システムはそれを使用して、先入れ先出しの順序を大まかに決めます。タイムスタンプ値は繰り返されたり更新されたりすることがあるので、QITS値は固有ではない可能性もありますが、Teradata Databaseはキュー内の行の固有性を常に保証します。
- メッセージまたはワークフロー ベースのモデルなどのキュー指向のアプリケーションをより優れた方法で実装できる。
- 内部的または外部的に生成されたクエリーが、データベースを定期的にポーリングしてイベント関連のデータを検出しなくても、キュー内でのイベント データの出現をアクティブに待機できる。
- アプリケーションがイベント関連のデータをキュー テーブルに挿入するための、非同期のロードおよび処理のプログラム構造をサポートする。その後、そのデータをバッファに入れて、独自に複雑な分析を実行するかまたはデータを後に分析できるように他の処理キューに入れるために、ユーザー開発のプロシージャによって処理できます。
- データベース管理システムとサード パーティ製のメッセージ ベースのEnterprise Application Integration (EAI)アプリケーションとを中継するインターフェースの開発機能をサポートする。たとえば、ストアド プロシージャ、マクロ、またはSQL INSERT文を呼び出して、データをキュー テーブルに挿入するための外部アダプタを記述できます。同様に、サード パーティ製のEAIアプリケーション キューに挿入するためにキュー テーブルからデータを抽出する外部アダプターを記述できます。
- イベント アラート。
イベントがデータベース管理システムで実行しているアプリケーション コード(ストアド プロシージャなど)によって検出されると、それはたとえば、その出来事に由来するデータをトリガーによってイベント キュー テーブルに挿入できます。その後、外部イベント処理アプリケーションは、SELECT AND CONSUME TOP 1文を実行してイベントをデータベースから抽出できます。そのリクエストは、データがキュー テーブルに挿入されるまで待機します。データがキューに到達すると、待機中のSELECT AND CONSUME TOP 1文によって結果が外部アプリケーションに返され、そこでデータがさらに処理されます。
その後、外部アプリケーションは、別のSELECT AND CONSUME TOP 1文をループおよび実行して、イベント データがさらにキュー テーブルに挿入されるまで待機します。この機能により、非キュー テーブルを使用する場合にアプリケーションが使用するポーリング ループ(イベントが発生するまで待機しながら自動的に繰り返しSELECT文を実行する)が不要になります。
- 非同期の処理を伴うデータのロード。
そのような非同期の処理を伴うデータのロードの典型的な例は、外部のメッセージ ソースからキュー テーブルにロードされているデータです。
データの各部分には、大量の処理が必要となることがあります。入って来るデータをデータベース到着直後に処理する代わりに、システムはそれをキュー テーブル内のバッファに入れることができます。新規に挿入されたデータは、SELECT AND CONSUME TOP 1文を使用してコーディングされたストアド プロシージャのグループによる処理が可能になります。このリクエストは、データがキュー テーブルに挿入されることを待機します。ストアド プロシージャのグループは、キュー テーブル データを処理する作業を分担します。到着するイベント データの各部分は、使用可能なストアド プロシージャにパーセルされて処理されます。
この技法により、各種データ ローディングの流入率に応じて、リソースの消費が平滑化されます。キュー テーブル データの処理に必要なストアド プロシージャ数を制御することにより、リソース消費の最高速度、および最大のスループット率を管理できます。
たとえば、流入率の高い短期間、システムは最初にデータをキュー テーブルのバッファに入れることができます。流入率がユーザー定義の臨界レベルより小さくなると、待機中のストアド プロシージャはバッファに入れられたキュー テーブル データを処理できるようになります。
- スケジュール変更。
運送業者が予想外のスケジュール変更を行なう必要がある場合、予約システムやコール センター システムなどの追加のエンティティは、その変更の影響を処理するために通知を受ける必要があります。
例えば、スケジュール変更を通知された予約システムは、影響を受けるすべての取引の再予約を開始できます。
顧客に通知して再予約を行なうための前線となるのは、コール センターです。コール センターは、顧客のキューに基づいて処理を行ないます。この例では、スケジュール変更の通知を必要とする顧客のキューです。複数のコールは、変更に伴う運搬距離が長いか短いか、変更の重要度、スケジュール変更によって生じる遅延の長さ、その顧客の企業にとっての重要度など、いくつかの要素を考慮に入れたビジネス ルールを適用して優先順位が決められます。
これらの各システムの分析用の入力は、キュー テーブルとしてモデル化できます。たとえば、あるキュー テーブルに含まれるメッセージは、スケジュール変更を表わすことがあります。そのキュー テーブルを読み取るストアド プロシージャは、予約、コール センター システム、その他のメッセージをキュー テーブルに挿入できます。その後、コール センターのキュー テーブルからデータを使用するアプリケーションによって、スケジュール変更の通知を必要とする顧客にコール センターのエージェントを割り当てることが可能になります。
エラー テーブルを作成すると、キュー テーブルに対するバッチ挿入および更新のエラーを追跡できます。エラー テーブルの詳細については、CREATE ERROR TABLEを参照してください。また、これらのDMLリクエストによるバッチ挿入および更新のエラー追跡を指定する方法については、<Teradata Vantage™ - SQLデータ操作言語、B035-1146>の「INSERT/INSERT … SELECT」および「MERGE」を参照してください。