バージョン: Latest-4.1

共有データ

このトピックでは、共有データクラスタに関するよくある質問への回答を提供します。

なぜテーブル作成が失敗するのですか？

BE ログ (be.INFO) を確認して、正確な原因を特定してください。一般的な原因には以下が含まれます：

オブジェクトストレージ設定の誤設定（例：aws_s3_path、endpoint、authentication）。
オブジェクトストレージサービスの不安定性や例外。

その他のエラー：

エラーメッセージ: "Error 1064 (HY000): Unexpected exception: Failed to create shards. INVALID_ARGUMENT: shard info cannot be empty"

原因: 自動バケット推論が使用されている際に、CN または BE ノードが稼働していない場合に発生します。この問題は v3.2 で修正されています。

なぜテーブル作成に時間がかかるのですか？

バケット数が多すぎる（特にパーティション化されたテーブルの場合）と、StarRocks は多くのタブレットを作成します。システムはオブジェクトストレージ内の各タブレットに対してタブレットメタデータファイルを書き込む必要があり、その高いレイテンシーが総作成時間を大幅に増加させる可能性があります。以下を検討してください：

バケット数を減らす。
BE 設定 create_tablet_worker_count を通じてタブレット作成スレッドプールサイズを増やす。
オブジェクトストレージでの高い書き込みレイテンシーを確認し、トラブルシューティングする。

なぜテーブルを削除した後もオブジェクトストレージ内のデータがクリーンアップされないのですか？

StarRocks は 2 つの DROP TABLE モードをサポートしています：

DROP TABLE xxx: テーブルメタデータを FE のリサイクルビンに移動します（データは削除されません）。
DROP TABLE xxx FORCE: テーブルメタデータとデータを即座に削除します。

クリーンアップが失敗した場合、以下を確認してください：

DROP TABLE xxx FORCE が使用されたかどうか。
リサイクルビンの保持パラメータが高すぎるかどうか。パラメータには以下が含まれます：
- FE 設定 catalog_trash_expire_second
- BE 設定 trash_file_expire_time_sec
削除エラーのための FE ログ（例：RPC タイムアウト）。必要に応じて RPC タイムアウトを増やします。

オブジェクトストレージ内のテーブルデータのストレージパスをどのように見つけることができますか？

以下のコマンドを実行してストレージパスを取得します。

SHOW PROC '/dbs/<database_name>';

例：

mysql> SHOW PROC '/dbs/load_benchmark';
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
| TableId | TableName   | IndexNum | PartitionColumnName | PartitionNum | State  | Type         | LastConsistencyCheckTime | ReplicaCount | PartitionType | StoragePath                                                                                                  |
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
| 17152   | store_sales | 1        | NULL                | 1            | NORMAL | CLOUD_NATIVE | NULL                     | 64           | UNPARTITIONED | s3://starrocks-common/xxxxxxxxx-xxxx_load_benchmark-1699408425544/5ce4ee2c-98ba-470c-afb3-8d0bf4795e48/17152 |
+---------+-------------+----------+---------------------+--------------+--------+--------------+--------------------------+--------------+---------------+--------------------------------------------------------------------------------------------------------------+
1 row in set (0.18 sec)

v3.1.4 より前のバージョンでは、テーブルデータは単一のディレクトリに散在しています。

v3.1.4 以降、データはパーティションごとに整理されます。同じコマンドがテーブルのルートパスを表示し、そこにはパーティション ID にちなんで名付けられたサブディレクトリが含まれ、各パーティションディレクトリには data/（セグメントデータファイル）と meta/（タブレットメタデータファイル）のサブディレクトリが含まれます。

なぜ共有データクラスタでクエリが遅いのですか？

一般的な原因には以下が含まれます：

キャッシュミス。
コンパクション不足により、小さなセグメントファイルが多すぎて過剰な I/O が発生する。
並行性の問題（例：タブレットが少なすぎる）。
不適切な datacache.partition_duration 設定により、キャッシュが失敗する。

