プロパティリファレンス¶

このセクションでは、Prestoの調整や、必要に応じてその動作を変更するために使用できる最も重要な設定プロパティについて説明します。

以下のページは、Prestoで利用可能なすべての設定およびセッションプロパティの完全なリストではなく、コネクタ固有のカタログ設定プロパティは含まれていません。カタログ設定プロパティの詳細については、コネクタドキュメントを参照してください。

一般的なプロパティ¶

join-distribution-type¶

• タイプ: string

• 使用可能な値: AUTOMATIC、PARTITIONED、BROADCAST

• デフォルト値: AUTOMATIC

使用する分散結合のタイプ。 PARTITIONED に設定すると、Prestoはハッシュ分散結合を使用します。 BROADCAST に設定すると、左側のテーブルのデータを持つクラスター内のすべてのノードに右側のテーブルをブロードキャストします。パーティション結合では、結合キーのハッシュを使用して両方のテーブルを再配布する必要があります。これはブロードキャスト結合よりも遅くなる可能性があります（場合によっては大幅に遅くなる可能性があります）が、はるかに大きな結合を可能にします。特に、右側のテーブルが左側のテーブルよりもはるかに小さい場合、ブロードキャスト結合の方が高速になります。ただし、ブロードキャスト結合では、フィルタリング後の結合の右側のテーブルが各ノードのメモリに収まる必要がありますが、分散結合では、すべてのノードの分散メモリに収まるだけで済みます。 AUTOMATIC に設定すると、Prestoはどの分散タイプが最適かについてコストに基づいた決定を下します。また、結合の左側と右側の入力を切り替えることも検討します。 AUTOMATIC モードでは、テーブルに統計がない場合など、コストを計算できない場合、Prestoはデフォルトでハッシュ分散結合を使用します。これは、 join_distribution_type セッションプロパティを使用して、クエリごとに指定することもできます。

redistribute-writes¶

• タイプ: boolean

• デフォルト値: true

このプロパティは、書き込み前にデータの再配布を有効にします。これにより、クラスター内のノード間でハッシュすることで、書き込み時のデータの偏りによるパフォーマンスへの影響を排除できます。ネットワーク全体でデータをハッシュして再配布するオーバーヘッドを回避するために、出力データセットが偏っていないことがわかっている場合は無効にできます。これは、 redistribute_writes セッションプロパティを使用して、クエリごとに指定することもできます。

メモリ管理プロパティ¶

query.max-memory-per-node¶

• タイプ: data size

• デフォルト値: JVM 最大メモリ * 0.1

これは、ワーカー上でクエリが使用できるユーザーメモリの最大量です。ユーザーメモリは、ユーザーのクエリに直接起因する、またはユーザーのクエリによって制御可能なものに対して、実行中に割り当てられます。たとえば、実行中に構築されたハッシュテーブルで使用されるメモリ、ソート中に使用されるメモリなどです。いずれかのワーカー上でクエリのユーザーメモリ割り当てがこの制限に達すると、そのクエリは強制終了されます。

query.max-total-memory-per-node¶

• タイプ: data size

• デフォルト値: query.max-memory-per-node * 2

これは、ワーカー上でクエリが使用できるユーザーメモリとシステムメモリの最大量です。システムメモリは、ユーザーのクエリに直接起因しない、またはユーザーのクエリによって制御できないものに対して、実行中に割り当てられます。たとえば、リーダー、ライター、ネットワークバッファなどによって割り当てられるメモリです。いずれかのワーカー上でクエリによって割り当てられたユーザーメモリとシステムメモリの合計がこの制限に達すると、そのクエリは強制終了されます。query.max-total-memory-per-node の値は、query.max-memory-per-node の値より大きくなければなりません。

query.max-memory¶

• タイプ: data size

• デフォルト値: 20GB

これは、クラスタ全体でクエリが使用できるユーザーメモリの最大量です。ユーザーメモリは、ユーザーのクエリに直接起因する、またはユーザーのクエリによって制御可能なものに対して、実行中に割り当てられます。たとえば、実行中に構築されたハッシュテーブルで使用されるメモリ、ソート中に使用されるメモリなどです。すべてのワーカーにわたるクエリのユーザーメモリ割り当てがこの制限に達すると、そのクエリは強制終了されます。

query.max-total-memory¶

• タイプ: data size

• デフォルト値: query.max-memory * 2

