本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

Junqiによる

1. はじめに

急速なデータ増加の時代において、大量のデータを効率的にクエリすることは、企業や技術サポート担当者にとって重要な課題となっています。ORCのような列指向ストレージ形式は特定のシナリオで顕著な利点を持っていますが、大規模なデータセットを処理する際にクエリ速度には依然としてボトルネックがあります。本記事では、PolarDB-Xの列指向クエリエンジンにおけるキャッシュ階層と、それがORC列指向クエリのパフォーマンス向上に果たす重要な役割について深く掘り下げます。設計原則、実装の詳細、適用シナリオを分析し、ビッグデータクエリにおけるその広範な応用と効率性、信頼性を示します。さらに、ORCファイルのストレージ構造、データ圧縮・解凍技術、およびエグゼキューターの中間結果をキャッシュするためのバックプレッシャー管理戦略についても取り上げ、キャッシュ階層とバックプレッシャー機構がどのようにクエリパフォーマンスをさらに向上させるかを説明します。これらの内容を通じて、読者はPolarDB-Xのキャッシュ階層が列指向クエリの効率向上に与える実際の効果と技術的優位性を理解できるでしょう。

2. 多層キャッシュ管理

2.1 概要

PolarDB-X の列指向クエリエンジンでは、多層キャッシュ管理はクエリパフォーマンスを向上させるためのコア戦略です。異なるレベルにキャッシュを設定することで、システムはデータアクセス頻度や特性に応じて効率的なデータロードとクエリ応答を実現できます。このキャッシュ階層アーキテクチャはデータ読み取りパスを最適化し、基盤となるストレージシステムへの依存を効果的に削減することで、クエリ速度を大幅に向上させます。

2.2 ORC ストレージ階層

ORC（Optimized Row Columnar）形式は、ビッグデータ処理で広く使用されている列指向ストレージ形式です。その内部構造は巧妙に設計されており、多層組織を通じて効率的なデータ圧縮と高速な列レベルのクエリを実現しています。

2.2.1 Stripe、Column、およびRowGroup

Stripe: デフォルトでは、ORCファイルは64MBごとに1つのストライプを形成します。複数の列が1つのストライプに格納されます。
Column: 1つのストライプ内では、各列は複数のRowGroupを含む連続したファイル領域に格納されます。
RowGroup: 列内では、10,000行ごとのデータが1つのRowGroupに分割されます。RowGroupは、ORCが圧縮、解凍、エンコード、デコードを行う基本単位です。列内に格納された行の総数が10,000の整数倍でない場合、最後のRowGroupには10,000行未満のデータが含まれることがあります。また、データブロックの位置情報を保存するために、ストライプフッターとインデックスデータという2種類の構造が使用されています。

2.2.2 SMA インデックス

ORCファイルでは、SMA（Statistics Minimum and Maximum）インデックスが各ストライプおよびRowGroupの最小値と最大値の統計情報を保存します。この情報により、クエリ中に無関係なデータブロックを迅速にフィルタリングでき、不要なデータ読み取りを削減し、クエリ効率を向上させます。

2.3 ORC データブロックの特定

ORCファイル内のデータブロック（例えば1,000行のデータユニット）を正確に特定するには、以下の5つのフィールドを含む一意の論理アドレスが必要です：

StripeId: ファイル内のストライプ番号。
ColumnId: ストライプ内の列番号。
RowGroupId: 列内のRowGroup番号。
StartPosition: RowGroup内のブロックの開始位置。
PositionCount: ブロック内の行数。

これらのフィールドを通じて、システムはORCファイル内の具体的なデータ位置を正確に特定し、効率的なデータ読み取りを可能にします。

2.4 列指向クエリとORCの関係

列指向クエリプロセスでは、エグゼキューターはデータクエリ操作のコアコンポーネントです。SQLステートメント、演算子（スキャンや結合など）、述語条件に基づいて実行プランツリーを生成し、対応するクエリ操作を実行します。

2.4.1 実行プランとスキャン演算子

