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 sectionprofiles 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 :
Types de contraintes
ClickHouse prend en charge plusieurs types de contraintes :minmaxdisallowedreadonly(avec l’aliasconst)changeable_in_readonly
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é :Ne rendez pas readonly modifiable en mode lecture seule
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 profilen’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
GETsont forcées àreadonly = 2uniquement lorsque la valeur effective serait autrement0. Ainsi, un profil qui définitreadonly = 1mais autorise aussi la modification dereadonlyen mode lecture seule réduit à néant cette protection, car une requêteGETpeut le repasser à0et é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 desettings_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.
Mode lecture seule
Le mode lecture seule est activé par le paramètrereadonly, à 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 queusers.xml contienne les lignes suivantes :
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.Contraintes sur les paramètres de MergeTree
Il est possible de définir des contraintes pour les paramètres de MergeTree. Ces contraintes sont appliquées lors de la création d’une table utilisant le moteur MergeTree ou lors de la modification de ses paramètres de stockage. Le nom d’un paramètre de MergeTree doit être précédé du préfixemerge_tree_ lorsqu’il est
référencé dans la section <constraints>.
Exemple
Vous pouvez interdire la création de nouvelles tables avec unstorage_policy spécifié explicitement