Hologres:Dynamic Table support and limitations

Limites

• Utilisation des ressources

  À partir de Hologres V3.1, les nouvelles tables utilisent par défaut des ressources serverless pour exécuter les tâches d'actualisation. Si l'instance n'a pas activé les ressources serverless, elle bascule automatiquement vers les ressources locales. Les tables créées dans Hologres V3.0 continuent d'utiliser les ressources initialement spécifiées et ne basculent pas automatiquement vers les ressources serverless.

• Limites relatives aux tables de base

  • Seules les tables internes Hologres, les tables externes Paimon et les autres Dynamic Tables sont prises en charge comme tables de base. Pour créer une Dynamic Table, vous devez disposer des autorisations SELECT sur la table de base.

  • Par défaut, Hologres V3.1 consomme les données de la table de base de manière incrémentielle via la méthode stream. Comparée à la méthode Binlog, la méthode stream offre de meilleures performances et n'entraîne aucun coût de stockage supplémentaire. Si votre table de base utilisait la méthode Binlog avant la version 3.1, nous vous recommandons de désactiver rapidement le Binlog afin d'éviter une consommation de stockage additionnelle. Pour désactiver le Binlog, consultez la section Subscribe to Hologres Binlog.

  • Dans Hologres V3.0, lors de la création d'une Dynamic Table en mode d'actualisation incrémentielle, le Binlog doit être activé pour la table de base. Cela n'est toutefois pas requis pour les tables de dimension. Pour plus d'informations sur l'activation du Binlog, consultez la section Subscribe to Hologres Binlog.

• Limites relatives aux requêtes

  • Scénarios pris en charge

    • Toute expression scalaire

    • Conditions WHERE

    • Sous-requêtes

    • Expressions de table communes (CTE)

    • GROUP BY

    • CUBE

    • GROUPING SETS

    • Clauses HAVING

    • Filtres d'agrégation

    • UNION ALL

    • UNNEST

  • Scénarios non pris en charge

    • Fonctions de fenêtrage

    • Sous-requêtes IN

    • EXISTS ou NOT EXISTS

    • EXCEPT ou INTERSECT

    • ORDER BY

    • LIMIT ou OFFSET

  • Jointure multi-tables :

    • Hologres V3.0 prend uniquement en charge les équijointures (INNER JOIN ou LEFT JOIN) sur les tables de dimension, et ces jointures doivent utiliser la syntaxe FOR SYSTEM_TIME AS OF PROCTIME(). Les jointures double-stream multi-tables ne sont pas prises en charge. Pour plus d'informations, consultez la section Lookup join statements.

      Remarque

      Une jointure de recherche associe chaque enregistrement à la dernière version des données de la table de dimension au moment du traitement. Si les données de la table de dimension changent après la jointure, les données précédemment jointes ne sont pas mises à jour.

    • À partir de Hologres V3.0.26, les jointures double-stream multi-tables sont prises en charge. Elles équivalent aux jointures OLAP standard ou aux jointures double-stream dans Flink et incluent INNER JOIN ainsi que LEFT/RIGHT/FULL OUTER JOIN. Pour plus d'informations, consultez la section CREATE DYNAMIC TABLE.

  • Fonctions : les fonctions d'agrégation telles que COUNT, SUM, MIN/MAX et COUNT DISTINCT sont prises en charge. Les fonctions s'exécutant sur le moteur Parallel Query Engine (PQE) ne sont pas prises en charge. Le tableau ci-dessous décrit les autres fonctions prises en charge.

    Fonction	Syntaxe	Exemple	Version prise en charge
    RB_BUILD_AGG	RB_BUILD_AGG(<column>) Remarque Le paramètre column prend en charge les types de données INT32 et INT64. Pour plus d'informations, consultez la section RoaringBitmap functions.	CREATE DYNAMIC TABLE daily_uv PARTITION BY list (day) WITH ( freshness = '5 minutes', refresh_mode = 'incremental') AS SELECT day, game_id, gameversion, RB_BUILD_AGG(user_id) AS user_rb FROM base_table GROUP BY day, game_id, gameversion;	V3.1 et versions ultérieures
    STRING_AGG	STRING_AGG([DISTINCT] column_expr, const_expr) Remarque Types de données : column_expr doit être de type TEXT, CHAR ou VARCHAR. const_expr doit être une constante TEXT. La clause ORDER BY n'est pas prise en charge. À partir de Hologres V3.1.10, STRING_AGG([DISTINCT] est pris en charge.	CREATE DYNAMIC TABLE string_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, STRING_AGG(gameversion, ',') AS gameversion_list FROM base_table GROUP BY day;	V3.1 et versions ultérieures À partir de V3.1.10, STRING_AGG([DISTINCT] est pris en charge.
    ARRAY_AGG	ARRAY_AGG([DISTINCT] expr) Remarque Types de données : le paramètre expr prend en charge les types BOOL, tous les types numériques, TEXT et BYTEA. La clause ORDER BY n'est pas prise en charge. À partir de Hologres V3.1.10, ARRAY_AGG([DISTINCT] est pris en charge.	CREATE DYNAMIC TABLE array_agg_test_dt WITH ( freshness = '3 minutes', refresh_mode = 'incremental') AS SELECT day, ARRAY_AGG(gameversion) AS gameversion_list FROM base_table GROUP BY day;	V3.1 et versions ultérieures À partir de Hologres V3.1.10, ARRAY_AGG([DISTINCT] est pris en charge.
    ANY_VALUE	Dans une requête d'agrégation contenant une clause GROUP BY, cette fonction renvoie de manière non déterministe une valeur issue de l'une des lignes de chaque groupe. ANY_VALUE(expr) La fonction ANY_VALUE accepte uniquement les types de données INT et BINARY.	CREATE DYNAMIC TABLE dt_t0 WITH ( -- Properties of the dynamic table freshness = '1 minutes', auto_refresh_mode = 'auto' ) AS SELECT a, any_value(c), SUM(b) FROM t0 GROUP BY a;	V3.1.5 et versions ultérieures

  • À partir de Hologres V3.1, vous pouvez configurer une Dynamic Table en tant que partition logique. Les propriétés de partition associées et les paramètres de gestion correspondants sont également pris en charge.