エグゼキューターによって生成される実行プランツリーには、スキャン演算子が含まれています。これは、ORCファイルに対してスキャン操作をどのように実行するか、つまり特定の列からデータをどのように読み取るかを定義します。これらの操作は通常、列中心であり、ORC形式のファイルで行われることで、クエリ効率が大幅に向上します。

2.4.2 述語条件とSMAインデックス

クエリ操作の実行中、スキャン演算子にはデータフィルタリングのための述語条件が付随します。ORC形式のSMAインデックスにより、エグゼキューターはすべてのデータを読み取ることなく、どのストライプまたはRowGroupに該当するデータが含まれているかを効率的に判断できます。述語条件とSMAインデックスを組み合わせることで、システムはデータロードとスキャンの負荷を削減し、クエリパフォーマンスをさらに向上させます。

2.4.3 データ圧縮と解凍

ORCファイルは通常、LZ4汎用圧縮やRunLength数値圧縮などの複数の圧縮技術を使用して、ストレージスペースを削減し、I/O効率を向上させます。エグゼキューターはデータを読み取る際に自動的に解凍操作を行います。圧縮率は2〜4倍で、これによりストレージスペースを節約し、データ読み取りの効率も向上します。

3. 全体的な階層アーキテクチャ

PolarDB-Xの列指向クエリエンジンは、レベル1、レベル2、レベル3のキャッシュ、および基盤となるOSSストレージベースを使用する多層キャッシュメカニズムを採用しています。各レベルのキャッシュには独自の設計と機能があり、階層的な検索とキャッシュを通じてシステムは大規模なデータを効率的にアクセスおよび管理できます。

3.1 処理図

全体的なプロセスは以下のステップにまとめられます：

キャッシュ階層: システムには3つのレベルのキャッシュが設定されています。いずれかのレベルでキャッシュヒットが発生した場合、そのキャッシュが返されます。そうでない場合は、次のレベルのキャッシュへの検索が続き、最終的にOSSストレージベースに到達します。
キャッシュスペース: レベル1のキャッシュスペースはランタイムメモリの20%以下、レベル2のキャッシュスペースは30%以下、レベル3の

キャッシュとORCファイルの設計および読み取りパスについて

レベル3キャッシュの仕組み

レベル3キャッシュは、以前レベル2キャッシュにあったバイト配列をファイルとして保存します。隣接するセグメントが読み取られる際にはそれらがマージされ、古いファイルは非同期で削除されます。ファイルへの書き込み操作は時間がかかるため、これらの操作は非同期スレッドによって完了されます。

3.6 OSS ストレージ基盤

すべてのキャッシュレベルでミスが発生した場合、システムは {StripeId, ColumnId, RowGroupId} を特定のファイルパスにマッピングし、OSS ストレージから完全な ORC ファイルを取得し、必要なファイル断片をダウンロードして解凍・読み取りを行います。OSS アクセスにはネットワークレイテンシがありますが、ほぼ無制限のストレージ容量がシステムに強力なバックアップサポートを提供します。

4. レベル1およびレベル2キャッシュの設計原則

4.1 列指向データ階層

PolarDB-X のカラムナリーストレージ形式は主に ORC ファイルで構成されています。エグゼキューターの計算層が必要とするデータ構造は、ORC ファイルから以下の3つのレベルに分けることができます。

物理ストレージ構造: 純粋なバイトシーケンスで構成されたファイル構造で、ファイル読み取りインターフェース InputStream によってカプセル化されています。読み取りプロセスはファイル内の各バイト領域の意味に影響を与えません。
論理ストレージ構造: ファイル、ストライプ、列、ストリーム、RowGroup、RL（軽量）圧縮、汎用圧縮という7つの階層構造に焦点を当てた構造です。
計算構造: ファイル、列、ストライプ、RowGroup の4つのレベルの情報を使用して、エグゼキューターが計算に使用する特定のタイプのブロックを取得する構造です。

4.2 物理ストレージ構造

物理ストレージ構造は、ORC ファイルの生の基本的なストレージ形式であり、純粋にバイトシーケンスで構成されており、意味情報は含まれていません。ファイル読み取りインターフェース（例: InputStream）を使用することで、システムはファイル内のバイトデータを順次またはランダムに読み取ることができ、その具体的な意味を理解する必要はありません。

