Hologres:Set up data orientation

Escolher um formato de armazenamento

Use esta tabela para identificar o formato adequado à sua carga de trabalho. O padrão é orientado a colunas.

Defina o formato de armazenamento

Especifique a propriedade orientation durante a criação da tabela.

A partir da V2.1:

CREATE TABLE <table_name> (...) WITH (orientation = '[column | row | row,column]');

Todas as versões:

BEGIN;
CREATE TABLE <table_name> (...);
CALL set_table_property('<table_name>', 'orientation', '[column | row | row,column]');
COMMIT;

Como funciona

Os três formatos diferem na disposição dos dados em disco e nos índices construídos. Essa diferença determina a eficiência para cada tipo de consulta.

No formato orientado a colunas, os valores de cada coluna ficam armazenados contiguamente. Uma consulta como SELECT SUM(revenue) FROM orders WHERE region = 'APAC' lê apenas as colunas revenue e region, ignorando as demais. Isso reduz a E/S em consultas analíticas que acessam um pequeno subconjunto de colunas em muitas linhas.

Já no formato orientado a linhas, os valores de cada linha ficam contíguos. Uma consulta como SELECT * FROM orders WHERE id = '1001' faz uma única busca por PK e recupera toda a linha em uma varredura. Esse método é eficiente quando você precisa de todas as colunas de uma linha específica imediatamente.

O formato híbrido mantém uma cópia orientada a linhas e outra orientada a colunas para cada registro. O otimizador de consultas escolha a cópia com melhor desempenho com base no plano de execução. Toda operação de escrita deve ser concluída com sucesso em ambas as cópias antes de retornar.

CREATE TABLE public.tbl_col (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT NOT NULL,
    in_time TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (id)
)
WITH (
    orientation = 'column',
    clustering_key = 'class',
    bitmap_columns = 'name',
    event_time_column = 'in_time'
);

SELECT * FROM public.tbl_col WHERE id = '3333';
SELECT id, class, name FROM public.tbl_col WHERE id < '3333' ORDER BY id;

BEGIN;
CREATE TABLE public.tbl_col (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT NOT NULL,
    in_time TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (id)
);
CALL set_table_property('public.tbl_col', 'orientation', 'column');
CALL set_table_property('public.tbl_col', 'clustering_key', 'class');
CALL set_table_property('public.tbl_col', 'bitmap_columns', 'name');
CALL set_table_property('public.tbl_col', 'event_time_column', 'in_time');
COMMIT;

SELECT * FROM public.tbl_col WHERE id = '3333';
SELECT id, class, name FROM public.tbl_col WHERE id < '3333' ORDER BY id;

CREATE TABLE public.tbl_row (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT,
    PRIMARY KEY (id)
)
WITH (
    orientation = 'row',
    clustering_key = 'id',
    distribution_key = 'id'
);

-- PK-based point query
SELECT * FROM public.tbl_row WHERE id = '1111';

-- Multiple key lookup
SELECT * FROM public.tbl_row WHERE id IN ('1111', '2222', '3333');

BEGIN;
CREATE TABLE public.tbl_row (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT,
    PRIMARY KEY (id)
);
CALL set_table_property('public.tbl_row', 'orientation', 'row');
CALL set_table_property('public.tbl_row', 'clustering_key', 'id');
CALL set_table_property('public.tbl_row', 'distribution_key', 'id');
COMMIT;

-- PK-based point query
SELECT * FROM public.tbl_row WHERE id = '1111';

-- Multiple key lookup
SELECT * FROM public.tbl_row WHERE id IN ('1111', '2222', '3333');

-- Avoid: clustering_key differs from PK
CREATE TABLE public.tbl_row (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT,
    PRIMARY KEY (id)
)
WITH (
    orientation = 'row',
    clustering_key = 'name',  -- different from PK (id)
    distribution_key = 'id'
);

BEGIN;
CREATE TABLE public.tbl_row (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT,
    PRIMARY KEY (id)
);
CALL set_table_property('public.tbl_row', 'orientation', 'row');
CALL set_table_property('public.tbl_row', 'clustering_key', 'name');  -- different from PK (id)
CALL set_table_property('public.tbl_row', 'distribution_key', 'id');
COMMIT;