まず、Query Profile を分析して根本原因を特定する必要があります。

キャッシュミス

共有データクラスタでは、データがリモートに保存されるため、Data Cache が重要です。クエリが予期せず遅くなった場合、CompressedBytesReadRemote や IOTimeRemote などの Query Profile メトリクスを確認してください。

キャッシュミスの原因には以下が含まれます：

テーブル作成時に Data Cache が無効化されている。
ローカルキャッシュスペースが不足している。
弾力的スケーリングによるタブレットの移動。
不適切な datacache.partition_duration 設定によりキャッシュが妨げられる。

コンパクション不足

適切なコンパクションが行われないと、多くの履歴データバージョンが残り、クエリ中にアクセスされるセグメントファイルの数が増加します。これにより I/O が増加し、クエリが遅くなります。

コンパクション不足を診断するには：

関連するパーティションの Compaction Score を確認します。

Compaction Score は約 10 以下に保たれるべきです。過度に高い Compaction Score はコンパクションの失敗を示すことがよくあります。
SegmentsReadCount などの Query Profile メトリクスを確認します。

セグメント数が多い場合、コンパクションが遅れているか、停止している可能性があります。

不適切なタブレット設定

タブレットはデータをコンピュートノードに分散します。バケットの選択が悪いか、バケットキーが偏っていると、クエリが一部のノードでのみ実行されることがあります。

推奨事項：

バランスの取れた分散を確保するバケット列を選択する。
適切なバケット数を設定する（式：total data size / (1–5 GB)）。

不適切な `datacache.partition_duration` 設定

この値が小さすぎると、「コールド」パーティションからのデータがキャッシュされず、リモート読み取りが繰り返される可能性があります。Query Profile で CompressedBytesReadRemote または IOCountRemote がゼロでない場合、これが原因かもしれません。datacache.partition_duration を適切に調整してください。

なぜ「Timeout was reached」や「Deadline Exceeded」などのエラーでウェアハウス内のすべてのクエリがタイムアウトするのですか？

ウェアハウス内のコンピュートノードがオブジェクトストレージのエンドポイントにアクセスできるかどうかを確認してください。

共有データクラスタでタブレットメタデータを取得するにはどうすればよいですか？