4.3 論理ストレージ構造

論理ストレージ構造は、データの組織と圧縮に焦点を当てており、以下のレベルで構成されています。

4.3.1 ファイル

ファイルは、ファイルフッター、ポストスクリプト、および複数のストライプで構成されています。

ポストスクリプト: ファイルの最後に位置しており、ファイル内の主要な内部領域のバイト位置を特定できます。
ファイルフッター: ファイルレベルの最小/最大統計情報、圧縮および暗号化アルゴリズム情報、バージョン情報などを格納しています。

4.3.2 ストライプ

各64 MBごとにストライプが形成され、これは StripeFooter と一連の列で構成されています。

StripeFooter:

全ての列-ストリームの2層構造のメタデータを格納します。
ストライプレベルでのSMA情報（最小/最大、カウント、合計）を格納します。
ストライプレベルでのカスタムインデックスを格納します。

4.3.3 列

各列は、いくつかのストリームで構成されており、これらはストレージ構造上で連続しています。

インデックスストリーム: 列の行インデックスを格納し、ColumnStatistics と位置で構成されています。
- ColumnStatistics: 各 RowGroup における列の最小/最大、カウント、合計などのSMA情報。
- 位置: 各 RowGroup 上での列の開始バイト位置、および圧縮前後のバイトサイズ。
Present ストリーム: 列の NULL 値のビットマップを格納し、データは軽量および汎用圧縮を経ています。
データストリーム: 列のデータを格納し、データは軽量および汎用圧縮を経ています。
辞書ストリーム: 辞書を形成できる列のために、追加のストリームを生成して辞書データを格納します。

4.3.4 ストリーム

各ストリームは、異なるタイプのデータストリーム情報を含む連続したバイトストレージ領域を表します。各ストリームはいくつかの RowGroup で構成され、各 RowGroup はデフォルトで10,000行のデータを格納します。

4.3.5 RowGroup

各ストリーム上では、10,000行のデータごとに RowGroup が形成されます。各 RowGroup は軽量圧縮と汎用圧縮を受け、RowIndex に格納されます。RowIndex は、RowGroup の開始バイト位置、圧縮後のサイズ、元のサイズ、開始要素数などの情報を記述します。

4.3.6 汎用圧縮

ORC のデフォルトの汎用圧縮方式は Zlib で、高い圧縮率を提供しますが、解凍速度は遅いです。PolarDB-X のカラムナリストレージは LZ4 圧縮を使用しています。圧縮率は平均的ですが、解凍速度が速く、高性能が求められるシナリオに適しています。

4.3.7 RL（軽量）圧縮

RL（RunLength）圧縮は、データのワークロード特性に基づいて柔軟な圧縮方法を選択し、圧縮効率を向上させます。主な方法は次の4つです。

DIRECT: 明確なワークロード特性がないデータの場合、元のデータが直接格納されます。
SHORT_REPEAT: データ要素が繰り返され、その長さがある範囲内にある場合にこのエンコーディングが使用されます。
PATCHED_BASE: 要素の分布範囲が広く、DIRECT エンコーディングが使用できない場合にパッチベースエンコーディングが採用されます。
DELTA: 要素が特定のパターン（例: 等差数列）に従う場合にデルタエンコーディングが使用されます。

4.4 計算構造と BlockCacheManager

ファイル、列、ストライプ、RowGroup に基づいて特定のタイプのブロックを取得できます。例えば、RowGroup ストライドが10,000行でチャンク制限が1000の場合、{file=xxx.orc, StripeId=0, ColumnId=1, rowGroupId={1,3}} は20個の IntegerBlock オブジェクトを取得できます。BlockCacheManager はこれらのオブジェクトをキャッシュする役割を担っており、主なインターフェースには以下が含まれます。

**RowGroup アク

非同期I/O管理とバッファリサイクル

非同期I/O管理: 非同期I/O操作のコールバックを管理し、I/O結果やストリーム情報に基づいて複数のパーサーを自動的に生成することで、効率的かつ並列なデータ解析を確保します。
バッファリサイクル: 非同期I/O操作で使用されたバッファを自動的にリサイクルしてメモリリークを防ぎ、システムリソースの利用効率を向上させます。