CREATE TABLE public.tbl_row_col (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT NOT NULL,
    PRIMARY KEY (id)
)
WITH (
    orientation = 'row,column',
    distribution_key = 'id',
    clustering_key = 'class',
    bitmap_columns = 'name'
);

SELECT * FROM public.tbl_row_col WHERE id = '2222';                         -- PK point query
SELECT * FROM public.tbl_row_col WHERE class = 'Class Two';                 -- Non-PK point query
SELECT * FROM public.tbl_row_col WHERE id = '2222' AND class = 'Class Two'; -- General OLAP query

BEGIN;
CREATE TABLE public.tbl_row_col (
    id TEXT NOT NULL,
    name TEXT NOT NULL,
    class TEXT,
    PRIMARY KEY (id)
);
CALL set_table_property('public.tbl_row_col', 'orientation', 'row,column');
CALL set_table_property('public.tbl_row_col', 'distribution_key', 'id');
CALL set_table_property('public.tbl_row_col', 'clustering_key', 'class');
CALL set_table_property('public.tbl_row_col', 'bitmap_columns', 'name');
COMMIT;

SELECT * FROM public.tbl_row_col WHERE id = '2222';                         -- PK point query
SELECT * FROM public.tbl_row_col WHERE class = 'Class Two';                 -- Non-PK point query
SELECT * FROM public.tbl_row_col WHERE id = '2222' AND class = 'Class Two'; -- General OLAP query

Exemplos de uso

Os exemplos abaixo usam a sintaxe WITH (orientation = ...) da V2.1. Para a sintaxe equivalente com set_table_property, compatível com todas as versões, consulte as seções anteriores.

-- Column-oriented table (default)
CREATE TABLE tbl_col (
    a INT NOT NULL,
    b TEXT NOT NULL
)
WITH (
    orientation = 'column'
);

-- Row-oriented table
CREATE TABLE public.tbl_row (
    a INTEGER NOT NULL,
    b TEXT NOT NULL,
    PRIMARY KEY (a)
)
WITH (
    orientation = 'row'
);

-- Hybrid table (row + column)
CREATE TABLE tbl_col_row (
    pk TEXT NOT NULL,
    col1 TEXT,
    col2 TEXT,
    col3 TEXT,
    PRIMARY KEY (pk)
)
WITH (
    orientation = 'row,column'
);

Perguntas frequentes

Se o armazenamento híbrido suporta consultas pontuais por PK e consultas OLAP, por que não usá-lo sempre?

O armazenamento híbrido gera maior overhead porque os dados são gravados duas vezes: uma no formato de linha e outra no formato de coluna. Use-o apenas quando uma única tabela realmente precisar de buscas por PK com alto QPS e consultas analíticas. Para tabelas exclusivamente OLAP, o armazenamento orientado a colunas é mais eficiente. Para tabelas focadas apenas em buscas por PK, o armazenamento orientado a linhas evita esse custo adicional.

É possível alterar o formato de armazenamento de uma tabela após a criação?

Não. A conversão direta não é suportada. Para mudar o formato, crie a tabela com o novo valor de orientation.

Por que o armazenamento orientado a linhas suporta mais colunas que o orientado a colunas?

Tabelas orientadas a colunas criam múltiplos índices por padrão, incluindo índices bitmap para colunas de string. À medida que o número de colunas aumenta, esses índices elevam o overhead de armazenamento e tornam as escritas mais lentas. Tabelas orientadas a linhas indexam apenas a chave primária, portanto o custo por coluna é muito menor.

O que acontece se uma tabela orientada a linhas ultrapassar 3.000 colunas ou uma tabela orientada a colunas ultrapassar 300 colunas?

Esses são limites recomendados, não rígidos. Excedê-los degrada o desempenho: tabelas orientadas a colunas com muitas colunas sofrem com alto custo de indexação e escrita; tabelas orientadas a linhas com excesso de colunas aumentam o tamanho da linha e reduzem o throughput de consultas pontuais. Mantenha-se dentro dos limites recomendados para cargas de produção.

Próximos passos

Para obter orientações sobre como combinar a escolha do formato de armazenamento com outras propriedades da tabela — como chave de distribuição, chave de clustering e particionamento — com base nos seus padrões de consulta, consulte o Guia de otimização de criação de tabelas baseado em cenários.