AlloyDB カラム型エンジンのコンセプトの概要については、AlloyDB Omni カラム型エンジンの概要をご覧ください。
カラム型エンジンを有効にする
インスタンスでカラム型エンジンを使用するには、インスタンスの google_columnar_engine.enabled フラグを on に設定します。
Kubernetes
google_columnar_engine.enabled フラグを on に設定するには、データベース クラスタ マニフェストを変更して、primarySpec セクションに parameters 属性を追加します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
parameters:
google_columnar_engine.enabled: "on"
CLUSTER_NAME は、実際のデータベース クラスタの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。
カラム型ストアのサイズを構成する
インスタンスでカラム型エンジンが有効になっている間、AlloyDB Omni はインスタンスのメモリの一部を割り振り、カラム型データを保存します。高速 RAM をカラムストア専用にすることで、AlloyDB Omni はカラム型データに可能な限り高速にアクセスできます。
メモリ キャッシュとストレージ キャッシュを合わせた容量が、カラム型エンジンの総容量を表します。
メモリを構成する
割り当てを固定サイズに設定するには、google_columnar_engine.memory_size_in_mb フラグを使用します。
Kubernetes
google_columnar_engine.memory_size_in_mb フラグを設定するには、データベース クラスタ マニフェストを変更して、primarySpec セクションに parameters 属性を追加します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
parameters:
google_columnar_engine.memory_size_in_mb: "COLUMN_MEMORY_SIZE"
次のように置き換えます。
CLUSTER_NAME: データベース クラスタの名前。これは、作成時に宣言したデータベース クラスタ名と同じです。COLUMN_MEMORY_SIZE: カラム型ストレージの新しいサイズ(メガバイト単位)。例:256。
ストレージ キャッシュを構成する
カラム型エンジンのストレージ キャッシュは、共有デバイスまたは専用デバイスで構成できます。
Kubernetes
共有デバイス
共有デバイスでデータベースのストレージ キャッシュを有効にするには、データベース クラスタ マニフェストを変更して、primarySpec セクションの features セクションに columnarSpillToDisk 属性を追加します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: STORAGE_CACHE_SIZE
ultraFastCache:
cacheSize: ULTRAFAST_CACHE_SIZE
genericVolume:
storageClass: "STORAGE_CLASS_NAME"
...
次のように置き換えます。
CLUSTER_NAME: データベース クラスタの名前。これは、作成時に宣言したデータベース クラスタ名と同じです。STORAGE_CACHE_SIZE: カラム型ストレージ キャッシュのサイズ(例:5Gi)。このフィールドに値を指定しない場合、デフォルトではディスク キャッシュの 5% がカラム型エンジンに割り当てられます。ULTRAFAST_CACHE_SIZE: キャッシュのサイズ(例:100Gi)。shared_buffersよりも大きい値にしてください。このフィールドは省略可能です。このフィールドの値を指定しない場合、AlloyDB Omni はディスク上の残りのスペースをすべて使用します。これは、コンテナ内の AlloyDB Omni と Kubernetes クラスタの両方に適用されます。測定単位の詳細については、メモリリソース ユニットをご覧ください。STORAGE_CLASS_NAME: 超高速キャッシュ ボリュームのストレージ クラスの名前(例:local-storage)。
専用デバイス
デフォルトでは、カラム型エンジンのストレージ キャッシュは AlloyDB Omni ディスク キャッシュと同じデバイスを共有します。ただし、次の理由により、ストレージ キャッシュに独自の専用デバイスを使用するようにカラム型エンジンを構成できます。
- プライマリ ストレージがすでに高性能 SSD 上にあるため、ディスク キャッシュは必要ありません。このシナリオでは、ディスク キャッシュのスペースを割り当てることなく、カラム型エンジン ストレージ キャッシュを作成できます。
- ディスク キャッシュとカラム型エンジン キャッシュに異なるストレージ メディアを使用する場合。たとえば、ディスク キャッシュには標準の SSD を使用し、列エンジン キャッシュには高パフォーマンスの NVMe SSD を使用できます。
汎用ボリュームを使用する
カラム型エンジン ストレージ キャッシュ専用のデバイスを構成するには、DBCluster マニフェストを変更して、features セクションに columnarSpillToDisk 属性を追加します。columnarSpillToDisk 内で、専用のカラム型エンジン キャッシュに使用するストレージを指す storageClass を含む genericVolume を指定できます。
local-ssd という名前のストレージ クラスを使用して、カラム型エンジンのストレージ キャッシュ用に 50 Gi の専用デバイスを構成する例は次のとおりです。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: STORAGE_CACHE_SIZE
genericVolume:
storageClass: "STORAGE_CLASS_NAME"
次のように置き換えます。
CLUSTER_NAME: データベース クラスタの名前。これは、作成時に宣言したデータベース クラスタ名と同じです。STORAGE_CACHE_SIZE: カラム型ストレージ キャッシュのサイズ(例:50Gi)。このフィールドに値を指定しない場合、デフォルトではディスク キャッシュの 5% がカラム型エンジンに割り当てられます。STORAGE_CLASS_NAME: 専用カラム型エンジン キャッシュ ボリュームのストレージ クラスの名前(例:local-ssd)。
エフェメラル ボリュームを使用する
ストレージ キャッシュにエフェメラル emptyDir ボリュームを使用するようにカラム型エンジンを構成できます。emptyDir Volume は、Pod がノードに割り当てられると作成され、その Pod がノードで実行されている限り存続します。Pod がノードから削除されると、emptyDir のデータは完全に削除されます。
カラム型ストレージ キャッシュ用に emptyDir ボリュームを構成するには、DBCluster マニフェストを変更して、columnarSpillToDisk セクションに emptyDir 属性を追加します。
次に、列形式ストレージ キャッシュ用にエフェメラル ボリュームを構成する例を示します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: 50Gi
emptyDir: {}
次のように置き換えます。
CLUSTER_NAME: データベース クラスタの名前。これは、作成時に宣言したデータベース クラスタ名と同じです。STORAGE_CACHE_SIZE: カラム型ストレージ キャッシュのサイズ(例:50Gi)。
ベクトル化結合を有効にする
カラム型エンジンには、ベクトル化結合機能があります。この機能を使用すると、対象となるクエリにベクトル化処理を適用することで、結合のパフォーマンスを向上できます。
ベクトル化結合を有効にすると、AlloyDB クエリ プランナーは、標準の PostgreSQL ハッシュ結合演算子ではなく、ベクトル化結合演算子を適用できます。プランナーは、各方法でクエリを実行するコストを比較して、この決定を行います。
インスタンスでベクトル化結合を有効にするには、インスタンスの google_columnar_engine.enable_vectorized_join フラグを on に設定します。
インスタンスにこのフラグを設定するには、ALTER SYSTEM PostgreSQL コマンドを実行します。
ALTER SYSTEM SET google_columnar_engine.enable_vectorized_join = 'on';
AlloyDB Omni は、デフォルトでベクトル化された結合機能に 1 つのスレッドを割り当てます。google_columnar_engine.vectorized_join_threads フラグを大きい値に設定すると、この機能で使用できるスレッド数を増やすことができます。最大値は cpu_count * 2 です。
カラム型エンジンを手動で更新する
デフォルトでは、カラム型エンジンが有効になっていると、バックグラウンドでカラム型ストアが更新されます。
カラム型エンジンを手動で更新するには、次の SQL クエリを実行します。
SELECT google_columnar_engine_refresh(relation =>'TABLE_NAME');
TABLE_NAME は、手動で更新するテーブルまたはマテリアライズド ビューの名前に置き換えます。
カラム型エンジンを無効にする
インスタンスでカラム型エンジンを無効にするには、google_columnar_engine.enabled フラグを off に設定します。
Kubernetes
google_columnar_engine.enabled フラグを off に設定するには、データベース クラスタ マニフェストを変更して、primarySpec セクションに parameters 属性を追加します。
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
parameters:
google_columnar_engine.enabled: "off"
CLUSTER_NAME は、実際のデータベース クラスタの名前に置き換えます。これは、作成時に宣言したデータベース クラスタ名と同じです。
次のステップ
カラム型エンジン データベース フラグの一覧を確認する。
Google Codelab チュートリアルの AlloyDB Omni でカラム型エンジンを使用して分析クエリを高速化する に沿って学習する。