これは、クラスタ全体でクエリが使用できるユーザーメモリとシステムメモリの最大量です。システムメモリは、ユーザーのクエリに直接起因しない、またはユーザーのクエリによって制御できないものに対して、実行中に割り当てられます。たとえば、リーダー、ライター、ネットワークバッファなどによって割り当てられるメモリです。すべてのワーカーにわたるクエリによって割り当てられたユーザーメモリとシステムメモリの合計がこの制限に達すると、そのクエリは強制終了されます。query.max-total-memory の値は、query.max-memory の値より大きくなければなりません。

memory.heap-headroom-per-node¶

• タイプ: data size

• デフォルト値: JVM max memory * 0.3

これは、Prestoによって追跡されない割り当てのために、JVMヒープにヘッドルーム/バッファとして確保されるメモリ量です。

query.low-memory-killer.policy¶

• タイプ: string

• デフォルト値: none

クラスタがメモリ不足（OOM）になった場合に強制終了するクエリを選択するために使用されるポリシーです。このプロパティには、none、total-reservation、またはtotal-reservation-on-blocked-nodesのいずれかの値を設定できます。noneは、クラスタOOMキラーを無効にします。total-reservationの値は、クラスタ全体で最大のメモリ予約を持つクエリを強制終了するポリシーを構成します。total-reservation-on-blocked-nodesの値は、メモリ不足（ブロックされている）のワーカーで最も多くのメモリを使用しているクエリを強制終了するポリシーを構成します。

スピルプロパティ¶

experimental.spill-enabled¶

• タイプ: boolean

• デフォルト値: false

クエリのメモリ制限を超えないように、メモリをディスクにスピルしようとします。

スピルは、メモリをディスクにオフロードすることで機能します。このプロセスにより、大きなメモリフットプリントを持つクエリは、実行時間が遅くなるという犠牲を払って実行できます。現在、スピルは集計と結合（内部および外部）でのみサポートされているため、このプロパティはウィンドウ関数、ソート、その他の結合タイプに必要なメモリ使用量を削減しません。

これは実験的な機能であり、慎重に使用する必要があることに注意してください。

この構成プロパティは、spill_enabledセッションプロパティでオーバーライドできます。

experimental.join-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、結合のためにメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、join_spill_enabledセッションプロパティでオーバーライドできます。

experimental.aggregation-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、集計のためにメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、aggregation_spill_enabledセッションプロパティでオーバーライドできます。

experimental.distinct-aggregation-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

aggregation_spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、一意な集計のためにメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、distinct_aggregation_spill_enabledセッションプロパティでオーバーライドできます。

experimental.order-by-aggregation-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

aggregation_spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、order by集計のためにメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、order_by_aggregation_spill_enabledセッションプロパティでオーバーライドできます。

experimental.window-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、ウィンドウ関数に対してメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、window_spill_enabledセッションプロパティでオーバーライドできます。

experimental.order-by-spill-enabled¶

• タイプ: boolean

• デフォルト値: true

spill_enabledがtrueの場合、これはPrestoがクエリのメモリ制限を超えないように、order byに対してメモリをディスクにスピルしようとするかどうかを決定します。

この構成プロパティは、order_by_spill_enabledセッションプロパティでオーバーライドできます。

experimental.spiller.task-spilling-strategy¶

• タイプ: string

• 許可される値: ORDER_BY_CREATE_TIME、ORDER_BY_REVOCABLE_BYTES、PER_TASK_MEMORY_THRESHOLD

• デフォルト値: ORDER_BY_CREATE_TIME

メモリをいつ破棄するか、どのタスクから破棄するかを選択するために使用する戦略を決定します。

ORDER_BY_CREATE_TIMEとORDER_BY_REVOCABLE_BYTESは、メモリプールがexperimental.memory-revoking-thresholdを超えて満たされた場合に、メモリプールの使用量がexperimental.memory-revoking-targetを下回るまでスピルをトリガーします。ORDER_BY_CREATE_TIMEは古いタスクから最初に破棄をトリガーし、ORDER_BY_REVOCABLE_BYTESはより多くの破棄可能なメモリを使用しているタスクから最初に破棄をトリガーします。

PER_TASK_MEMORY_THRESHOLDは、タスクによって使用される破棄可能なメモリがexperimental.spiller.max-revocable-task-memoryを超えた場合に常にスピルをトリガーします。

experimental.memory-revoking-threshold¶

