テーブルの作成
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 を使ってリアルタイムの処理パイプラインを作成するほうが実用的です。手順は次のとおりです。
- エンジンを使用して、Azure Blob Storage 内の指定したパスからデータを読み込むためのテーブルを作成し、それをデータストリームとして扱います。
- 必要な構造を持つテーブルを作成します。
- エンジンからのデータを変換し、あらかじめ作成したテーブルに書き込む materialized view を作成します。
MATERIALIZED VIEW でそのエンジンを参照すると、バックグラウンドでデータの収集が開始されます。
エンジンの引数は AzureQueue(connection_string, container_name, blobpath, format[, compression]) の形式です。
例:
仮想カラム
_path— ファイルのパス。_file— ファイル名。
イントロスペクション
enable_logging_to_queue_log=1 で、このテーブルのログ記録を有効にします。
イントロスペクション機能は S3Queue テーブルエンジン と同じですが、いくつか異なる点があります。
- server バージョンが >= 25.1 の場合、キューのインメモリ状態には
system.azure_queue_metadata_cacheを使用します。古いバージョンではsystem.s3queue_metadata_cacheを使用します (これにはazureテーブルの情報も含まれます) 。 system.azure_queue_metadataテーブルを使用すると、Keeper に保存されている状態を直接調査できます。各メタデータオブジェクトについて、processed、processing、failedノードの数、および必要に応じてその内容を確認できます。これはsystem.s3_queue_metadataに相当するAzureQueueのテーブルです。- メインの ClickHouse 設定で
system.azure_queue_logを有効にします。例:
system.s3queue_metadata_cache と同じ情報が含まれていますが、対象は処理済みおよび失敗したファイルです。
このテーブルの構造は次のとおりです。
制限事項
AzureQueue は S3Queue と同じ実装を使用しており、同じ制限事項があります。特に、ClickHouse ノードでデバイスレベルの電源障害が発生すると、消費済みの行が気付かないうちに失われる可能性があります。insert が完了するとすぐに、ファイルは Keeper に処理済みとして記録され (after_processing = 'delete' の場合はソースブロブも削除されます) 、一方で挿入された行が永続化されるのはターゲット part が fsync された後です。これはデフォルトでは同期的に行われません (fsync_after_insert = 0) 。推奨されるマテリアライズドビューを介した消費パスでは、ターゲットの MergeTree テーブルで fsync_after_insert = 1 (および fsync_part_directory = 1) を設定することで、この時間的なギャップを大幅に縮小できます。