このトピックでは、StarRocks についてよく寄せられる質問への回答を提供します。
ビジネス テストと評価
購入
使用方法
StarRocks のハードウェアリソース要件
マシン構成
バックエンド (BE) ノードのサーバーには、少なくとも 16 個の CPU コアと 64 GB のメモリを搭載し、フロントエンド (FE) ノードのサーバーには、少なくとも 8 個の CPU コアと 16 GB のメモリを搭載することをお勧めします。
ほとんどの場合、本番環境の FE ノードのサーバーには、16 個の CPU コア、32 GB または 64 GB のメモリ、および 200 GB から 500 GB のメモリを搭載した NVMe ディスクが搭載されています。
ディスク
HDD と SSD を使用できます。
ディスク容量は、圧縮率が 3 で、ディスク使用率が 70% から 75% であるという条件に基づいて見積もることができます。
Parquet 形式または ORC 形式の Hive データを StarRocks にインポートする場合は、1:1 の圧縮率に基づいてディスク容量を見積もります。
たとえば、インポートする Hive データのサイズが 3 TB の場合、StarRocks にインポートされるデータのサイズは 3 TB です。
CPU
CPU は、Advanced Vector Extensions 2 (AVX2) 命令セットをサポートしている必要があります。
cat /proc/cpuinfo |grep avx2コマンドを実行して、AVX2 命令セットがサポートされているかどうかを確認できます。完全にベクトル化された実行エンジンは、CPU に命令セットが搭載されている場合、CPU 処理能力をより効率的に使用します。サポートされていない場合は、サーバーを変更することをお勧めします。
ネットワーク
10GE ネットワークインターフェースコントローラ (NIC) と 10GE スイッチを選択することをお勧めします。
StarRocks のソフトウェア構成要件
詳細については、「パラメータ構成」をご参照ください。
本番環境で指定する必要があるレプリカの数
ほとんどの場合、本番環境では 2 つまたは 3 つのレプリカが必要です。3 つのレプリカを指定することをお勧めします。
テーブルのパーティション数を決定する方法
適切なパーティションを設定すると、スキャンされるデータ量を効果的に削減できます。
ほとんどの場合、ビジネス要件に基づいてパーティションキーを選択できます。たとえば、時間またはリージョンの列をパーティションキーとして選択できます。
パーティションを自動的に作成する必要がある場合は、動的パーティション化を有効にできます。
タブレットの数を決定する方法
カーディナリティの高い列をバケットキーとして選択して、タブレット間のデータスキューを防ぐことができます。
一意の ID 列が存在する場合は、一意の ID 列をバケットキーとして選択することをお勧めします。
1 つのバケット列を使用してデータを各タブレットに均等に分散できない場合は、複数の列をバケットキーとして選択できます。ただし、過剰な数の列をバケットキーとして使用しないでください。
次の情報に基づいて、タブレットの最適なサイズを見積もることができます。タブレットの数は、次の項目とデータ総量に基づいて計算できます。
CSV 形式のデータなどの生データの場合、タブレットのサイズは 1 GB から 10 GB の範囲です。
Parquet 形式のデータの場合、タブレットのサイズは約 1 GB です。
マシンリソースを最大限に活用するには、次の式を使用してタブレットの数を計算します。
BE ノードの数 × CPU コア数 / 2。
ソートキーを決定する方法
ソートキーは、データクエリの特性に基づいて設計する必要があります。
フィルター条件や GROUP BY 句で頻繁に使用される列をソートキーとして選択して、クエリを高速化できます。
ポイントクエリが多数実行される場合は、ポイントクエリの ID 列をソートキー列の最初の列として設定します。
たとえば、クエリ文が
select sum(revenue) from lineorder where user_id='aaa100';で、高い同時実行性が発生する場合は、user_id列をソートキー列の最初の列として設定することをお勧めします。集計クエリとスキャンが主に実行される場合は、カーディナリティの低い列を最初に設定することをお勧めします。
たとえば、クエリ文が
select region, nation, count(*) from lineorder_flat group by region, nationの場合は、region列を最初の列として、nation列を 2 番目の列として指定することをお勧めします。
適切なデータ型を選択する方法
精度の高いデータ型を選択することをお勧めします。たとえば、文字列データ型ではなく整数データ型を選択し、BIGINT データ型ではなく INT データ型を選択します。精度の高いデータ型を使用すると、データベースのパフォーマンスを最大限に活用できます。
Routine Load インポート方式でパフォーマンスの問題が発生した場合にパラメータチューニングを実行する方法
パラメーター調整ポリシー
Routine Load インポート方式でパフォーマンスの問題が発生した場合、次のディメンションからパラメーター調整を実行できます。
ジョブのスケジューリングサイクル
max_batch_interval パラメーターを変更して、スケジューリングサイクルを短縮し、データ消費を高速化できます。ただし、スケジューリングサイクルを短縮すると、より多くの CPU リソースが消費される可能性があります。
重要最小スケジューリングサイクルは 5 秒です。
ジョブの並列処理
多数のパーティションと BE ノードが関係している場合、次のパラメーターを設定してジョブの実行を高速化できます。ただし、並列処理の次数 (DOP) を増やすと、より多くの CPU リソースが消費される可能性があります。
max_routine_load_task_concurrent_num
desired_concurrent_number
Routine Load ジョブは、Kafka Topic のパーティション数に基づいて複数のタスクに分割され、BE ノード数に基づいて複数 BE ノードに分散されて実行されます。ジョブの DOP とは、Routine Load ジョブが分割されるタスク数を指します。
次の数式を使用して、ジョブの DOP を計算できます。
concurrent_num = Min( Min( partition_num, Min( desired_concurrent_num, alive_be_num ) ),Config.max_routine_load_task_concurrent_num )インポートバッチサイズ
routine_load_task_consume_second: 読み取り操作の時間を増やすことで、データ消費を高速化できます。
max_routine_load_batch_size: 読み取り操作のデータ量を増やすことで、データ消費を高速化できます。
次のログを使用して、max_routine_load_batch_size パラメーターが低い値に設定されているかどうかを判断できます。ログの
left_bytesフィールドの値は 0 以上である必要があります。これは、一度に読み取られるデータ量が max_routine_load_batch_size パラメーターの値を超えないことを示します。そうでない場合、max_routine_load_batch_size パラメーターは低い値に設定されています。I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done: 41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190, received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking get time(us): 3065086, blocking put time(us): 24855 1
パラメータチューニングポリシー
パラメーター | タイプ | デフォルト値 | 説明 |
max_routine_load_job_num | fe.conf | 100 | NEED_SCHEDULE、RUNNING、または PAUSED 状態のルーティングロードジョブの最大数。 |
max_routine_load_task_concurrent_num | fe.conf | 5 | ルーティングロードジョブの最大 DOP。 |
max_routine_load_task_num_per_be | fe.conf | 5 | 1 つの BE ノードに割り当てることができるルーティングロードジョブの最大数。 |
max_routine_load_batch_size | fe.conf | 500 MB | Kafka から一度に読み取ることができるデータの最大量。 |
routine_load_task_consume_second | fe.conf | 3 | Kafka から一度にデータを読み取るために使用される最大期間。 |
routine_load_task_timeout_second | fe.conf | 15 | ルーティングロードジョブを実行できるタイムアウト期間。 |
max_consumer_num_per_group | be.conf | 3 | コンシューマーグループのコンシューマーの最大数。 |
desired_concurrent_number | properties | 3 | ルーティングロードジョブの想定 DOP。実際の DOP は、次の式に基づいて計算されます。 |
max_batch_interval | properties | 10s | ルーティングロードジョブのスケジューリングサイクル。 |
max_batch_rows | properties | 200000 | このパラメーターは、エラー検出ウィンドウの範囲を指定するためにのみ使用されます。ウィンドウの範囲は、このパラメーターの値に 10 を掛けて計算されます。 |
max_error_number | properties | 0 | サンプリングウィンドウで許可されるエラー行の最大数。値は 0 以上である必要があります。デフォルト値 0 は、エラー行が許可されないことを指定します。 重要 エラー行には、WHERE 句によって除外された行は含まれません。 |
strict_mode | properties | true | 厳密モードを有効にするかどうかを指定します。デフォルトでは、厳密モードが有効になっています。厳密モードを有効にした後、生データの列が NOT NULL から NULL に変更された場合、データは除外されます。 |
データモデルを選択するにはどうすればよいですか?
StarRocks は、次の 4 つのデータモデルを提供しています。ビジネス要件に基づいてデータモデルを選択できます。
データモデル | シナリオ |
duplicate key |
|
Aggregate key モデル |
|
uniq key | リアルタイム分析のためにデータが更新されます。 |
primary key | リアルタイム分析のためにデータが更新されます。 一部の列が更新される場合、更新される列の数は 200 以内にすることをお勧めします。 |
さまざまな StarRocks データモデルにおける COUNT 関数の動作
StarRocks には、複製キー、一意キー、集計キー、プライマリキーの 4 つのデータモデルがあります。COUNT 関数の動作は、データモデルによって異なります。次の項目で違いについて説明します。
複製キーモデル: このデータモデルではマージ操作が不要なため、COUNT 関数の結果は迅速に返されます。
一意キーモデルと集計キーモデル: これらの 2 つのデータモデルでは、複数のバージョンのデータに対してマージ操作が必要になるため、COUNT 関数の結果は複製キーモデルの場合よりも遅く返されます。
理論的には、キー列の型が STRING の場合、COUNT 関数の結果はより遅く返されます。
プライマリキーモデル: このデータモデルは、プライマリキーインデックスと、データの読み取り時のベクターに対する削除操作をサポートしています。このモデルではマージ操作は不要です。そのため、COUNT 関数の結果は、一意キーモデルと集計キーモデルの場合よりも速く返されます。
データに更新操作が含まれる場合は、プライマリキーモデルを選択することをお勧めします。
/mnt/disk1/starrocks/storage/trash/ ディレクトリのディスク使用量を削減するにはどうすればよいですか?
削除されたデータは /mnt/disk1/starrocks/storage/trash/ ディレクトリに保存されます。このディレクトリのディスク使用量を削減するには、be.conf ファイルの trash_file_expire_time_sec パラメーターの値を小さくして、trash ディレクトリの保存期間を短縮します。デフォルトの保存期間は 259,200 秒(72 時間)です。
マテリアライズドビューの作成時にエラーが発生した場合はどうすればよいですか?
問題の説明: 次の図は、エラーメッセージを示しています。
解決策:
次の文を実行します:
show proc "/cluster_balance";およびshow proc "/statistic";。タブレットが再調整されているかどうかを確認します。
はいの場合、実行が完了するまで待ちます。
いいえの場合、
set disable_balance=true文を実行し、マテリアライズドビューを作成できます。
低速のデータクエリが発生した場合の対処方法
次のソリューションを使用することをお勧めします。
プロファイルレポートを有効にして、StarRocks ユーザーインターフェース (UI) でプロファイル情報を表示します。
SET is_report_success = true;文を実行して、プロファイルレポートを有効にできます。一般的なトラブルシューティング方法:
並列度を調整します。
パイプライン
SET pipeline_dop = 8; SET enable_pipeline_engine = true;非パイプラインエンジン
SET enable_pipeline_engine=false; SET parallel_fragment_exec_instance_num=8;
タブレットのデータ分布を表示します。
show data xxx;説明推奨されるタブレットのサイズは 1 ~ 10 GB です。
作成されたテーブルを表示します。
プロファイル情報に基づいて I/O 待機時間を判断できます。待機時間が長い場合は、頻繁に作成されるビットマップインデックスなど、不要なインデックスを削除できます。
テーブルデータモデルを表示し、適切なデータモデルを選択します。たとえば、一意キーモデルでは、コンパクションフェーズが完了する前はプッシュダウンが機能しません。これが原因でクエリが遅くなります。
ポート 8030 またはポート 8040 を使用して StarRocks クラスタにアクセスできないのはなぜですか?
E-MapReduce (EMR) V5.8.0、EMR V3.42.0、または EMR V5.8.0 または EMR V3.42.0 より前のマイナーバージョンの StarRocks クラスタの場合、load_url のポート番号は 8030 で、webserver_port のポート番号は 8040 です。ただし、EMR V5.9.0 以降のマイナーバージョン、または EMR V3.43.0 以降のマイナーバージョンの StarRocks クラスタの場合、load_url のポート番号は 18030 で、webserver_port のポート番号は 18040 です。クラスタのバージョンに基づいて、StarRocks クラスタへのアクセスに使用するポートを選択する必要があります。
show frontends コマンドを実行して、StarRocks クラスタの実際のポート番号を確認できます。
EMR StarRocks はどのリージョンで利用できますか?
StarRocks はすべてのリージョンで利用できます。
StarRocks は BE ノードのデータディスクにどのようにデータを分散しますか?
デフォルトでは、各 BE ノードに 4 つの PL1 拡張 SSD が構成されています。StarRocks は、負荷とバケットメカニズムに基づいて、BE ノードに均等にデータを分散します。同じタブレットおよびレプリカ内のデータは、同じディスクに保存されます。
データ例外が発生した場合、クラスタをリセットするにはどうすればよいですか?
以下の操作を実行すると、クラスタデータが消去されます。 慎重に行ってください。
FE ノードと BE ノードにデプロイされているサービスを停止します。
FE ノードのメタデータが格納されているディレクトリをクリアします。
/opt/apps/STARROCKS/starrocks-current/fe/conf/ディレクトリにある fe.conf ファイルを表示し、meta_dirの構成ディレクトリを取得します。構成ディレクトリから bdb フォルダを削除します。
構成ディレクトリ内のイメージフォルダをクリアします。
BE データとメタデータをクリアします。
/opt/apps/STARROCKS/starrocks-current/be/conf/ディレクトリにある be.conf ファイルを表示し、storage_root_pathの構成ディレクトリを取得します。構成ディレクトリから、data フォルダと meta フォルダを除くすべてのフォルダとファイルを削除します。
構成ディレクトリ内の data フォルダと meta フォルダをクリアします。
説明構成ディレクトリは複数のパスに存在する場合があります。 各パスに対して上記の操作を実行する必要があります。
FE ノードと BE ノードにデプロイされているサービスを再起動します。
FE ノードと BE ノードのログを表示するにはどうすればよいですか?
FE ノードと BE ノードのログは、次のディレクトリに保存されます。
FE ノード
/opt/apps/STARROCKS/starrocks-current/fe/log/
/mnt/disk1/log/starrocks/
BE ノード
/opt/apps/STARROCKS/starrocks-current/be/log/
/mnt/disk1/log/starrocks/
タスクノードを StarRocks クラスターに追加した後、ノードがタスクの実行に使用されません。なぜですか?
問題の説明
3 つのタスクノードを計算ノード(CN)として StarRocks クラスターに追加した後、追加されたノードがタスクの実行に使用されません。BE ノードのワークロードは高いです。ただし、新しく追加されたタスクノードは十分に活用されておらず、モニタリングデータはタスクノードのワークロードが低いことを示しています。
原因
コンピューティングストレージ統合アーキテクチャを採用している StarRocks クラスターの場合、CN ノードは外部テーブルからのデータのクエリにのみ使用できます。内部テーブルのデータをクエリするシナリオでは、常に BE ノードが使用されます。その結果、新しく追加されたタスクノードは十分に活用されません。
解決策
クエリタスクを実行する前に、次の SQL 文を実行して、タスクが CN で優先的に実行されるようにします。
SET GLOBAL prefer_compute_node=true;StarRocks クラスタのパスワードを表示するにはどうすればよいですか。
StarRocks クラスタのパスワードとは、StarRocks クラスタの作成時にルートユーザーに設定したパスワードのことです。パスワードを忘れた場合は、パスワードをリセットできます。詳細については、「クラスタにログオンする」トピックの パスワードをリセットするにはどうすればよいですか。 セクションをご参照ください。