• タイプ: double

• 最小値: 0

• 最大値: 1

• デフォルト値: 0.9

メモリプールがこのパーセンテージを超えて満たされた場合に、メモリの取り消しをトリガーします。

experimental.memory-revoking-target¶

• タイプ: double

• 最小値: 0

• 最大値: 1

• デフォルト値: 0.5

メモリを取り消す際、メモリプールが最終的にターゲットのパーセンテージを下回るまで十分に取り消そうとします。

experimental.query-limit-spill-enabled¶

• タイプ: boolean

• デフォルト値: false

スピルが有効で、experimental.spiller.task-spilling-strategy が ORDER_BY_CREATE_TIME または ORDER_BY_REVOCABLE_BYTES の場合、クエリの取り消し可能、ユーザー、およびシステムメモリの合計が query_max_total_memory_per_node を超えるたびに、クエリから取り消し可能なメモリもスピルします。これにより、利用可能なメモリの効率は低下しますが、クラスターの負荷に関係なく、クエリのパフォーマンスの一貫性を高めることができます。

experimental.spiller.max-revocable-task-memory¶

• タイプ: data size

• デフォルト値: 500MB

experimental.spiller.task-spilling-strategy が PER_TASK_MEMORY_THRESHOLD に設定されている場合、このプロパティはタスクのスピルをトリガーするしきい値を定義します。このプロパティは、他のスピル戦略では無視されます。

experimental.max-revocable-memory-per-node¶

• タイプ: data size

• デフォルト値: 16GB

このプロパティは、クエリが各ノードで使用できる取り消し可能なメモリの量を定義します。

experimental.spiller-spill-path¶

• タイプ: string

• デフォルト値はありません。 スピルを有効にする場合は設定する必要があります。

スピルされたコンテンツが書き込まれるディレクトリ。システムにインストールされた複数のドライブを活用するために、コンマ区切りのリストとして複数のディレクトリに同時にスピルできます。

システムドライブへのスピルは推奨されません。最も重要なことは、JVMログが書き込まれるドライブにスピルしないでください。ディスクの過剰使用により、JVMが長時間停止し、クエリが失敗する可能性があります。

experimental.spiller-max-used-space-threshold¶

• タイプ: double

• デフォルト値: 0.9

特定のスピルパスのディスクスペース使用率がこのしきい値を超えている場合、このスピルパスはスピルの対象にはなりません。

experimental.spiller-threads¶

• タイプ: integer

• デフォルト値: 4

スピラーのスレッド数。デフォルト値が、基盤となるスピルデバイスを飽和させることができない場合（たとえば、RAIDを使用している場合）、この値を増やしてください。

experimental.max-spill-per-node¶

• タイプ: data size

• デフォルト値: 100 GB

単一ノード上のすべてのクエリで使用される最大スピルスペース。

experimental.query-max-spill-per-node¶

• タイプ: data size

• デフォルト値: 100 GB

単一ノード上の単一クエリで使用される最大スピルスペース。

experimental.aggregation-operator-unspill-memory-limit¶

• タイプ: data size

• デフォルト値: 4 MB

単一の集計演算子インスタンスのアンピルに使用されるメモリの制限。この設定プロパティは、aggregation_operator_unspill_memory_limit セッションプロパティで上書きできます。

experimental.spill-compression-enabled¶

• タイプ: boolean

• デフォルト値: false

ディスクにスピルされたページに対してデータ圧縮を有効にします。

experimental.spill-encryption-enabled¶

• タイプ: boolean

• デフォルト値: false

ディスクにスピルされたデータを暗号化および復号化するために、ランダムに生成された秘密鍵（スピルファイルごと）を使用することを有効にします。

experimental.spiller.single-stream-spiller-choice¶

• タイプ: String

• デフォルト値: LOCAL_FILE

スピルが有効になっている場合に使用されるシングルストリームスピラー。LOCAL_FILE（デフォルト）とTEMP_STORAGEの2つのオプションがあります。

experimental.spiller.spiller-temp-storage¶

• タイプ: String

• デフォルト値: local

experimental.spiller.single-stream-spiller-choice が TEMP_STORAGE に設定されている場合、スピラーが使用する一時ストレージ。

experimental.temp-storage-buffer-size¶

• タイプ: Data Size

• デフォルト値: 4KB

experimental.spiller.single-stream-spiller-choice が TEMP_STORAGE に設定されている場合、バッファーのサイズ。