ColumnReaderインターフェースには3つのコアメソッドが含まれています：

初期化メソッド: このメソッドはデータ解析プロセスを初期化します。StripeLoaderがロードされた際に返されるコールバックを渡すか、内部でロードプロセスを直接トリガーして結果を待つことができます。
ポインタ位置指定メソッド: このメソッドは内部読み取りポインタを指定された行グループおよび要素の位置に移動し、ランダムアクセスを可能にし、特定のデータを効率的に検索して読み取ります。
データ読み取りメソッド: このメソッドは現在のポインタ位置から指定された数のデータ要素を読み取り、ランダムアクセス可能なブロックに書き込みます。この方法では、動的配列の拡張や境界チェックなどの追加オーバーヘッドを回避し、データ書き込み効率を向上させます。

5.3 一般的な抽象カラムリーダー

AbstractLongColumnReaderは、整数または長整数で表現されるすべてのデータタイプ（例：int、bigint、decimal64、date、datetimeなど）を処理するのに適した抽象クラスです。主なステップは次の通りです：

パーサーの初期化: 入力ストリームとストリーム情報に基づいてパーサーが構築されます。たとえば、一般的なbigintタイプの場合、データストリームと存在ストリームに基づいて圧縮および解凍パーサーが構築されます。データストリームには圧縮されたbigint値が格納され、存在ストリームには圧縮されたNULL値情報が格納されます。
多層ポインタ管理: パーサーは3層のポインタ管理メカニズムを使用します。
- ポインタ1: 解凍されたデータキャッシュの現在位置を指し、解凍された数値またはブール値を取得します。
- ポインタ2: LZ4解凍キャッシュの位置を指し、解凍後の中間データを管理します。
- ポインタ3: 生データの連結リストの位置を指し、圧縮されていない生データを管理します。
指定位置への移動: 行グループIDと要素位置に基づいてバイト開始位置と圧縮サイズを計算し、各層のポインタを調整して読み取るデータを正しく特定します。
データコピーとブロック生成: 現在のポインタからランダムアクセス可能なブロックにメモリデータを必要に応じてコピーします。異なるデータタイプに応じて対応するタイプのブロックオブジェクトを割り当て、存在ストリームとデータストリームをループ内で解析し、最終的なデータをブロックに書き込んでブロック構築を完了します。

上記の設計により、新しいORC読み取りパスは各列および各行グループに対して精密な制御を実現し、データ読み取りと解析のあらゆる側面を最適化しています。StripeLoaderインターフェースはストリーム情報を効率的に管理し、I/O操作を組織化します。一方、ColumnReaderインターフェースは生のバイトデータを効率的に解析し、実行者が必要とするブロックオブジェクトを生成します。AbstractLongColumnReaderの抽象設計と組み合わせることで、全体の読み取りプロセスは効率性と柔軟性を達成し、複数のデータタイプの処理要件に適応します。このカスタマイズされたORC読み取りパス設計は大規模データ処理を強力にサポートし、データ読み取りのパフォーマンスと信頼性を大幅に向上させます。

6. 3層キャッシュの設計原則

6.1 3層キャッシュシステムの構成

3層キャッシュシステムの管理は、効率的なデータアクセスとシステムパフォーマンスの最適化を確保するためにいくつかの重要な部分をカバーします。まず、ファイルシステムの入出力（I/O）プロセスがシステムの基盤であり、ネットワークI/Oとローカル永続キャッシュの両方を含みます。ネットワークI/Oはリモートデータの転送を担当し、ローカル永続キャッシュはローカルに保存されたデータの信頼性と迅速なアクセスを確保します。次に、ファイルメタデータ管理はObject Storage Service（OSS）インスタンスに保存されているテーブルファイルとインデックスファイルを維持し、データ構造の秩序と検索効率を確保します。さらに、データソース管理はさまざまなエンジン下でのデータソースの設定とロードを行い、多様なデータ入力チャネルをサポートします。最後に、Massively Parallel Processing（MPP）フレームワークを通じてファイルアクセススケジューリングが行われ、実行前のファイルアクセスを合理的に割り当ててスケジュールし、リソース利用とアクセス効率を最適化します。