以下を実行して可視バージョンを取得します：
```
SHOW PARTITIONS FROM <table_name>`
```

以下のステートメントを実行してタブレットメタデータを取得します：

admin execute on <backend_id> 
'System.print(StorageEngine.get_lake_tablet_metadata_json(<tablet_id>, <version>))'

高頻度のインジェスション中にロードが遅いのはなぜですか？

StarRocks はトランザクションコミットを直列化するため、高いインジェスションレートが制限に達する可能性があります。

以下の側面を監視してください：

ロードキュー: ロードキューがいっぱいの場合、I/O ワーカースレッドを増やすことができます。
Publish Version レイテンシー: 高いパブリッシュ時間がインジェスションの遅延を引き起こします。

共有データクラスタでのコンパクションはどのように機能し、なぜスタックするのですか？

主な動作には以下が含まれます：

コンパクションは FE によってスケジュールされ、CN によって実行されます。
各コンパクションは新しいバージョンを生成し、書き込み、コミット、パブリッシュのプロセスを経ます。
FE は実行中のコンパクションタスクを追跡しません。BE 上の古いタスクが新しいタスクをブロックする可能性があります。

スタックしたコンパクションタスクをクリーンアップするには、以下の手順に従います：

パーティションのバージョン情報を確認し、CompactVersion と VisibleVersion を比較します。
```
SHOW PARTITIONS FROM <table_name>
```

コンパクションタスクのステータスを確認します。

SHOW PROC '/compactions'

SELECT * FROM information_schema.be_cloud_native_compactions WHERE TXN_ID = <TxnID>

期限切れのタスクをキャンセルします。

a. コンパクションと移行を無効にします。

ADMIN SET FRONTEND CONFIG ("lake_compaction_max_tasks" = "0");
ADMIN SET FRONTEND CONFIG ('tablet_sched_disable_balance' = 'true');
ADMIN SHOW FRONTEND CONFIG LIKE 'lake_compaction_max_tasks';
ADMIN SHOW FRONTEND CONFIG LIKE 'tablet_sched_disable_balance';

b. すべての BE ノードを再起動します。

c. すべてのコンパクションが失敗したことを確認します。

SHOW PROC '/compactions'

d. コンパクションと移行を再有効化します。

ADMIN SET FRONTEND CONFIG ("lake_compaction_max_tasks" = "-1");
ADMIN SET FRONTEND CONFIG ('tablet_sched_disable_balance' = 'false');
ADMIN SHOW FRONTEND CONFIG LIKE 'lake_compaction_max_tasks';
ADMIN SHOW FRONTEND CONFIG LIKE 'tablet_sched_disable_balance';

なぜ Kubernetes 共有データクラスタでコンパクションが遅いのですか？

インジェスションがあるウェアハウスで行われ、コンパクションが別のウェアハウス（例：default_warehouse）で実行される場合、コンパクションはキャッシュなしでウェアハウス間でデータを取得する必要があり、これが遅くなる原因です。

解決策：

BE 設定 lake_enable_vertical_compaction_fill_data_cache を true に設定します。
コンパクションと同じウェアハウスで書き込みを行います。

なぜ共有データクラスタでストレージ使用量が膨張しているように見えるのですか？

オブジェクトストレージ上のストレージ使用量にはすべての履歴バージョンが含まれますが、SHOW DATA の出力は最新バージョンのみを反映します。

しかし、差が過度に大きい場合、以下の問題が原因である可能性があります：

コンパクションが遅れている可能性があります。
Vacuum タスクが滞っている可能性があります（キューサイズを確認してください）。

必要に応じてコンパクションや Vacuum スレッドプールを調整することを検討してください。

なぜ大きなクエリが「meta does not exist」で失敗するのですか？

クエリがすでにコンパクト化され、Vacuum されたデータバージョンを使用している可能性があります。

これを解決するには、FE 設定 lake_autovacuum_grace_period_minutes を変更してファイル保持を増やし、クエリを再試行してください。

オブジェクトストレージに小さなファイルが過剰に存在する原因は何ですか？

小さなファイルの過剰な数はパフォーマンスの低下を引き起こす可能性があります。一般的な原因には以下が含まれます：

不適切なバケット設定によるバケット数の過剰。
高頻度のインジェスションにより非常に小さな個別のロードが発生する。

コンパクションは最終的に小さなファイルをマージしますが、バケット数の調整とインジェスションのバッチ処理はパフォーマンスの低下を防ぐのに役立ちます。

なぜテーブル作成が失敗するのですか？​

なぜテーブル作成に時間がかかるのですか？​

なぜテーブルを削除した後もオブジェクトストレージ内のデータがクリーンアップされないのですか？​

オブジェクトストレージ内のテーブルデータのストレージパスをどのように見つけることができますか？​

なぜ共有データクラスタでクエリが遅いのですか？​

キャッシュミス​

コンパクション不足​

不適切なタブレット設定​

不適切な datacache.partition_duration 設定​

なぜ「Timeout was reached」や「Deadline Exceeded」などのエラーでウェアハウス内のすべてのクエリがタイムアウトするのですか？​

共有データクラスタでタブレットメタデータを取得するにはどうすればよいですか？​

高頻度のインジェスション中にロードが遅いのはなぜですか？​

共有データクラスタでのコンパクションはどのように機能し、なぜスタックするのですか？​

なぜ Kubernetes 共有データクラスタでコンパクションが遅いのですか？​

なぜ共有データクラスタでストレージ使用量が膨張しているように見えるのですか？​

なぜ大きなクエリが「meta does not exist」で失敗するのですか？​

オブジェクトストレージに小さなファイルが過剰に存在する原因は何ですか？​

このドキュメントについてどう思いましたか？