Exchange プロパティ¶

Exchanges は、クエリのさまざまなステージで Presto ノード間でデータを転送します。これらのプロパティを調整すると、ノード間の通信問題を解決したり、ネットワーク利用率を向上させたりするのに役立つ場合があります。

exchange.client-threads¶

• タイプ: integer

• 最小値: 1

• デフォルト値: 25

Exchangeクライアントが他のPrestoノードからデータをフェッチするために使用するスレッド数。値を大きくすると、大規模なクラスターや非常に高い同時実行性を備えたクラスターのパフォーマンスが向上する可能性がありますが、値が過度に大きいと、コンテキストスイッチや追加のメモリ使用量によりパフォーマンスが低下する可能性があります。

exchange.concurrent-request-multiplier¶

• タイプ: integer

• 最小値: 1

• デフォルト値: 3

利用可能なバッファメモリに対する同時リクエスト数を決定する乗数。リクエストの最大数は、リクエストあたりの平均バッファ使用量にこの乗数を掛けた、利用可能なバッファスペースに収まるクライアントの数に基づいてヒューリスティックを使用して決定されます。たとえば、exchange.max-buffer-size が 32 MB で、すでに 20 MB が使用されており、リクエストあたりの平均サイズが 2MB の場合、クライアントの最大数は 乗数 * ((32MB - 20MB) / 2MB) = 乗数 * 6 になります。この値を調整するとヒューリスティックが調整され、同時実行性が向上し、ネットワーク利用率が向上する可能性があります。

exchange.max-buffer-size¶

• タイプ: data size

• デフォルト値: 32MB

処理される前に他のノードからフェッチされたデータを保持する、exchangeクライアントのバッファのサイズ。バッファを大きくすると、大規模なクラスターのネットワークスループットが向上し、クエリ処理時間が短縮される可能性がありますが、他の用途に使用できるメモリ量が減少します。

exchange.max-response-size¶

• タイプ: data size

• 最小値: 1MB

• デフォルト値: 16MB

exchangeリクエストから返されるレスポンスの最大サイズ。レスポンスは、exchangeのすべての同時リクエスト間で共有されるexchangeクライアントバッファに配置されます。

レイテンシーが高い場合は、値を大きくするとネットワークスループットが向上する可能性があります。値を小さくすると、exchangeクライアントバッファがより多くのタスクのレスポンスを保持するため（より少ないタスクからより多くのデータを保持するのではなく）、大規模なクラスターのクエリパフォーマンスが向上する可能性があります。

sink.max-buffer-size¶

• タイプ: data size

• デフォルト値: 32MB

アップストリームタスクによってプルされるのを待機しているタスクデータの出力バッファサイズ。タスク出力がハッシュパーティション分割されている場合、バッファはすべてのパーティション分割されたコンシューマー間で共有されます。ネットワークのレイテンシーが高い場合や、クラスターに多くのノードがある場合は、この値を大きくすると、ステージ間で転送されるデータのネットワークスループットが向上する可能性があります。

タスクプロパティ¶

task.concurrency¶

• タイプ: integer

• 制限事項: 2のべき乗である必要があります

• デフォルト値: 16

結合や集計などの並列演算子に対するデフォルトのローカル並列度。この値は、クエリの並列度とワーカーのリソース使用率に基づいて上下に調整する必要があります。低い値は、多くのクエリを同時に実行するクラスターに適しています。これは、クラスターが実行中のすべてのクエリによってすでに使用されているため、並列度を上げるとコンテキストスイッチングなどのオーバーヘッドによって速度が低下するためです。高い値は、一度に1つまたは少数のクエリのみを実行するクラスターに適しています。これは、task_concurrencyセッションプロパティを使用して、クエリごとに指定することもできます。

task.http-response-threads¶

• タイプ: integer

• 最小値: 1

• デフォルト値: 100

HTTP応答を処理するために作成される可能性のある最大スレッド数。スレッドは必要に応じて作成され、アイドル状態になるとクリーンアップされるため、処理するリクエストの数が少ない場合は、大きな値にしてもオーバーヘッドはありません。多数の同時実行クエリがあるクラスター、または数百または数千のワーカーがいるクラスターでは、より多くのスレッドが役立つ場合があります。

task.http-timeout-threads¶

• タイプ: integer

• 最小値: 1

• デフォルト値: 3