6.2 Hadoopファイルシステムとキャッシュファイルシステム

Hadoopファイルシステム

Hadoopエコシステムにおいて、Hadoopファイルシステムは統一されたファイルシステムの抽象化を提供し、そのコア抽象クラスを実装することでさまざまなデータソースをカプセル化します。この設計により、異なるタイプのデータソースが統一されたインターフェースを通じてアクセス可能になり、ファイル操作の複雑さが大幅に簡略化されます。Hadoopファイルシステムは接続の初期化、ファイルストリームのオープン、ファイルストリームの作成を通じてファイルの読み書きを可能にし、分散データストレージと効率的なデータ処理をサポートします。

キャッシュファイルシステム

ファイルアクセスの効率をさらに向上させるため、PolarDB-Xはキャッシュファイルシステムを設計および実装しました。これはローカル永続キャッシュとリモートOSSインスタンスの両方のファイルアクセスをサポートします。キャッシュファイルシステムは主に2つのコンポーネントで構成されています。1つはリモートOSSインスタンス上のファイルアクセスを処理し、もう1つはデータの永続化やキャッシュファイルの管理を含むローカルキャッシュを管理します。この2層のキャッシュメカニズムにより、システムはデータの一貫性を確保しつつ、ファイルアクセスを大幅に高速化し、全体的なシステムパフォーマンスを向上させます。

6.3 読み取りプロセス

3層キャッシュシステムのよく設計された読み取りプロセスは、効率的なデータ取得とキャッシュ管理を確保します。まず、システムはキャッシュファイルシステムを通じてターゲットファイルの入力ストリームを取得し、データ読み取りの準備を行います。次に、システムは必要に応じてファイルの特定のバイト範囲を読み取ります。このプロセスはファイル内の任意の位置に柔軟にアクセスでき、さまざまなデータ要件に対応します。読み取られたデータはキャッシュマネージャによって処理されます。キャッシュマネージャ内の非同期ディスクフラッシュスレッドは、リモートから取得されたデータを定期的にローカルディスクに永続化し、各キャッシュブロックのリモートパス、オフセット、長さ情報を記録する範
以下の設計は次の通りです。

7.3.1 プロデューサー・コンシューマー・バッファーモデル

プロデューサーパイプライン: 並列度mで、各並列処理上にプロデューサードライバーが形成されます。
コンシューマーパイプライン: 並列度nで、各並列処理上にコンシューマードライバーが形成され、プロデューサーからのチャンクを受け取るためのLocalBufferが装備されています。
LocalBuffer: 無制限のノンブロッキングキューとして存在し、リンクリスト構造を介してチャンクの読み書きを管理します。メモリ制限を考慮しない場合、プロデューサーとコンシューマーは自由にLocalBufferに対して読み書きできます。しかし、プロデューサーの速度がコンシューマーの速度を大幅に上回ると、メモリ使用量が急激に増加し、システムの不安定を引き起こす可能性があります。そのため、制御のためにバックプレッシャー機構が導入されています。
! 15

7.3.2 メモリカウンターとシグナル機構

memory_ledger: すべてのLocalBuffer内のチャンク総数を記録し、メモリ使用量の指標として機能します。
readableおよびwritable信号: SettableFutureに基づいて実装されており、これらはプロデューサーとコンシューマーの実行状態を制御するために使用されます。

readable: バッファーが読み取り可能であることを示す信号です。
writable: バッファーが書き込み可能であることを示す信号です。
これらの2つの信号を通じて、システムはプロデューサーとコンシューマーの実行を調整し、メモリオーバーロードを回避できます。

7.3.3 バックプレッシャープロセス

メモリ閾値Smaxの設定: memory_ledgerに記録されたメモリ使用量がSmaxに達した場合、バックプレッシャーがトリガーされます。
バックプレッシャーのトリガー: プロデューサーがチャンクをLocalBufferに書き込む際に、memory_ledgerのメモリ使用量がSmaxに達するとバックプレッシャーが発生します。すべての上流のプロデューサードライバーは即座にタイムスライスを放棄し、ドライバーブロッキングキューに入ります。

