Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie einen Überblick über das spaltenorientierte Modul, das AlloyDB for PostgreSQL bietet, und eine Anleitung zur Verwendung.
Die spaltenbasierte Engine von AlloyDB beschleunigt die Verarbeitung von Scans, Joins und Aggregaten in SQL-Abfrage durch die folgenden Komponenten:
Ein Spaltenspeicher, der Tabellen- und Ansichtsdaten für ausgewählte Spalten enthält, die in ein spaltenorientiertes Format umorganisiert wurden.
Ein spaltenorientierter Abfrageplaner und eine spaltenorientierte Ausführungs-Engine zur Unterstützung der Verwendung des Spaltenspeichers in Abfragen.
Die spaltenorientierte Engine kann für die primäre Instanz, eine Lesepoolinstanz oder beide verwendet werden.
Sie können auch die automatische Spaltenformatierung verwenden, um Ihre Arbeitslast zu analysieren und den Spaltenspeicher automatisch mit den Spalten zu füllen, die die beste Leistungssteigerung bieten.
Wenn Sie die spaltenorientierte Engine für eine bestimmte Abfrage verwenden möchten, müssen alle Spalten in den Fragmenten dieser Abfrage, z. B. Joins und Scans, im Spaltenspeicher vorhanden sein.
Standardmäßig verwendet die spaltenorientierte Engine 30% des Arbeitsspeichers Ihrer Instanz.
Je nach Arbeitslast, Arbeitsspeichernutzung und Konfiguration eines Lesepools können Sie die Arbeitsspeicherzuweisung für die spaltenorientierte Engine auf Ihrer primären Instanz reduzieren und der Lesepoolinstanz mehr Arbeitsspeicher zuweisen.
Informationen zum Ansehen und Überwachen der Arbeitsspeichernutzung durch die Spalten-Engine finden Sie unter Arbeitsspeichernutzung des Spaltenspeichers ansehen.
Informationen zum Ändern der vom Spaltenspeicher verwendeten Speichergröße finden Sie unter Größe des Spaltenspeichers konfigurieren.
Die empfohlene Arbeitsspeichergröße für die spaltenbasierte Engine für Ihre Instanz finden Sie unter Empfohlene Arbeitsspeichergröße für den Spaltenspeicher.
Abfragetypen, die von der spaltenbasierten Engine profitieren
Bestimmte Abfragen können von der spaltenbasierten Engine profitieren. Im Folgenden finden Sie eine Liste der Vorgänge und ihrer Abfragemuster, die am meisten von der spaltenorientierten Engine profitieren:
Tabellenscans
Sie verfügt über selektive Filter wie WHERE-Klauseln.
Es werden nur wenige Spalten aus einer größeren Tabelle oder materialisierten Ansicht verwendet.
Sie verwendet Ausdrücke wie LIKE, SUBSTR oder „TRIM“.
Aggregatfunktionen
Sie verwenden nur die folgenden Ausdrücke: SUM, MIN, MAX, AVG und COUNT.
Sie stehen am Anfang der Abfrage eines spaltenorientierten Scans.
Sie sind nicht gruppiert oder werden nach Spalten gruppiert.
ORDER-BY und SORT: nur, wenn ORDER-BY oder SORT in den Scanergebnissen von Spalten enthalten ist, auf die über die spaltenorientierte Engine zugegriffen wird.
LIMIT: nur, wenn sich der Operator am Anfang der Anfrage eines spaltenweisen Scans befindet und vor allen SORT- oder GROUP BY-Operatoren steht.
INNER HASH JOIN nur, wenn die verwendeten Schlüssel Spalten sind und keine Join-Qualifizierer verwendet werden.
Selektive Joins nur, wenn sich die Joins am Anfang der Abfrage eines spaltenweisen Scans befinden.
Weitere Informationen dazu, welche Abfragen am besten mit der spaltenorientierten Engine funktionieren, ob und wie die spaltenorientierte Engine von einer Abfrage verwendet wurde, finden Sie unter Verwendung der spaltenorientierten Engine mit EXPLAIN überprüfen.
Spaltenorientierte Engine verwenden
So verwenden Sie die spaltenorientierte Engine in einer AlloyDB-Instanz:
Mit der Ansicht g_columnar_relations können Sie nachvollziehen, was sich im Spaltenspeicher befindet. Nachdem Spalten hinzugefügt wurden, können Sie mit der Anweisung EXPLAIN die Verwendung der spaltenorientierten Engine in SQL-Abfragen prüfen.
Welche Daten können dem Spaltenspeicher hinzugefügt werden?
Es gibt einige Einschränkungen hinsichtlich der Datentypen und Datenquellen, die Sie verwenden können, wenn Sie dem Spaltenspeicher Spalten hinzufügen.
Unterstützte Datentypen
Die spaltenorientierte Engine unterstützt nur Spalten mit den folgenden integrierten Datentypen:
array
bigint
boolean
bytea
char
date
decimal
double precision
enum
float4
float8
integer
json
jsonb
numeric
real
serial
short
smallint
text
timestamp
timestamptz
uuid
varchar
vector
Die spaltenorientierte Engine ignoriert alle Versuche, dem Spaltenspeicher manuell Spalten mit nicht unterstützten Datentypen hinzuzufügen.
Nicht unterstützte Datenquellen
Die spaltenorientierte Engine unterstützt keine Tabellen oder materialisierten Ansichten mit den folgenden Attributen als Datenquellen:
Nicht-Leaf-partitionierte Tabellen
Fremde Tabellen
Tabellen oder Ansichten mit weniger als 5.000 Zeilen
Einschränkungen der spaltenbasierten Engine
Wenn Sie eine Analyseabfrage für eine Spalte mit einem Index ausführen, kann der AlloyDB-Optimierer den Zeilenspeicher verwenden.
Spalten, die dem Spaltenspeicher manuell hinzugefügt wurden, werden nicht automatisch entfernt. Wenn Sie manuell hinzugefügte Spalten erzwingen möchten, verwenden Sie google_columnar_engine_drop() in Ihrer Instanz.
Bei der automatischen Spaltenorientierung können Spalten basierend auf der Abfragenutzung dynamisch hinzugefügt und entfernt werden.
Nicht alle Datentypen werden von der spaltenorientierten Engine unterstützt. Informationen zu den unterstützten Datentypen finden Sie unter Unterstützte Datentypen.
Häufige Aktualisierungen von Zeilen machen Spaltendaten ungültig. Wenn Sie eine Tabelle oder eine materialisierte Ansicht im spaltenorientierten Speicher validieren möchten, können Sie entweder die Aktualisierungshäufigkeit verringern oder die Aktualisierungen der spaltenorientierten Engine häufiger planen.
Sie können die Spalten invalid_block_count und total_block_count in g_columnar_relations vergleichen, um zu prüfen, ob Ihre Tabelle oder Ansicht betroffen ist. Wenn Sie häufig oder in großem Umfang Änderungen an Ihrer Tabelle oder Ansicht vornehmen, ist der invalid_block_count hoch.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-25 (UTC)."],[[["\u003cp\u003eThe AlloyDB columnar engine accelerates SQL query processing for scans, joins, and aggregates by storing selected table and materialized-view data in a column-oriented format, and is supported on the primary instance and/or read pool.\u003c/p\u003e\n"],["\u003cp\u003eQueries with selective filters, aggregation functions (SUM, MIN, MAX, AVG, COUNT), and certain joins and sorts are among those that benefit from the columnar engine, as long as the related columns are in the columnar store.\u003c/p\u003e\n"],["\u003cp\u003eThe columnar engine can be enabled, and columns can be added to its store either manually or via auto-columnarization, which analyzes your workload to automatically identify columns for optimization.\u003c/p\u003e\n"],["\u003cp\u003eThe columnar engine supports a limited set of data types, does not work with certain data sources like non-leaf partitioned tables, and frequent updates can invalidate columnar data.\u003c/p\u003e\n"],["\u003cp\u003eThe columnar engine's memory allocation can be configured, with the default being 30% of instance memory, and you can monitor memory usage and verify columnar engine utilization using \u003ccode\u003eg_columnar_relations\u003c/code\u003e and \u003ccode\u003eEXPLAIN\u003c/code\u003e.\u003c/p\u003e\n"]]],[],null,["# About the AlloyDB columnar engine\n\nThis page provides an overview of the columnar engine that\nAlloyDB for PostgreSQL offers and shows how to use it.\n\nThe AlloyDB columnar engine accelerates SQL query\nprocessing of scans, joins, and aggregates by providing these components:\n\n- A column store that contains table and materialized-view data for selected\n columns, reorganized into a column-oriented format.\n\n- A columnar query planner and execution engine to support\n use of the column store in queries.\n\nThe columnar engine can be used on the primary instance, a read pool instance, or both.\nYou can also use [auto-columnarization](/alloydb/docs/columnar-engine/manage-content-recommendations#default-schedule)\nto analyze your workload and automatically populate the column store with the columns\nthat provide the best performance gain.\n\nTo use the columnar engine with a specific query, all columns in that query fragments,\nsuch as joins and scans, must be in the column store.\n\nBy default, the columnar engine is set to use 30% of your instance's memory.\nDepending on your workload, memory usage, and if you have a read pool configured,\nyou may choose to reduce the columnar engine memory allocation on your primary\ninstance and allocate more memory to the read pool instance.\nTo view and monitor memory usage by the columnar\nengine, see [View column store memory usage](/alloydb/docs/columnar-engine/monitor-tune#usage).\nTo modify the memory size used by the column store, see\n[Configure the size of the column store](/alloydb/docs/columnar-engine/configure#configure).\nTo find the recommended columnar engine memory size for your instance, see\n[Recommend column store memory size](/alloydb/docs/columnar-engine/manage-content-recommendations#recommend-populate).\n\nQuery types that benefit from the columnar engine\n-------------------------------------------------\n\nCertain queries can benefit from the columnar engine. The following is a list of\noperations and their query patterns that benefit most from the columnar engine:\n\n- **Table scans**\n\n - It has selective filters, such as `WHERE` clauses.\n - It uses a small number of columns from a larger table or materialized view.\n - It uses expressions such as `LIKE`, `SUBSTR`, or \\`TRIM.\n- **Aggregation functions**\n\n - They only use the following expressions: `SUM`, `MIN`, `MAX`, `AVG`, and `COUNT`.\n - They are at the beginning of the query of a columnar scan.\n - They are ungrouped, or are grouped-by columns.\n- **`ORDER-BY`** and **`SORT`** : only when the `ORDER-BY` or `SORT` is on the scan results of columns accessed from the columnar engine.\n\n- **`LIMIT`** : only if the operator is at the beginning of the query\n of a columnar scan and is before any `SORT` or `GROUP BY` operators.\n\n- **`INNER HASH JOIN`** only if the keys used are columns and no join\n qualifiers are used.\n\n- **Selective joins** only if the joins are at the beginning of the query\n of a columnar scan.\n\nFor more information on which queries work best with the columnar engine, whether\nthe columnar engine was used by a query, and how it was used, see\n[Verify usage of the columnar engine using `EXPLAIN`](/alloydb/docs/columnar-engine/monitor-tune#explain).\n\nHow to use the columnar engine\n------------------------------\n\nTo use the columnar engine in an AlloyDB instance, you perform these\nhigh-level steps:\n\n1. [Enable the engine](/alloydb/docs/columnar-engine/enable) on the instance.\n\n Enabling the engine is a one-time operation and requires a restart.\n2. Add columns to the column store.\n\n To add columns to the column store, use one of the following methods:\n - [Use auto-columnarization](/alloydb/docs/columnar-engine/manage-content-recommendations),\n which analyzes your workload and automatically adds columns.\n\n - [Add the columns manually](/alloydb/docs/columnar-engine/manage-content-manually)\n based on your knowledge of the workload on the databases in the instance.\n\n3. You can track what's in the column store using [the `g_columnar_relations`\n view](/alloydb/docs/columnar-engine/monitor-tune#relations-view), and, after\n columns have been added, you can use [the `EXPLAIN`\n statement](/alloydb/docs/columnar-engine/monitor-tune#explain) to verify usage of\n the columnar engine in SQL queries.\n\nFor detailed instructions on how to use the columnar engine, see\n[Configure the columnar engine](/alloydb/docs/columnar-engine/configure).\n\nWhat data you can add to the column store\n-----------------------------------------\n\nThere are some limitations on the data types and data sources you can use\nwhen adding columns to the column store.\n\n### Supported data types\n\nThe columnar engine supports only columns with the following built-in\ndata types:\n\n- `array`\n- `bigint`\n- `boolean`\n- `bytea`\n- `char`\n- `date`\n- `decimal`\n- `double precision`\n- `enum`\n- `float4`\n- `float8`\n- `integer`\n- `json`\n- `jsonb`\n- `numeric`\n- `real`\n- `serial`\n- `short`\n- `smallint`\n- `text`\n- `timestamp`\n- `timestamptz`\n- `uuid`\n- `varchar`\n- `vector` ([Preview](https://cloud.google.com/products#product-launch-stages))\n\nThe columnar engine ignores any attempts to manually add columns with unsupported\ndata types to the column store.\n\n### Unsupported data sources\n\nThe columnar engine does not support tables or materialized views with the\nfollowing attributes as data sources:\n\n- Non-leaf partitioned tables\n\n- Foreign tables\n\n- Tables or views with fewer than 5,000 rows\n\nColumnar Engine limitations\n---------------------------\n\n- If you're running an analytical query on a column that has an index, the AlloyDB optimizer may choose to use row-store.\n- Columns added manually to the column store aren't automatically removed. To force remove manually added columns, use [`google_columnar_engine_drop()`](/alloydb/docs/columnar-engine/manage-content-manually#drop-by-function) on your instance.\n- Auto-columnarization may dynamically add and remove columns based on query usage.\n- Not all data types are supported by the columnar engine. To see supported data types, see [supported data types](#supported-data-types).\n- Frequent updates to rows invalidate columnar data. To validate a table or a\n materialized view in the columnar store, you can either reduce the update\n frequency, or\n [schedule more frequent the columnar engine refreshes](/alloydb/docs/columnar-engine/manage-content-recommendations#auto-schedule).\n\n You can compare the `invalid_block_count` and `total_block_count` columns in\n [g_columnar_relations](/alloydb/docs/columnar-engine/monitor-tune#relations-view)\n to check if your table or view is impacted. If you have a frequent or high-volume changes to your table or view, the `invalid_block_count` will be high.\n\nWhat's next\n-----------\n\n- [Configure the columnar engine](/alloydb/docs/columnar-engine/configure).\n\n- [Configure the columnar engine on AlloyDB Omni](/alloydb/docs/omni/columnar-engine/configure).\n\n- Learn how to [accelerate analytical queries using the AlloyDB columnar engine](https://www.cloudskillsboost.google/paths/22/course_templates/642/labs/501234)."]]
