ロードのベストプラクティス

テーブルモデルの選択

データロードとクエリパフォーマンスの両方で他のモデルと比較して利点を提供するDuplicate Keyモデルの使用を優先することを推奨します。詳細については、以下を参照してください：Data Model

パーティションとBucket設定

tabletのサイズは1-10GBの間に保つことを推奨します。tabletが小さすぎると集約パフォーマンスが低下し、メタデータ管理のオーバーヘッドが増加する可能性があります。tabletが大きすぎるとレプリカの移行と修復が阻害される可能性があります。詳細については、以下を参照してください：Data Distribution。

Random Bucketing

Random bucketingを使用する際は、load_to_single_tabletをtrueに設定することでシングルタブレットロードモードを有効にできます。このモードは大規模データロード時にデータロードの並行性とスループットを向上させ、書き込み増幅を削減できます。詳細については、以下を参照してください：Random Bucketing

バッチロード

クライアント側バッチ処理：ロード前にクライアント側でデータをバッチ処理（数MBからGBサイズ）することを推奨します。高頻度の小さなロードは頻繁なcompactionを引き起こし、深刻な書き込み増幅の問題を引き起こします。 サーバー側バッチ処理：高並行性の小データ量ロードについては、サーバー側でバッチ処理を実装するためにGroup Commitを有効にすることを推奨します。

パーティションロード

一度に少数のパーティションからのみデータをロードすることを推奨します。同時に多くのパーティションからロードするとメモリ使用量が増加し、パフォーマンスの問題を引き起こす可能性があります。Dorisの各tabletはメモリにアクティブなMemtableを持ち、一定サイズに達するとディスクにフラッシュされます。プロセスOOMを防ぐため、アクティブなMemtableのメモリ使用量が高すぎる場合、早期フラッシュがトリガーされ、多数の小さなファイルが生成されてロードパフォーマンスに影響します。

大規模データバッチロード

大量のファイルや大きなデータ量を扱う際は、ロード失敗時の高い再試行コストを避け、システムリソースへの影響を削減するためにバッチでロードすることを推奨します。Broker Loadについては、バッチあたり100GBを超えないことを推奨します。大きなローカルデータファイルについては、自動的にバッチロードを実行するDorisのstreamloaderツールを使用できます。

Broker Load並行性

圧縮ファイル/Parquet/ORCファイル：より高い並行性を実現するため、ファイルを複数の小さなファイルに分割してロードすることを推奨します。

非圧縮CSVおよびJSONファイル：Dorisは自動的にファイルを分割し、並行してロードします。

並行性戦略については、以下を参照してください：Broker Load Configuration Parameters

Stream Load並行性

BE当たりのStream load並行性を128以下に保つことを推奨します（BEのwebserver_num_workersパラメータで制御）。高い並行性はwebserverスレッドの枯渇を引き起こし、ロードパフォーマンスに影響する可能性があります。特に単一BEの並行性が512を超える場合（doris_max_remote_scanner_thread_pool_thread_numパラメータ）、BEプロセスがハングする可能性があります。