AzureQueue テーブルエンジン

このエンジンは Azure Blob Storage エコシステムとの統合を提供し、ストリーミングデータのインポートを可能にします。

テーブルの作成

エンジンのパラメータ

AzureQueue のパラメータは AzureBlobStorage テーブルエンジンがサポートしているのと同じです。パラメータセクションは こちら を参照してください。

AzureBlobStorage テーブルエンジンと同様に、ユーザーはローカルの Azure Storage 開発のために Azurite エミュレーターを使用できます。詳細は こちら を参照してください。

例

設定

サポートされている設定のセットは S3Queue テーブルエンジンと同じですが、s3queue_ プレフィックスはありません。設定のフルリストを参照してください。 テーブルに対して設定された設定のリストを取得するには、system.azure_queue_settings テーブルを使用します。利用可能は 24.10 以降です。

説明

ストリーミングインポートに対して SELECT は特に便利ではありません（デバッグを除く）、なぜなら各ファイルは一度だけインポートできるからです。実際には、マテリアライズドビューを使用してリアルタイムスレッドを作成するのがより実用的です。これを行うには：

1. エンジンを使用して、S3の指定されたパスからデータを消費するためのテーブルを作成し、それをデータストリームと見なします。
2. 望ましい構造を持つテーブルを作成します。
3. エンジンからデータを変換し、以前に作成したテーブルに挿入するマテリアライズドビューを作成します。

MATERIALIZED VIEW がエンジンを結合すると、バックグラウンドでデータの収集を開始します。

例：

仮想カラム

• _path — ファイルへのパス。
• _file — ファイルの名前。

仮想カラムに関する詳細は こちら を参照してください。

内部情報

テーブル設定 enable_logging_to_queue_log=1 を介してテーブルのロギングを有効にします。

内部情報の機能は、S3Queue テーブルエンジン と同様ですが、いくつかの明確な違いがあります：

1. サーバーバージョン >= 25.1 では、system.azure_queue を使用してキューのメモリ内状態を確認します。古いバージョンでは system.s3queue を使用します（それには azure テーブルに関する情報も含まれます）。
2. メインの ClickHouse 構成を介して system.azure_queue_log を有効にします。例えば：

この永続テーブルは system.s3queue と同じ情報を持っていますが、処理され、失敗したファイルに関するものです。

テーブルの構造は以下の通りです：

例：