Eine konzeptionelle Übersicht über die spaltenbasierte Engine von AlloyDB finden Sie unter Übersicht über die spaltenbasierte Engine von AlloyDB Omni.
Spaltenbasierte Engine aktivieren
Wenn Sie die spaltenbasierte Engine für eine Instanz verwenden möchten, setzen Sie das Flag google_columnar_engine.enabled der Instanz auf on.
Kubernetes
Wenn Sie das Flag google_columnar_engine.enabled auf on setzen möchten, ändern Sie das Manifest Ihres Datenbankclusters, um das Attribut parameters dem Abschnitt primarySpec hinzuzufügen:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "18.3.0"
primarySpec:
parameters:
google_columnar_engine.enabled: "on"
Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.
Größe des Spaltenspeichers konfigurieren
Wenn die spaltenbasierte Engine für eine Instanz aktiviert ist, weist AlloyDB Omni einen Teil des Arbeitsspeichers der Instanz zu, um die spaltenbasierten Daten zu speichern. Wenn Sie Ihrem Spaltenspeicher schnellen RAM zuweisen, kann AlloyDB Omni so schnell wie möglich auf die Spaltendaten zugreifen.
Arbeitsspeicher und Speichercache stellen zusammen die Gesamtkapazität der spaltenbasierten Engine dar.
Arbeitsspeicher konfigurieren
Mit dem Flag google_columnar_engine.memory_size_in_mb können Sie die Zuweisung auf eine feste Größe festlegen.
Kubernetes
Wenn Sie das Flag google_columnar_engine.memory_size_in_mb festlegen möchten, ändern Sie das Manifest Ihres Datenbankclusters, um das Attribut parameters dem Abschnitt primarySpec hinzuzufügen:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "18.3.0"
primarySpec:
parameters:
google_columnar_engine.memory_size_in_mb: "COLUMN_MEMORY_SIZE"
Ersetzen Sie Folgendes:
CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.COLUMN_MEMORY_SIZE: die neue Größe des Spaltenspeichers in Megabyte, z. B.256.
Speicher-Cache konfigurieren
Sie können den Speichercache der spaltenbasierten Engine entweder auf freigegebenen oder zweckbestimmten Geräten konfigurieren.
Kubernetes
Gemeinsam verwendete Geräte
Wenn Sie den Speichercache für Ihre Datenbank auf freigegebenen Geräten aktivieren möchten, ändern Sie das Manifest Ihres Datenbankclusters, um das Attribut columnarSpillToDisk im Abschnitt features des Abschnitts primarySpec hinzuzufügen:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "18.3.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: STORAGE_CACHE_SIZE
ultraFastCache:
cacheSize: ULTRAFAST_CACHE_SIZE
genericVolume:
storageClass: "STORAGE_CLASS_NAME"
...
Ersetzen Sie Folgendes:
CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.STORAGE_CACHE_SIZE: die Größe des spaltenbasierten Speichercaches, z. B.5Gi. Wenn Sie keinen Wert für dieses Feld angeben, werden standardmäßig 5 % des Datenträger-Cache der spaltenorientierten Engine zugewiesen.ULTRAFAST_CACHE_SIZE: die Größe des Cache, z. B.100Gi. Es muss größer alsshared_bufferssein. Dieses Feld ist optional. Wenn Sie den Wert dieses Felds nicht angeben, verwendet AlloyDB Omni den gesamten verbleibenden Speicherplatz auf dem Laufwerk. Dies gilt sowohl für AlloyDB Omni in einem Container als auch in einem Kubernetes-Cluster. Weitere Informationen zu Maßeinheiten finden Sie unter Arbeitsspeicherressourceneinheiten.STORAGE_CLASS_NAME: der Name der Speicherklasse des ultraschnellen Cache-Volumes, z. B.local-storage.
Zweckbestimmte Geräte
Standardmäßig verwendet der Speichercache der spaltenbasierten Engine dieselben Geräte wie der AlloyDB Omni-Datenträger-Cache. Sie können die spaltenbasierte Engine jedoch so konfigurieren, dass sie eigene zweckbestimmte Geräte für ihren Speichercache verwendet. Das hat folgende Gründe:
- Sie benötigen keinen Datenträger-Cache, da sich Ihr primärer Speicher bereits auf leistungsstarken SSDs befindet. In diesem Szenario können Sie einen Speicher-Cache für die spaltenorientierte Engine erstellen, ohne Speicherplatz für einen Datenträger-Cache zuweisen zu müssen.
- Sie möchten verschiedene Speichermedien für Ihren Datenträger-Cache und Ihren spaltenbasierten Engine-Cache verwenden. Sie können beispielsweise eine Standard-SSD für Ihren Datenträger-Cache und eine leistungsstärkere NVMe-SSD für Ihren Cache der spaltenorientierten Engine verwenden.
Generisches Volume verwenden
Wenn Sie ein zweckbestimmtes Gerät für den Speichercache der spaltenbasierten Engine konfigurieren möchten, ändern Sie das Manifest DBCluster, um das Attribut columnarSpillToDisk im Abschnitt features hinzuzufügen. In columnarSpillToDisk können Sie dann einen genericVolume mit einem storageClass angeben, der auf den Speicher verweist, den Sie für den dedizierten Cache der spaltenbasierten Engine verwenden möchten.
Hier ist ein Beispiel für die Konfiguration eines dedizierten 50-Gi-Geräts für den Speicher-Cache der spaltenbasierten Engine mit einer Speicherklasse namens „local-ssd“:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "18.3.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: STORAGE_CACHE_SIZE
genericVolume:
storageClass: "STORAGE_CLASS_NAME"
Ersetzen Sie Folgendes:
CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.STORAGE_CACHE_SIZE: die Größe des spaltenbasierten Speichercaches, z. B.50Gi. Wenn Sie keinen Wert für dieses Feld angeben, werden standardmäßig 5 % des Datenträger-Cache der spaltenorientierten Engine zugewiesen.STORAGE_CLASS_NAME: der Name der Speicherklasse für das dedizierte Cache-Volume der spaltenorientierten Engine, z. B.local-ssd.
Sitzungsspezifisches Volume verwenden
Sie können die spaltenbasierte Engine so konfigurieren, dass sie ein sitzungsspezifisches emptyDir-Volume für ihren Speichercache verwendet. Ein emptyDir-Volume wird erstellt, wenn ein Pod einem Knoten zugewiesen wird, und existiert so lange, wie dieser Pod auf diesem Knoten ausgeführt wird. Wenn ein Pod von einem Knoten entfernt wird, werden die Daten im emptyDir endgültig gelöscht.
Wenn Sie ein emptyDir-Volume für den Cache für spaltenbasierten Speicher konfigurieren möchten, ändern Sie Ihr DBCluster-Manifest, um das Attribut emptyDir dem Abschnitt columnarSpillToDisk hinzuzufügen.
Hier sehen Sie ein Beispiel für die Konfiguration eines sitzungsspezifischen Volumes für den Cache des spaltenorientierten Speichers:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "17.5.0"
primarySpec:
features:
columnarSpillToDisk:
cacheSize: 50Gi
emptyDir: {}
Ersetzen Sie Folgendes:
CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.STORAGE_CACHE_SIZE: die Größe des spaltenbasierten Speichercaches, z. B.50Gi.
Vektorisierte Joins aktivieren
Die spaltenbasierte Engine bietet die Funktion vektorisierter Join, mit der die Leistung von Joins verbessert werden kann, indem die vektorisierte Verarbeitung auf qualifizierte Abfragen angewendet wird.
Nachdem Sie den vektorisierten Join aktiviert haben, kann der AlloyDB-Abfrageplaner den vektorisierten Join-Operator anstelle des Standard-PostgreSQL-Hash-Join-Operators anwenden. Der Planer trifft diese Entscheidung, indem er die Kosten für die Ausführung der Abfrage mit den einzelnen Methoden vergleicht.
Wenn Sie den vektorisierten Join für eine Instanz aktivieren möchten, setzen Sie das Flag google_columnar_engine.enable_vectorized_join der Instanz auf on.
google_columnar_engine.enable_vectorized_join: "on" zum Abschnitt parameters Ihres DBCluster-Manifests hinzu. Weitere Informationen finden Sie unter AlloyDB Omni-Datenbank-Flags konfigurieren.
AlloyDB Omni weist dem vektorisierten Join-Feature standardmäßig einen Thread zu. Sie können die Anzahl der für dieses Feature verfügbaren Threads erhöhen, indem Sie das Flag google_columnar_engine.vectorized_join_threads auf einen größeren Wert setzen. Der Höchstwert ist cpu_count * 2.
Spaltenbasierte Engine manuell aktualisieren
Wenn die spaltenbasierte Engine aktiviert ist, wird der Spaltenspeicher standardmäßig im Hintergrund aktualisiert.
Führen Sie die folgende SQL-Abfrage aus, um die Spalten-Engine manuell zu aktualisieren:
SELECT google_columnar_engine_refresh(relation =>'TABLE_NAME');
Ersetzen Sie TABLE_NAME durch den Namen der Tabelle oder der materialisierten Ansicht, die Sie manuell aktualisieren möchten.
Spaltenbasierte Engine deaktivieren
Wenn Sie die spaltenbasierte Engine für eine Instanz deaktivieren möchten, setzen Sie das Flag google_columnar_engine.enabled auf off.
Kubernetes
Wenn Sie das Flag google_columnar_engine.enabled auf off setzen möchten, ändern Sie das Manifest Ihres Datenbankclusters, um das Attribut parameters dem Abschnitt primarySpec hinzuzufügen:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: CLUSTER_NAME
spec:
databaseVersion: "18.3.0"
primarySpec:
parameters:
google_columnar_engine.enabled: "off"
Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.
Nächste Schritte
Vollständige Liste der Datenbank-Flags für die spaltenbasierte Engine
Probieren Sie das Codelab Schnellere Analyseabfragen mit der spaltenbasierten Engine in AlloyDB Omni aus.