Fonctionnalités prises en charge

• Tables de base : la fonctionnalité est identique à celle des tables Hologres standard. Vous pouvez utiliser des tables internes Hologres et des tables externes, telles que celles issues de MaxCompute, Data Lake Formation (DLF) et Paimon, comme tables de base. Vous devez disposer des autorisations nécessaires sur la table de base pour créer une Dynamic Table. Pour plus d'informations, consultez la section Dynamic Table permissions.

• Requêtes : toutes les fonctions, expressions SQL et types de données actuellement pris en charge par Hologres sont également disponibles en mode d'actualisation complète.

• Ressources d'actualisation : par défaut, les tâches d'actualisation utilisent des ressources serverless. Vous pouvez également configurer les tâches pour qu'elles utilisent les ressources de votre instance actuelle.

Limites

• Vous ne pouvez pas modifier le mode d'actualisation pour passer de l'actualisation complète à l'actualisation incrémentielle.

• Dans Hologres V3.0, si vous créez une VIEW sur une Dynamic Table en mode d'actualisation complète, le processus d'actualisation de la Dynamic Table échoue. Ce problème est résolu dans les versions V3.1 et ultérieures. Nous vous recommandons de mettre à niveau votre instance.

Limites relatives aux Dynamic Tables

• Votre instance Hologres doit être en version 3.0 ou ultérieure.

• Limites relatives aux propriétés des tables : vous ne pouvez pas définir de clé primaire ni de valeurs de champ par défaut. Le moteur déduit automatiquement l'index de la table, mais vous pouvez également le définir manuellement selon vos besoins métier.

• Seuls les modes d'actualisation complète et incrémentielle sont pris en charge. Les fonctionnalités disponibles et les limites varient selon le mode. Pour plus de détails, consultez les sections Actualisation complète et Actualisation incrémentielle.

Limites relatives aux opérations DDL et DML