Kusto 取り込みライブラリのベスト プラクティス
この記事では、 Kusto Ingest ライブラリを使用したデータ インジェストのベスト プラクティスについて説明します。
直接インジェストよりもキューに入れられます
運用環境のシナリオでは、キューに登録された取り込みクライアントを使用します。 詳細については、「 Queued インジェスト および Direct インジェストを参照してください。
単一の取り込みクライアント インスタンスを使用する
Kusto Ingest クライアントの実装は、スレッド セーフで再利用可能です。 ターゲット データベースごとに、プロセスごとにキューに入った取り込みクライアントまたは直接取り込みクライアントの単一インスタンスを使用します。 複数のインスタンスを実行すると、データベースがオーバーロードされ、データベースが応答しなくなるか、有効な要求への応答が遅くなる可能性があります。
追跡操作の状態を制限する
大量のデータ ストリームの場合は、インジェスト要求に対する肯定的な通知の使用を制限します。 過剰な追跡により、インジェストの待機時間が長くなり、応答性が低下する可能性があります。 詳細については、「 Operation status」を参照してください。
スループットの最適化
インジェスト パイプラインを計画するときは、インジェストスループットに大きな影響を与える可能性があるため、次の要因を考慮してください。
| 要素 | 説明 |
|---|---|
| データ サイズ | インジェストは、大きなチャンクで行う場合の効率が向上します。 100 MB から 1 GB (非圧縮) のバッチでデータを送信することをお勧めします。 |
| データ形式 | CSV などのデータ形式、または PSV や TSV などの区切りテキスト形式のほか、最大スループット用に最適化された Parquet、JSON、AVRO を優先します。 詳細については、「インジェストでサポートされている Data 形式を参照してください。 |
| テーブル幅 | 重要なデータのみを取り込む。 各列をエンコードしてインデックスを作成する必要があります。つまり、より広いテーブルのスループットが低下する可能性があります。 ingestion マッピングを提供して、取り込まれるフィールドを制御します。 |
| ソース データの場所 | インジェストを高速化するため、リージョンをまたがる読み取りは避けてください。 |
| データベースへの読み込み | データベースのクエリ負荷が高い場合、インジェストの完了に時間がかかります。 |
Note
キューに置かれた取り込みクライアントは、大きなデータ セットをチャンクに分割して集計します。これは、インジェスト前にデータをバッチ処理できない場合に便利です。
コストを最適化する
Kusto クライアント ライブラリを使用してデータベースにデータを取り込む方法は、引き続き最も安価で最も堅牢なオプションです。 お客様には、コストを最適化し、BLOB トランザクションのコスト効率を大幅に高める Azure Storage の価格を利用するために、インジェスト方法を確認することをお勧めします。
コスト効率の高いインジェストの場合:
- ファイル、BLOB、ストリームなど、取り込まれたデータ チャンクの数を制限します。
- 最大 1 GB の非圧縮データの大きなチャンクを取り込む。
- バッチ処理を選択します。
- 余分なストレージ トランザクションを回避するために、正確で圧縮されていないデータ サイズを指定します。
FlushImmediatelyをtrueに設定しないでください。ingest-byタグまたはdrop-by拡張タグを使用して少量のデータを送信しないでください。
Note
最後の 2 つの方法を過剰に使用すると、データの集計が中断され、追加のストレージ トランザクションが発生し、インジェストとクエリのパフォーマンスが低下する可能性があります。