プロデューサーの処理: writable信号が生成され、memory_ledgerに格納されます。このwritable信号は、プロデューサードライバーが「バッファーが書き込み可能になるイベント」を待機していることを表します。また、writable信号にはコールバックが登録されており、その実行内容は、プロデューサードライバーをブロッキングキューから取り出し、準備完了キューに移動することです。
コンシューマーの処理: コンシューマーはLocalBuffer内のキューから継続的にチャンクを取り除き、同時にmemory_ledger.subBytesを呼び出してメモリ使用量の値を減少させます。ほとんどのコンシューマードライバーのLocalBufferキューが空になり、memory_ledgerのメモリ使用量がほぼゼロに近づくと、以下のステップが実行されます。

i) readable信号が生成され、memory_ledgerに格納されます。これは、すべてのコンシューマードライバーが「バッファーが読み取り可能になるイベント」を待っていることを表します。readable信号には、イベントが完了した後に実行されるコールバックが登録されており、その内容は次の通りです。
- コンシューマードライバーがタイムスライス内でまだ待機中の場合、待機を終了し、コンシューマードライバーがバッファーからチャンクを読み続けるようにします。
- コンシューマードライバーがタイムスライスを放棄し、ブロッキングキューにいる場合、コンシューマードライバーを準備完了キューに移動します。

ii) コンシューマードライバーがmemory_ledgerからwritable信号を取得し、writable.setを呼び出します。これは、「バッファーが書き込み可能になったイベント」が完了したことを示します。これにより、登録されたコールバックが実行され、すべてのプロデューサードライバーがブロッキングキューから最優先の準備完了キューに移動します。

iii) コンシューマードライバーがreadable.getを呼び出し、スレッドはその場で待機を開始します。次の2つの状況が発生するまで待機します。
1) タイムアウト後、コンシューマードライバーはタイムスライスを放棄し、ブロッキングキューに入ります。
2) タイムアウト前に「バッファーが読み取り可能になったイベント」が完了した場合、待機が終了し、コンシューマードライバーがバッファーからチャンクを読み続けることが許可されます。

iii) 短時間（通常数十ナノ秒）後、スレッドグループによって準備完了キューからプロデューサードライバーが取り出され、スケジューリングと実行が開始されます。これにより、プロデューサーはチャンクを生成し、それをLocalBufferに書き込みます。一方、コンシューマードライバーも待機を終了し、バッファーからチャンクを読み取り、消費してチャンクメモリを解放します。このメカニズムにより、プロデューサーとコンシューマー間の速度が一致し、メモリオーバーロードを防ぎます。さらに、頻繁なコンテキストスイッチを削減し、システム全体のパフォーマンスが向上します。
! 16

7.4 バックプレッシャー周波数制御

過剰なバックプレッシャーとスケジューリングオーバーヘッドを避けるため、システムはバッファーメモリの上限を動的に調整し、バックプレッシャーの頻度を制御します。具体的な手順は次の通りです。

バックプレッシャー回数の上限Rを設定: 例えば、システムのデフォルトではR=1000です。
初期Smax値の設定: 例えば、デフォルト値は8MBです。
タイムスライス内での動的調整: Smaxの値は、プロデューサーとコンシューマーの読み書き速度に基づいて動的に調整されます。これにより、各タイムスライスにおけるバックプレッシャーの回数が設定された上限Rを超えないようにします。
過剰なメモリ使用の防止: システムは、データベースインスタンスのランタイムメモリサイズに基づいてSmaxの上限を設定します。これにより、ユーザーが非常に小さいR値を設定した場合でも、過剰なSmaxによるメモリオーバーフローを防ぎます。
! 17

7.5 バックプレッシャープロセスのタイミングシーケンス

バックプレッシャープロセスは、次のようなタイミングシーケンスに抽象化できます。

正常動作: プロデューサーは速度v1でデータを書き込み、コンシューマーは速度v2でデータを読み取ります。バッファーメモリレベルSは時間tとともに変化します。
バックプレッシャーのトリガー: SがSmaxに達すると、プロデューサードライバーがブロック状態に入り、コンシューマード