HTTP応答を生成するときにタイムアウトを処理するために使用されるスレッド数。すべてのスレッドが頻繁に使用されている場合は、この値を増やす必要があります。これは、com.facebook.presto.server:name=AsyncHttpExecutionMBean:TimeoutExecutor JMXオブジェクトを使用して監視できます。ActiveCountが常にPoolSizeと同じ場合は、スレッド数を増やしてください。

task.info-update-interval¶

• 型: duration

• 最小値: 1ms

• 最大値: 10s

• デフォルト値: 3s

スケジューリングで使用されるタスク情報の鮮度を制御します。値を大きくすると、コーディネーターのCPU負荷を軽減できますが、最適な分割スケジューリングにならない可能性があります。

task.max-partial-aggregation-memory¶

• タイプ: data size

• デフォルト値: 16MB

分散集計の部分集計結果の最大サイズ。この値を大きくすると、より多くのグループをフラッシュする前にローカルに保持できるようになり、ネットワーク転送を減らし、CPU使用率を下げることができますが、メモリ使用量が増加します。

task.max-worker-threads¶

• タイプ: integer

• デフォルト値: ノード CPU * 2

ワーカーが分割を処理するために使用するスレッド数を設定します。ワーカーのCPU使用率が低く、すべてのスレッドが使用中の場合、この数を増やすとスループットが向上しますが、ヒープスペースの使用量が増加します。値を高く設定しすぎると、コンテキストスイッチングのためにパフォーマンスが低下する可能性があります。アクティブなスレッドの数は、com.facebook.presto.execution.executor:name=TaskExecutor.RunningSplits JXMオブジェクトのRunningSplitsプロパティを使用して確認できます。

スレッド数は、絶対値（例：10）または利用可能なCPUコア数に対する相対値（例：1.5C）を使用して構成できます。相対値を使用する場合、スレッド数は、利用可能なCPUコア数に指定された係数（例：1.5）を掛けて、最も近い整数に丸められます。

task.min-drivers¶

• タイプ: integer

• デフォルト値: task.max-worker-threads * 2

ワーカーで実行されているリーフ分割の目標数。各リーフタスクでは、少なくとも3つの分割が実行されることが保証されているため、これは最小値です。非リーフタスクも、デッドロックを防ぐために順番に実行されることが保証されています。値が小さいと、新しいタスクの応答性が向上する可能性がありますが、リソースが十分に活用されない可能性があります。値が大きいと、リソース使用率が向上する可能性がありますが、追加のメモリを使用します。

task.writer-count¶

• タイプ: integer

• 制限事項: 2のべき乗である必要があります

• デフォルト値: 1

クエリごとのワーカーごとの同時ライター スレッド数。この値を増やすと、特にクエリがI/Oバウンドではなく、並列書き込みに追加のCPUを利用できる場合に（一部のコネクタでは、圧縮やその他の要因により書き込み時にCPUがボトルネックになる可能性があります）、書き込み速度が向上する可能性があります。これを高く設定しすぎると、過剰なリソース使用率によりクラスターが過負荷になる可能性があります。これは、task_writer_countセッションプロパティを使用して、クエリごとに指定することもできます。

task.interrupt-runaway-splits-timeout¶

• 型: duration

• デフォルト値: 10m

制御を譲らずにブロックされた分割スレッドを中断するためのタイムアウト。特定の場所でブロックされたスレッドのみが中断されます。現在、これはJoni正規表現ライブラリでブロックされたスレッドのみです。

ノードスケジューラープロパティ¶

node-scheduler.max-splits-per-node¶

• タイプ: integer

• デフォルト値: 100

すべての分割が標準の分割ウェイトを持つと仮定して、各ワーカーノードで実行できる分割数の目標値。

クエリが大きなバッチで送信される場合（例：大規模なレポートグループを定期的に実行する場合）、または高速に完了する多くの分割を生成するが、分割スケジューラにそれを表現する分割ウェイト値を割り当てることをサポートしないコネクタの場合は、より高い値を使用することをお勧めします。この値を大きくすると、ワーカーが完全に活用されるのに十分な分割を持つことが保証されるため、クエリのレイテンシが向上する可能性があります。

コネクタが重みベースの分割スケジューリングをサポートしている場合、割り当てられる分割数は個々の分割の重みに依存します。分割が小さい場合は、各ワーカーに割り当てられる分割数を増やして補正します。

