テーブルの作成
AzureQueue のパラメータは、AzureBlobStorage テーブルエンジンでサポートされているものと同じです。パラメータについては、こちらを参照してください。
AzureBlobStorage テーブルエンジンと同様に、ローカルで Azure Storage を開発する際には Azurite エミュレータを使用できます。詳細はこちらを参照してください。
例
設定
S3Queue テーブルエンジンと同じですが、s3queue_ プレフィックスは付きません。設定の完全な一覧を参照してください。
テーブルに対して設定されている項目の一覧を取得するには、system.azure_queue_settings テーブルを使用します。24.10 から利用できます。
以下は、AzureQueue でのみ使用でき、S3Queue には適用されない設定です。
after_processing_move_connection_string
- String。
after_processing_move_container
- String.
AzureQueue テーブルエンジン での SELECT
stream_like_engine_allow_direct_select を True にする必要があります。
AzureQueue engine には、SELECT クエリ向けの特別な設定 commit_on_select があります。読み取り後もキュー内のデータを保持するには False に設定し、削除するには True に設定します。
説明
SELECT はストリーミングインポートにはあまり適していません (デバッグ用途を除く) 。各ファイルは一度しかインポートできないためです。代わりに、materialized view を使ってリアルタイムの処理パイプラインを作成するほうが実用的です。手順は次のとおりです。
- エンジンを使用して、S3 内の指定したパスからデータを読み込むためのテーブルを作成し、それをデータストリームとして扱います。
- 必要な構造を持つテーブルを作成します。
- エンジンからのデータを変換し、あらかじめ作成したテーブルに書き込む materialized view を作成します。
MATERIALIZED VIEW でそのエンジンを参照すると、バックグラウンドでデータの収集が開始されます。
例:
仮想カラム
_path— ファイルのパス。_file— ファイル名。
イントロスペクション
enable_logging_to_queue_log=1 で、このテーブルのログ記録を有効にします。
イントロスペクション機能は S3Queue テーブルエンジン と同じですが、いくつか異なる点があります。
- server バージョンが >= 25.1 の場合、queue のインメモリ状態には
system.azure_queue_metadata_cacheを使用します。古いバージョンではsystem.s3queue_metadata_cacheを使用します (これにはazureテーブルの情報も含まれます) 。 - メインの ClickHouse 設定で
system.azure_queue_logを有効にします。例:
system.s3queue_metadata_cache と同じ情報が含まれていますが、対象は処理済みおよび失敗したファイルです。
このテーブルの構造は次のとおりです。