キャッシュウォームアップ機能の詳細と活用方法

1. 毎日のビジネスデータをウォームアップする例

例:sql
WARMUP(30 21 * * *)
SELECT col1, col2, col3 ...
FROM table1
LEFT JOIN table2 ON table1.id1 = table2.id2
LEFT JOIN table3 ON table1.id1 = table3.id3
WHERE table1.col_date > 2024-01-01;

機能:
毎日夜9時30分に当日のビジネスデータをウォームアップして、夜10時のクエリに対して迅速な応答を確保します。

2. パフォーマンステスト前のウォームアップ

シナリオ:

TPC-HやClickBenchのようなプロフェッショナルなパフォーマンステストを実施する場合。

例:sql
WARMUP SELECT * FROM lineitem;
WARMUP SELECT * FROM orders;
WARMUP SELECT * FROM customer;
WARMUP SELECT * FROM part;
WARMUP SELECT * FROM partsupp;
WARMUP SELECT * FROM supplier;
WARMUP SELECT * FROM region;
WARMUP SELECT * FROM nation;

機能:
すべてのテーブルを一度にウォームアップすることで、パフォーマンステスト中にキャッシュヒット率を高く保ち、テスト結果がより正確になるようにします。

3. スケジュールされたバッチウォームアップ

シナリオ:

毎朝の運用・保守（O&M）タスクの前にデータをウォームアップする場合。

例:sql
WARMUP(*/5 1-5 * * *)
SELECT * FROM lineitem;

機能:
毎日午前1時から午前5時の間の運用・保守ウィンドウ内で、指定されたテーブルのデータを5分ごとにウォームアップし、運用・保守中のクエリ性能を安定させます。

8.6 サマリー

キャッシュウォームアップ機能は、クエリ中にリモートからデータを取得する際のオーバーヘッドを排除するためにキャッシュを積極的に埋める役割を果たします。これにより、クエリの性能と安定性が大幅に向上します。適切にキャッシュウォームアップを設定し、ビジネスアクセスモードやクエリ要件と組み合わせることで、PolarDB-Xはユーザーにより効率的で信頼性の高いデータクエリ体験を提供できます。

9. 結論

ビッグデータの時代において、大量のデータを効率的に保存しクエリする方法が重要な課題となっています。PolarDB-Xのカラムナリクエリエンジンは、キャッシュ階層管理と洗練されたバックプレッシャー機構を通じて、ORCカラムナリクエリのパフォーマンスを効果的に最適化し、大規模データセットにおけるクエリ速度のボトルネックを解決します。同時に、柔軟なキャッシュウォームアップと最適化されたORC読み取りパス設計により、PolarDB-Xは複雑で変化するビジネスシナリオにおいても効率的かつ安定したクエリサービスを提供します。

主な特長:

効率的なマルチレベルキャッシュ管理:
キャッシュ階層メカニズムにより、高頻度データへの高速アクセスと低頻度データの効率的な管理を可能にし、クエリ性能を大幅に向上させます。
洗練されたバックプレッシャー機構:
メモリカウンタとシグナルメカニズムにより、プロデューサーとコンシューマーの実行プロセスを精密に制御し、メモリ過負荷を防ぎ、システムの安定性を確保します。
柔軟なキャッシュウォームアップポリシー:
複数のウォームアップシナリオとポリシーが利用可能で、異なるビジネス要件に対応し、さらにクエリ応答速度を向上させます。
最適化されたORC読み取りパス設計:
公式リーダーをバイパスし、独自に最適化された読み取りパスを使用することで、効率的なデータ読み取りと解析を実現し、クエリレイテンシを削減します。
適応可能なコンピュート・ストレージ分離アーキテクチャ:
コンピュートノードとストレージノードの分離により、効率的なリソース利用とシステムの拡張性を実現し、さまざまな規模や複雑さのクエリに対応します。

PolarDB-Xは、継続的な技術革新と最適化を通じて、ユーザーにより効率的で信頼性の高いデータクエリソリューションを提供することを目指しています。ビッグデータの時代において、企業がデータの価値を最大限に活用できるよう支援します。