これを高く設定しすぎると、メモリが無駄になり、分割がワーカー間でバランスが取れていないためにパフォーマンスが低下する可能性があります。理想的には、常に少なくとも1つの分割が処理を待機しているように設定する必要がありますが、それより高く設定しないでください。

node-scheduler.max-pending-splits-per-task¶

• タイプ: integer

• デフォルト値: 10

ノードがすでに合計分割数の制限に達している場合でも、クエリの1つのステージで各ワーカーノードに対してキューに入れることができる、標準の分割ウェイトを持つ未処理の分割数。ステージごとに最小限の分割数を許可することは、飢餓とデッドロックを防ぐために必要です。

この値はnode-scheduler.max-splits-per-nodeより小さくする必要があり、通常は同じ理由で大きくされ、高すぎると同様の欠点があります。

node-scheduler.min-candidates¶

• タイプ: integer

• 最小値: 1

• デフォルト値: 10

分割のターゲットノードを選択するときに、ノードスケジューラによって評価される候補ノードの最小数。この値を低く設定しすぎると、すべてのワーカーノード間で分割のバランスが適切に取れない場合があります。高く設定しすぎると、クエリのレイテンシが増加し、コーディネーターのCPU使用率が増加する可能性があります。

node-scheduler.network-topology¶

• タイプ: string

• 許可される値: legacy、flat

• デフォルト値: legacy

分割のスケジュール時に使用するネットワークトポロジを設定します。legacyは、分割をスケジュールするときにトポロジを無視します。flatは、ローカル分割用にワークキューの50％を予約することで、データが配置されているホストで分割をスケジュールしようとします。分散ストレージがPrestoワーカーと同じノードで実行されているクラスターでは、flatを使用することをお勧めします。

オプティマイザープロパティ¶

optimizer.dictionary-aggregation¶

• タイプ: boolean

• デフォルト値: false

辞書に対する集計の最適化を有効にします。これは、dictionary_aggregationセッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.optimize-hash-generation¶

• タイプ: boolean

• デフォルト値: true

実行中に早期に分散、結合、および集計のハッシュコードを計算し、クエリの後期で操作間で結果を共有できるようにします。これにより、同じハッシュを複数回計算することを回避することでCPU使用量を削減できますが、ハッシュの追加のネットワーク転送が発生します。ほとんどの場合、クエリ処理時間全体が短縮されます。これは、optimize_hash_generationセッションプロパティを使用して、クエリごとに指定することもできます。

クエリプランを読みやすくするために、EXPLAINを使用する場合は、このプロパティを無効にすると便利な場合があります。

optimizer.optimize-metadata-queries¶

• タイプ: boolean

• デフォルト値: false

メタデータとして保存されている値を使用して、一部の集計の最適化を有効にします。これにより、Prestoは一部の単純なクエリを一定時間で実行できます。現在、この最適化は、パーティションキーのmax、min、およびapprox_distinct、および入力のカーディナリティに影響を受けない他の集計（DISTINCT集計を含む）に適用されます。これを使用すると、一部のクエリが大幅に高速化される可能性があります。

主な欠点は、コネクタが行のないパーティションのパーティションキーを返した場合に、誤った結果が生成される可能性があることです。特に、Hiveコネクタは、他のシステムによって作成された場合（Prestoは作成できません）、空のパーティションを返す可能性があります。

optimizer.optimize-single-distinct¶

• タイプ: boolean

• デフォルト値: true

単一の DISTINCT 最適化では、複数の DISTINCT 句を単一の GROUP BY 句に置き換えようとします。これにより、実行速度を大幅に向上させることができます。

optimizer.push-aggregation-through-join¶

• タイプ: boolean

• デフォルト値: true

外部結合の上に集計があり、結合の外部側のすべての列がグループ化句にある場合、集計は外部結合の下にプッシュされます。この最適化は、外部結合に対する集計に書き換えられる相関スカラーサブクエリに特に役立ちます。例えば

SELECT * FROM item i
    WHERE i.i_current_price > (
        SELECT AVG(j.i_current_price) FROM item j
            WHERE i.i_category = j.i_category);

この最適化を有効にすると、結合によって処理する必要があるデータ量を減らすことで、クエリを大幅に高速化できます。ただし、非常に選択的な結合を持つ一部のクエリでは、速度が低下する可能性があります。これは、push_aggregation_through_join セッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.push-table-write-through-union¶

