Hologres:Set up data orientation

Choisir un format de stockage

Utilisez ce tableau pour identifier le format adapté à votre charge de travail. Le format orienté colonne est celui par défaut.

Définir le format de stockage

Spécifiez la propriété orientation lors de la création d'une table.

À partir de la version V2.1 :

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

Toutes versions :

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

Fonctionnement

Ces trois formats diffèrent par la disposition des données sur le disque et par les index qu'ils génèrent. Ces caractéristiques déterminent l'efficacité des différents types de requête.

Le format orienté colonne stocke les valeurs de chaque colonne de manière contiguë. Une requête telle que SELECT SUM(revenue) FROM orders WHERE region = 'APAC' lit uniquement les colonnes revenue et region en ignorant toutes les autres. Cette approche réduit les opérations d'E/S pour les requêtes analytiques qui ne concernent qu'un sous-ensemble restreint de colonnes sur un grand nombre de lignes.

Le format orienté ligne stocke les valeurs de chaque ligne de manière contiguë. Une requête comme SELECT * FROM orders WHERE id = '1001' effectue une recherche unique via la clé primaire et récupère la ligne entière en une seule analyse. Ce procédé s'avère efficace lorsque vous avez besoin d'accéder immédiatement à toutes les colonnes d'une ligne spécifique.

Le format hybride conserve à la fois une copie orientée ligne et une copie orientée colonne pour chaque ligne. L'optimiseur de requêtes sélectionne la copie offrant les meilleures performances selon le plan d'exécution. Chaque opération d'écriture doit aboutir dans les deux copies avant que l'opération ne soit considérée comme terminée.

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

Exemples d'utilisation

Les exemples suivants utilisent la syntaxe WITH (orientation = ...) disponible à partir de la version V2.1. Pour la syntaxe équivalente set_table_property compatible avec toutes les versions, reportez-vous aux sections précédentes.

-- 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'
);

FAQ

Si le stockage hybride prend en charge à la fois les requêtes ponctuelles sur clé primaire et les requêtes OLAP, pourquoi ne pas toujours l'utiliser ?

Le stockage hybride entraîne un surcoût de stockage plus élevé, car les données sont écrites deux fois : une fois au format ligne et une fois au format colonne. Utilisez le stockage hybride uniquement lorsqu'une même table a réellement besoin de combiner des recherches par clé primaire à haut débit (QPS) et des requêtes analytiques. Pour les tables dédiées exclusivement à l'OLAP, le stockage orienté colonne est plus efficace. Pour les tables servant uniquement aux recherches par clé primaire, le stockage orienté ligne permet d'éviter ce surcoût.

Puis-je modifier le format de stockage d'une table après sa création ?

Non. La conversion directe n'est pas prise en charge. Pour changer le format de stockage, vous devez recréer la table avec la nouvelle valeur orientation.

Pourquoi le stockage orienté ligne prend-il en charge plus de colonnes que le stockage orienté colonne ?

Les tables orientées colonne construisent plusieurs index par défaut, notamment des index bitmap pour les colonnes de type chaîne. À mesure que le nombre de colonnes augmente, ces index alourdissent le stockage et ralentissent les écritures. Les tables orientées ligne n'indexent que la clé primaire, ce qui réduit considérablement le coût par colonne.

Que se passe-t-il si une table orientée ligne dépasse 3 000 colonnes ou si une table orientée colonne dépasse 300 colonnes ?

Il s'agit de limites recommandées, non de limites absolues. Les dépasser dégrade les performances : les tables orientées colonne avec un grand nombre de colonnes subissent un surcoût de stockage des index et d'écriture élevé ; les tables orientées ligne avec un très grand nombre de colonnes voient leur taille de ligne augmenter, ce qui réduit le débit des requêtes ponctuelles. Respectez les limites recommandées pour vos environnements de production.

Étapes suivantes

Pour obtenir des conseils sur la combinaison du choix du format de stockage avec d'autres propriétés de table, telles que la clé de distribution, la clé de clustering et le partitionnement, en fonction de vos modèles de requête, consultez le Guide d'optimisation de la création de tables basé sur les scénarios.