Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, você encontra uma visão geral do mecanismo colunar oferecido pelo AlloyDB para PostgreSQL e aprende a usá-lo.
O mecanismo colunar do AlloyDB acelera o processamento de consulta SQL de verificações, junções e agregações fornecendo estes componentes:
Um armazenamento de colunas que contém dados de tabela e de visualização materializada para colunas selecionadas, reorganizados em um formato orientado a colunas.
Um planejador de consultas e um mecanismo de execução colunares para oferecer suporte ao uso do repositório de colunas em consultas.
O mecanismo colunar pode ser usado na instância principal, em uma instância do pool de leitura ou em ambas.
Também é possível usar a colunação automática para analisar sua carga de trabalho e preencher automaticamente o repositório de colunas com as colunas que oferecem o melhor ganho de performance.
Para usar o mecanismo colunar com uma consulta específica, todas as colunas nos fragmentos dessa consulta, como junções e verificações, precisam estar no repositório de colunas.
Por padrão, o mecanismo colunar é configurado para usar 30% da memória da instância.
Dependendo da sua carga de trabalho, do uso de memória e se você tiver um pool de leitura configurado,
é possível reduzir a alocação de memória do mecanismo colunar na instância
principal e alocar mais memória para a instância do pool de leitura.
Para ver e monitorar o uso da memória pelo mecanismo
colunar, consulte Ver o uso da memória do repositório de colunas.
Para modificar o tamanho da memória usada pelo repositório de colunas, consulte
Configurar o tamanho do repositório de colunas.
Para encontrar o tamanho de memória recomendado para o mecanismo colunar da sua instância, consulte
Recomendar tamanho da memória do repositório de colunas.
Tipos de consultas que se beneficiam do mecanismo colunar
Algumas consultas podem se beneficiar do mecanismo colunar. Confira a seguir uma lista de operações e padrões de consulta que se beneficiam mais do mecanismo colunar:
Verificações de tabela
Ele tem filtros seletivos, como cláusulas WHERE.
Ela usa um pequeno número de colunas de uma tabela ou visualização materializada maior.
Ele usa expressões como LIKE, SUBSTR ou "TRIM".
Funções de agregação
Elas usam apenas as seguintes expressões: SUM, MIN, MAX, AVG e COUNT.
Eles estão no início da consulta de uma verificação colunar.
Elas não estão agrupadas ou são colunas de agrupamento.
ORDER-BY e SORT: somente quando ORDER-BY ou SORT está nos resultados da verificação das colunas acessadas pelo mecanismo colunar.
LIMIT: somente se o operador estiver no início da consulta
de uma verificação colunar e antes de qualquer operador SORT ou GROUP BY.
INNER HASH JOIN somente se as chaves usadas forem colunas e nenhum qualificador de junção for usado.
Junções seletivas somente se elas estiverem no início da consulta de uma varredura colunar.
É possível acompanhar o que está no repositório de colunas usando a visualização g_columnar_relations. Depois que as colunas forem adicionadas, use a instrução EXPLAIN para verificar o uso do mecanismo colunar em consultas SQL.
Quais dados podem ser adicionados ao repositório de colunas
Há algumas limitações nos tipos e fontes de dados que podem ser usados ao adicionar colunas ao repositório de colunas.
Tipos de dados compatíveis
O mecanismo colunar aceita apenas colunas com os seguintes tipos de dados integrados:
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
O mecanismo colunar ignora qualquer tentativa de adicionar manualmente colunas com tipos de dados não compatíveis ao repositório de colunas.
Fontes de dados sem suporte
O mecanismo colunar não é compatível com tabelas ou visualizações materializadas com os seguintes atributos como fontes de dados:
Tabelas particionadas não folha
Tabelas externas
Tabelas ou visualizações com menos de 5.000 linhas
Limitações do mecanismo colunar
Se você estiver executando uma consulta analítica em uma coluna que tem um índice, o otimizador do AlloyDB poderá usar o armazenamento de linhas.
As colunas adicionadas manualmente ao repositório não são removidas automaticamente. Para forçar a remoção de
colunas adicionadas manualmente, use
google_columnar_engine_drop()
na sua instância.
A columnarização automática pode adicionar e remover colunas dinamicamente com base no uso da consulta.
Nem todos os tipos de dados são compatíveis com o mecanismo colunar. Para conferir os tipos de dados compatíveis, consulte Tipos de dados compatíveis.
Atualizações frequentes de linhas invalidam os dados de colunas. Para validar uma tabela ou uma visualização materializada no armazenamento colunar, reduza a frequência de atualização ou programe atualizações mais frequentes do mecanismo colunar.
Compare as colunas invalid_block_count e total_block_count em g_columnar_relations para verificar se a tabela ou visualização foi afetada. Se você fizer mudanças frequentes ou em grande volume na tabela ou visualização, o invalid_block_count será alto.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]