• タイプ: boolean

• デフォルト値: true

データの書き込みを行うクエリで UNION ALL を使用する場合に、書き込みを並列化します。これにより、UNION ALL クエリで出力テーブルを書き込む速度が向上します。これは、これらの書き込みでは結果を収集する際の追加の同期が必要ないためです。この最適化を有効にすると、書き込み速度がまだ飽和していない場合に UNION ALL の速度が向上します。ただし、すでに負荷の高いシステムでは、クエリの速度が低下する可能性があります。これは、push_table_write_through_union セッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.join-reordering-strategy¶

• タイプ: string

• 許容される値: AUTOMATIC, ELIMINATE_CROSS_JOINS, NONE

• デフォルト値: AUTOMATIC

使用する結合の並べ替え戦略。NONE は、クエリにリストされているテーブルの順序を維持します。ELIMINATE_CROSS_JOINS は、可能な場合はクロス結合を排除するために結合を並べ替え、それ以外の場合は元のクエリ順序を維持します。結合を並べ替える際には、可能な限り元のテーブル順序を維持するように努めます。AUTOMATIC は可能な順序を列挙し、統計ベースのコスト見積もりを使用して最小コストの順序を決定します。統計情報が利用できない場合、または何らかの理由でコストを計算できなかった場合、ELIMINATE_CROSS_JOINS 戦略が使用されます。これは、join_reordering_strategy セッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.max-reordered-joins¶

• タイプ: integer

• デフォルト値: 9

optimizer.join-reordering-strategy がコストベースに設定されている場合、このプロパティは一度に並べ替えることができる結合の最大数を決定します。

optimizer.use-defaults-for-correlated-aggregation-pushdown-through-outer-joins¶

• タイプ: boolean

• デフォルト値: true

集計は、外部結合の下にプッシュされる場合があります（optimizer.push-aggregation-through-joinを参照）。一般に、集計関数にはカスタムの NULL 処理動作があります。外部結合によって生成される可能性のある NULL パディングされた行を正しく処理するために、オプティマイザーは、単一の NULL 値に対する対応する集計とのその後のクロス結合を導入し、結合出力からの集計をこれらの NULL 集計値と結合します。

特定の集計関数（NULL を無視するもの、COUNT など）の場合、クロス結合を回避でき、NULL に対するデフォルト/既知の集計値を結合の集計出力と直接結合できます。この最適化により、クロス結合が排除され、外部結合が内部結合に変換されて、より最適なプランが生成される可能性があります。

optimizer.rewrite-expression-with-constant-variable¶

• タイプ: boolean

• デフォルト値: true

フィルター式と代入式から定数を持つ式を抽出し、その式を定数値に置き換えます。

optimizer.history-based-optimizer-plan-canonicalization-strategies¶

• タイプ: string

• デフォルト値: IGNORE_SAFE_CONSTANTS

履歴ベースの最適化のためにクエリプランを正規化するために使用されるプラン正規化戦略。

optimizer.track-history-stats-from-failed-queries¶

• タイプ: boolean

• デフォルト値: true

失敗したクエリの完全なプランフラグメントから、履歴ベースのプラン統計を追跡します。

optimizer.log-plans-used-in-history-based-optimizer¶

• タイプ: boolean

• デフォルト値: false

履歴ベースの最適化で使用される統計的に等価なプランと正規化されたプランをログに記録します。

optimizer.exploit-constraints¶

• タイプ: boolean

• デフォルト値: true

クエリプランのノード間で、個別キーやカーディナリティなどの論理プロパティの分析と伝播を有効にします。オプティマイザーは、これらのプロパティを使用して、さまざまな最適化を実行できます。

optimizer.confidence-based-broadcast¶

• タイプ: boolean

• デフォルト値: false

使用されている統計の信頼度に基づいてブロードキャストを有効にします。最も高い（HIGH または FACT）信頼度統計を持つ joinNode の側をブロードキャストします。両側が同じ信頼度統計を持っている場合は、元の動作に従います。これは、confidence_based_broadcast セッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.treat-low-confidence-zero-estimation-as-unknown¶

• タイプ: boolean

• デフォルト値: false

結合中に、LOW 信頼度、ゼロ推定値を UNKNOWN として扱うことを有効にします。これは、treat-low-confidence-zero-estimation-as-unknown セッションプロパティを使用して、クエリごとに指定することもできます。

