このトピックでは、データ変換のパフォーマンスに影響を与える要因について説明します。
データ変換タスクの速度は、ソースシャードの数、変換ルールのロジックと複雑さによって異なります。 詳細については、「データ変換の基本」をご参照ください。 ほとんどの場合、1 秒あたり 1 MB の非圧縮データ (85 GB/日) の変換速度に 1 つのシャードが必要です。 たとえば、データが1日あたり1テラバイトの速度でソースLogstoreに書き込まれる場合、ソースLogstore内のシャードの数は12 (1024 GB/85 = 12) でなければなりません。 詳細については、「シャードを分割します。」をご参照ください。
データ変換パフォーマンス
- 出力ログエントリ
- ログサイズ。 出力ログサイズが大きいほど、変換速度が遅くなります。 これは、より大きなデータパケットの出力がより多くのコンピューティングおよびネットワークリソースを必要とするためです。 出力ログのサイズが小さいほど、変換速度は速くなります。出力ログサイズは、出力ログエントリーの数（サイズが大きい場合はログエントリーが分割される）、出力ログエントリーに含まれるフィールドの数、または出力ログエントリーの内容によって測定されます。
- ロググループ。出力されたログエントリーは、タグ付けされ、グループにパッケージ化されます。 より多くのロググループはより多くのネットワークリソースを必要とし、変換速度が遅くなります。 出力ロググループが少ないほど、変換速度が速くなります。
- 変換ロジック
変換ロジックが複雑になればなるほど、変換速度は遅くなる。 これは、より複雑な変換論理が、より多くの検索、計算、および外部リソース同期をもたらすためである。 これらのプロセスは、より多くのコンピューティングおよびネットワークリソースを消費する。 変換ロジックの複雑さが少ないほど、変換速度は速くなります。
- サードパーティのデータソース
サードパーティのソースを使用してデータを強化する場合、プルされたデータのサイズが大きいほど、変換速度が遅くなります。 さらに、OSSオブジェクトなどのプルされたデータが別のリージョンにある場合、変換速度も低下します。
Improve the data transformation performance of the source Logstore
- リアルタイムデータ変換のパフォーマンスを向上させます。
シャードの数を増やして、リアルタイムのデータ変換のパフォーマンスを向上させることができます。 シャードの課金方法の詳細については 従量課金.
- 履歴データ変換のパフォーマンスを向上させる。シャード分割は新しいデータにのみ適用されます。履歴データのサイズが大きく、シャードの数が足りない場合、ソースLogstoreに対して複数のデータ変換タスクを作成し、タスクに重複しない変換期間を設定することができます。 たとえば、9月1日から9月10日までに生成された履歴ログデータを変換する必要がある場合、9つのタスクを作成して、
[9月1日、9月2日) 、[9月2日、9月3日) ... [9月9日、9月10日]の期間に生成されたデータを変換できます。説明 変換期間は、ログ受信時間に基づいて計算されます。 詳細については、「t947967.html#task_1181217」をご参照ください。
ターゲットLogstoreのデータ変換パフォーマンスの向上
- データ変換中の書き込み速度。 シャードの最大書き込み速度は5メガバイト/秒です。 ソースLogstore内のシャードの数と同時データ変換タスクの数に基づいて、特定の書き込み速度を見積もることができます。
たとえば、ソースLogstoreに20個のシャードがある場合、ターゲットLogstoreには少なくとも4個のシャードが必要です。
- 宛先Logstoreのデータを照会するためにインデックスを作成する必要があるかどうか。 ターゲットLogstoreのデータを照会するためにインデックスを作成する必要がある場合は、シャードのログエントリを50万個計画し、計画に基づいてシャードの数を指定することを推奨します。
例えば、1つのログエントリーが1KBで、毎日変換して書き込む必要があるログエントリーのサイズが10GBの場合、ログエントリーの数は1,000万個になります。30日間 (約300万件のログエントリ) のデータをクエリする必要がある場合は、宛先Logstoreに6つのシャードを作成することを推奨します。