Contraintes sur les paramètres

Vue d’ensemble

Dans ClickHouse, les « contraintes sur les paramètres » désignent les limitations et les règles que vous pouvez leur définir. Ces contraintes permettent de préserver la stabilité, la sécurité et le comportement prévisible de votre base de données.

Définition des contraintes

Les contraintes sur les paramètres peuvent être définies dans la section profiles du fichier de configuration user.xml. Elles empêchent les utilisateurs de modifier certains paramètres à l’aide de l’instruction SET. Les contraintes sont définies comme suit :

<profiles>
  <user_name>
    <constraints>
      <setting_name_1>
        <min>lower_boundary</min>
      </setting_name_1>
      <setting_name_2>
        <max>upper_boundary</max>
      </setting_name_2>
      <setting_name_3>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
      </setting_name_3>
      <setting_name_4>
        <readonly/>
      </setting_name_4>
      <setting_name_5>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <changeable_in_readonly/>
      </setting_name_5>
      <setting_name_6>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <disallowed>value1</disallowed>
        <disallowed>value2</disallowed>
        <disallowed>value3</disallowed>
        <changeable_in_readonly/>
      </setting_name_6>
    </constraints>
  </user_name>
</profiles>

Si l’utilisateur tente d’enfreindre les contraintes, une exception est levée et le paramètre reste inchangé.

Types de contraintes

ClickHouse prend en charge plusieurs types de contraintes :

min
max
disallowed
readonly (avec l’alias const)
changeable_in_readonly

Les contraintes min et max définissent les bornes inférieure et supérieure d’un paramètre numérique, et peuvent être utilisées conjointement. La contrainte disallowed permet de spécifier une ou plusieurs valeurs qui ne doivent pas être autorisées pour un paramètre donné. La contrainte readonly ou const indique que l’utilisateur ne peut pas modifier du tout le paramètre correspondant. Le type de contrainte changeable_in_readonly permet aux utilisateurs de modifier le paramètre dans la plage min/max même si le paramètre readonly est défini sur 1 ; autrement, les paramètres ne peuvent pas être modifiés en mode readonly=1.

changeable_in_readonly n’est pris en charge que si settings_constraints_replace_previous est activé :

<access_control_improvements>
  <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
</access_control_improvements>

Ne rendez pas `readonly` modifiable en mode lecture seule

Gardez readonly en dehors de la liste changeable_in_readonly dans chaque profil, y compris dans les profils que vous n’affectez à personne : n’importe quelle session peut sélectionner un profil par son nom.

Ne marquez pas readonly lui-même comme changeable_in_readonly. Si vous le faites, une session démarrée avec readonly = 1 peut exécuter SET readonly = 0 et retrouver ainsi la possibilité d’exécuter les requêtes d’écriture que ses privilèges existants autorisent déjà, à moins que la même contrainte n’interdise également 0. Ce point concerne chaque profil que vous définissez, et pas seulement ceux que vous affectez :

SET profile n’est pas soumis à un contrôle d’accès : n’importe quelle session peut donc sélectionner n’importe quel profil par son nom. Un profil reste accessible même si vous ne l’affectez à personne, bien que les modifications qu’il applique restent soumises aux contraintes déjà actives dans cette session.
En HTTP, les requêtes GET sont forcées à readonly = 2 uniquement lorsque la valeur effective serait autrement 0. Ainsi, un profil qui définit readonly = 1 mais autorise aussi la modification de readonly en mode lecture seule réduit à néant cette protection, car une requête GET peut le repasser à 0 et écrire.

Plusieurs profils de contraintes

S’il y a plusieurs profils actifs pour un utilisateur, les contraintes sont fusionnées. Le processus de fusion dépend de settings_constraints_replace_previous :

true (recommandé) : les contraintes d’un même paramètre sont remplacées lors de la fusion, de sorte que la dernière contrainte est utilisée et que toutes les précédentes sont ignorées. Cela inclut les champs non définis dans la nouvelle contrainte.
false (par défaut) : les contraintes d’un même paramètre sont fusionnées de telle sorte que chaque type de contrainte non défini est repris du profil précédent et que chaque type de contrainte défini est remplacé par la valeur du nouveau profil.

Contraintes et paramètre `compatibility`

Le paramètre compatibility remplace les paramètres que l’utilisateur n’a pas définis par les valeurs par défaut d’une version précédente. Il n’applique jamais une valeur que les contraintes refusent : un paramètre conserve sa valeur par défaut lorsque l’ancienne valeur par défaut se situe hors de sa plage min/max, fait partie de ses valeurs disallowed, ou lorsque le paramètre est const. Il en va de même pour un paramètre appartenant à un niveau que allow_feature_tier désactive. Le paramètre readonly ne restreint pas compatibility de cette manière : il détermine si une requête peut, ou non, définir compatibility. Les paramètres MergeTree ne tiennent compte que du paramètre compatibility du profil par défaut, qui fournit les valeurs par défaut de toutes les tables à l’échelle du serveur. Là aussi, un paramètre conserve sa valeur par défaut lorsqu’une contrainte préfixée par merge_tree_ du profil par défaut, ou allow_feature_tier, refuse l’ancienne valeur par défaut.

Mode lecture seule

Le mode lecture seule est activé par le paramètre readonly, à ne pas confondre avec le type de contrainte readonly. Lorsque readonly = 1, un paramètre qui serait normalement refusé peut malgré tout être modifié si une contrainte changeable_in_readonly l’autorise. Pour la signification des valeurs de ce paramètre, consultez la référence des settings ; pour savoir quelles classes de requête chaque valeur autorise, et comment l’HTTP interface la définit, consultez les permissions pour les requêtes.

Exemple

Supposons que users.xml contienne les lignes suivantes :

<profiles>
  <default>
    <max_memory_usage>10000000000</max_memory_usage>
    <force_index_by_date>0</force_index_by_date>
    ...
    <constraints>
      <max_memory_usage>
        <min>5000000000</min>
        <max>20000000000</max>
      </max_memory_usage>
      <force_index_by_date>
        <readonly/>
      </force_index_by_date>
    </constraints>
  </default>
</profiles>

Les requêtes suivantes renverront toutes une exception :

SET max_memory_usage=20000000001;
SET max_memory_usage=4999999999;
SET force_index_by_date=1;

Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be greater than 20000000000.
Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be less than 5000000000.
Code: 452, e.displayText() = DB::Exception: Setting force_index_by_date should not be changed.

Le profil default est traité de manière particulière : toutes les contraintes définies pour le profil default deviennent les contraintes par défaut et s’appliquent donc à tous les utilisateurs jusqu’à ce qu’elles soient explicitement remplacées pour ces utilisateurs.