ApsaraDB for SelectDB における高並列ポイントクエリ - ApsaraDB for SelectDB

このトピックでは、で高並列ポイントクエリを最適化および使用する方法について説明します。これにより、同時クエリを最適化し、応答レイテンシを削減できます。 ApsaraDB for SelectDB。

背景情報

高並列サービスシナリオでは、ほとんどの場合、システムからデータ行をクエリする必要があります。ただし、ApsaraDB for SelectDB はカラムストア形式に基づいて開発されています。ワイドテーブルを使用する場合、カラムストア形式はランダム読み取り I/O を増幅し、クエリ速度を低下させます。 ApsaraDB for SelectDB のクエリオプティマイザーと実行エンジンは、ポイントクエリなどの一部の単純なクエリには適していません。クエリオプティマイザーは、このようなクエリを処理するための短いパスを計画できる必要があります。さらに、ApsaraDB for SelectDB のクエリアクセス層は Java で記述されています。 ApsaraDB for SelectDB が高並列 SQL クエリを分析および解析すると、高い CPU オーバーヘッドが発生します。これらの問題を解決するために、ApsaraDB for SelectDB は、行ストアモード、短いクエリパス、およびプリペアドステートメントを提供します。

行ストア

ApsaraDB for SelectDB のテーブルに対して行ストアモードを有効にすることができます。ただし、これは追加のストレージ容量を消費します。行ストアを実装するために、ApsaraDB for SelectDB は行ストア形式で格納されたデータをエンコードし、データを個別の列に格納します。これにより、行ストアの実装が簡素化されます。テーブルに対して行ストアモードを有効にできるのは、テーブルの作成時のみです。 CREATE TABLE ステートメントで次のプロパティを設定する必要があります。

"store_row_column" = "true"

Unique key モデルでのポイントクエリの最適化

Unique key モデルで行ストアモードを有効にする場合、書き込み時マージ (MoW) ポリシーを有効にして、ポイントクエリ中の I/O オーバーヘッドを削減できます。 Unique key モデルの CREATE TABLE ステートメントで enable_unique_key_merge_on_write パラメーターと store_row_column パラメーターが true に設定されている場合、クエリオプティマイザーはプライマリキーに基づいて実行されるポイントクエリの実行を最適化する短いパスを計画し、クエリの実行には 1 つのリモートプロシージャコール (RPC) のみが必要です。

次のサンプルコードは、行ストアモードと MoW ポリシーを有効にする方法の例を示しています。

CREATE TABLE `tbl_point_query` (
    `key` int(11) NULL,
    `v1` decimal(27, 9) NULL,
    `v2` varchar(30) NULL,
    `v3` varchar(30) NULL,
    `v4` date NULL,
    `v5` datetime NULL,
    `v6` float NULL,
    `v7` datev2 NULL
) ENGINE=OLAP
UNIQUE KEY(`key`)
COMMENT 'OLAP'
DISTRIBUTED BY HASH(`key`) BUCKETS 16
PROPERTIES (
    "enable_unique_key_merge_on_write" = "true",
    "light_schema_change" = "true",
    "store_row_column" = "true"
);

説明

enable_unique_key_merge_on_write パラメーターを true に設定して、ストレージエンジンがプライマリキーに基づいてポイントクエリを迅速に実行できるようにすることをお勧めします。
SELECT * FROM tbl_point_query WHERE id = 123 など、クエリの条件にプライマリキーのみが含まれている場合、クエリオプティマイザーはクエリを最適化する短いパスを計画します。
プライマリキーに基づくポイントクエリの最適化は、軽量スキーマ変更の unique column ID に依存して列を特定するため、light_schema_change パラメーターを true に設定することをお勧めします。
ポイントクエリには、単一テーブルのキー列に関連する等価条件が含まれている必要があります。 JOIN クエリとネストされたサブクエリはサポートされていません。 WHERE 句は、キー列の値に基づくクエリのみをサポートします。これは、キーと値のペアのクエリと見なすことができます。

プリペアドステートメントの使用

SQL の解析と式の計算のオーバーヘッドを削減するために、ApsaraDB for SelectDB は、クエリアクセス層で MySQL プロトコルと完全に互換性のある prepared statements を提供します。プリペアドステートメントは、プライマリキーに基づいてポイントクエリを実行する場合にのみ使用できます。フロントエンド (FE) で prepared statement 機能が有効になっている場合、SQL ステートメントとその式は事前に計算され、セッションレベルのメモリキャッシュにキャッシュされます。後続のクエリは、キャッシュされたオブジェクトを直接使用できます。 CPU がプライマリキーベースのポイントクエリのパフォーマンスを制限している場合、prepared statement 機能を有効にすると、このようなクエリのパフォーマンスを 4 倍以上向上させることができます。

次の例は、Java Database Connectivity (JDBC) で prepared statement 機能を使用する方法を示しています。

JDBC URL を指定し、サーバーで prepared statement 機能を有効にします。
```
url = jdbc:mysql://127.0.0.1:9030/ycsb?useServerPrepStmts=true
```

プリペアドステートメントを使用します。

// プレースホルダーには `?` を使用し、readStatement は再利用する必要があります
PreparedStatement readStatement = conn.prepareStatement("select * from tbl_point_query where key = ?");
...
readStatement.setInt(1234);
ResultSet resultSet = readStatement.executeQuery();
...
readStatement.setInt(1235);
resultSet = readStatement.executeQuery();
...

行キャッシュ機能の有効化

ApsaraDB for SelectDB は、各ページの特定の列のデータを格納するページレベルのキャッシュ機能を提供します。各ページには、列のデータが格納されます。これは、ページレベルのキャッシュが列に使用されることを示しています。行ストアモードでは、行には複数の列のデータが含まれており、キャッシュは大きなクエリによって削除される可能性があり、ヒット率が低下する可能性があります。ヒット率を高めるために、ApsaraDB for SelectDB は行キャッシュ機能を提供します。行キャッシュ機能は、ApsaraDB for SelectDB の最低使用頻度 (LRU) キャッシュメカニズムを再利用して、十分なメモリ使用量を確保します。行キャッシュ機能は、バックエンド (BE) 構成の次のパラメーターを設定することで有効にできます。

disable_storage_row_cache: 行キャッシュ機能を有効にするかどうかを指定します。デフォルトでは、このパラメーターは false に設定されており、メモリオーバーヘッドを削減します。
row_cache_mem_limit: 行キャッシュが占有できるメモリの最大割合。デフォルト値: 20。これは、メモリの 20% が行キャッシュによって占有される可能性があることを示します。