optimizer.retry-query-with-history-based-optimization¶

• タイプ: boolean

• デフォルト値: false

HBO によって改善される可能性がある失敗したクエリの再試行を有効にします。これは、retry-query-with-history-based-optimization セッションプロパティを使用して、クエリごとに指定することもできます。

プランナープロパティ¶

planner.query-analyzer-timeout¶

• 型: duration

• デフォルト値: 3m

処理に時間がかかりすぎたり、無限ループに陥ったりした場合の、クエリ Analyzer の最大実行時間。タイムアウト時間が経過すると、プランナースレッドが中断され、例外がスローされます。

正規表現関数プロパティ¶

次のプロパティを使用すると、正規表現関数を調整できます。

regex-library¶

• タイプ: string

• 許容される値: JONI, RE2J

• デフォルト値: JONI

正規表現関数に使用するライブラリ。JONI は一般的に一般的な使用法では高速ですが、特定の式パターンでは指数関数的な時間が必要になる場合があります。RE2J は線形時間を保証する別のアルゴリズムを使用しますが、多くの場合遅くなります。

re2j.dfa-states-limit¶

• タイプ: integer

• 最小値: 2

• デフォルト値: 2147483647

正規表現マッチングのために、RE2J が高速で潜在的にメモリを大量に消費する決定性有限オートマトン（DFA）を構築するときに使用する最大状態数。制限に達した場合、RE2J は、低速だがメモリ消費量の少ない非決定性有限オートマトン（NFA）を使用するアルゴリズムにフォールバックします。この値を小さくすると、速度を犠牲にして、正規表現検索の最大メモリフットプリントが減少します。

re2j.dfa-retries¶

• タイプ: integer

• 最小値: 0

• デフォルト値: 5

状態制限に達した場合に、RE2J が DFA アルゴリズムを再試行する回数。その後、その検索の今後のすべての入力に対して、低速だがメモリ消費量の少ない NFA アルゴリズムを使用します。特定の入力行で制限に達することが外れ値である可能性が高い場合は、より高速な DFA アルゴリズムを使用して後続の行を処理できるようにする必要があります。後続の行の照合で制限に達する可能性が高い場合は、時間とリソースを浪費しないように、最初から正しいアルゴリズムを使用する必要があります。処理する行数が多いほど、この値を大きくする必要があります。

ロギングプロパティ¶

log.max-history¶

• タイプ: integer

• デフォルト値: 30

log.max-history プロパティは、アプリケーションが保持するアーカイブログ期間の数を制御します。Presto では、1つのログ期間は1日に対応します。たとえば、log.max-history が 30 に設定されている場合、システムは過去 30 日間のログを保持します。

log.max-size¶

• タイプ: data size

• デフォルト値: 100MB

一般的なアプリケーションログファイルの最大ファイルサイズ。

http-server.log.enabled¶

• タイプ: boolean

• デフォルト値: true

HTTP サーバーのロギングを有効または無効にするフラグ。

http-server.log.compression.enabled¶

• タイプ: boolean

• デフォルト値: true

HTTP サーバーのログファイルの圧縮を有効または無効にするフラグ。

http-server.log.path¶

• タイプ: string

• デフォルト値: var/log/http-request.log

HTTPサーバーが使用するログファイルのパス。このパスは、ランチャースクリプトによって設定されるデータディレクトリからの相対パスです。詳細はPrestoの実行を参照してください。

http-server.log.max-history¶

• タイプ: integer

• デフォルト値: 15

http-server.log.max-historyプロパティは、HTTPサーバーが保持するアーカイブログ期間の数を制御します。Prestoでは、1つのログ期間は1日に対応します。例えば、http-server.log.max-historyが15に設定されている場合、システムは過去15日間のログを保持します。

http-server.log.max-size¶

• タイプ: data size

• デフォルト値: 100MB

HTTPサーバーのログファイルの最大ファイルサイズ。

レガシー互換プロパティ¶

legacy_json_cast¶

• タイプ: boolean

• デフォルト値: true

JSONからROWにキャストする際、レガシーサポートのためにRowTypeのフィールド名の大文字と小文字を無視し、マッチングを大文字小文字を区別しないようにします。legacy_json_castをfalseに設定すると、マッチング時にRowType内の二重引用符付きのフィールド名の大文字と小文字を厳密に区別します。引用符なしのフィールド名のマッチングは、引き続き大文字と小文字を区別しません。