Lecture du code source Databend : gestion de la configuration

Auteur : Shang Zhuoran (PsiACE), étudiant en master à l'Université des Sciences et Technologies de Macao, stagiaire ingénieur R&D Databend

Commitateur Apache OpenDAL (incubation)

https://github.com/PsiACE

Pour les programmes de serveur de bases de données complexes comme Databend, il est souvent nécessaire de prendre en charge un grand nombre d'options configurables pour aider le personnel d'exploitation et de maintenance à gérer et à régler le système en fonction des besoins réels d'utilisation.

Databend prend actuellement en charge trois méthodes de configuration : ligne de commande, variables d'environnement et fichiers de configuration, avec priorité décroissante.

En général, il est recommandé d'utiliser des fichiers de configuration pour enregistrer et gérer diverses configurations.
Pour les clusters K8S, afin de modifier de manière flexible certaines configurations (telles que les commutateurs de fonctionnalités), l'utilisation de variables d'environnement peut être une forme plus élégante.
La ligne de commande est utilisée pour ajuster quelques configurations conflictuelles dans l'environnement local.

Mappage dans la requête Databend

Quelle databend-queryque soit la forme de configuration, ses options de configuration peuvent presque être considérées comme une arborescence plate du code, c'est-à-dire qu'elles sont fondamentalement conformes à la logique « domaine de configuration » + « élément de configuration » dans le code.

Dans les variables d'environnement et les fichiers de configuration, utilisez serfigpour imbriquer et développer le code, et utilisez-le _comme séparateur.
Il existe de légères différences dans la ligne de commande : d'une part, le délimiteur est utilisé -; d'autre part, certaines options de ligne de commande n'ont pas de champs de configuration liés dans leurs noms.

Afin de mieux comprendre la relation de mappage ici, nous pouvons nous pencher sur une configuration spécifique, et ce qui suit se admin_api_addressconcentrera sur cet élément de configuration.

Pour les variables d'environnement, vous devez utiliser QUERY_ADMIN_API_ADDRESSpour QUERYreprésenter le domaine où se trouve cette configuration, mais ADMIN_API_ADDRESSl'élément de configuration spécifique.
Dans le fichier de configuration, toml est généralement utilisé pour la configuration. [query]Indique le domaine où se trouve la configuration et admin_api_addressconstitue un élément de configuration spécifique.

[query]
...
# Databend Query http address.
# For admin RESET API.
admin_api_address = "0.0.0.0:8081"
...

Vous devez utiliser dans la ligne de commande --admin-api-addresspour la configuration, cet élément n'est pas lié au "domaine de configuration". S'il s'agit de configuration --storage-s3-access-key-id, alors "storage" + "s3" constituent le domaine de configuration et "access-key-id" est l'élément de configuration spécifique.

Après avoir compris comment admin_api_addressconfigurer, entrons le code lié à la configuration pour afficher plus en détail la forme de code de la relation de mappage (située à l'adresse src/query/config/src/config.rs).

pub struct Config {
    ...

    // Query engine config.
    #[clap(flatten)]
    pub query: QueryConfig,
    
    ...
}

/// Query config group.
#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize, Args)]
#[serde(default, deny_unknown_fields)]
pub struct QueryConfig {
    ...
    
    #[clap(long, default_value = "127.0.0.1:8080")]
    pub admin_api_address: String,
    
    ...
}

Étant donné que le code utilise une structure hiérarchique imbriquée, le niveau supérieur est Config, mais admin_api_addressil s'agit pub query: QueryConfigd'un élément de configuration dans . Après avoir été serfigtraité, vous devez utiliser QUERYou [query]représenter le domaine dans lequel il se trouve, et l'élément de configuration reste admin_api_address.

Les noms d'éléments de configuration spécifiques et les valeurs par défaut dans la ligne de commande seront #[clap(long = "<long-name>", default_value = "<value>")]contrôlés) et clapprendront en charge la configuration :

admin_api_addressC'est devenu --admin-api-address.
--storage-s3-access-key-idD'une manière générale, le niveau de code réel est Config-> StorageConfig-> S3StorageConfig-> access_key_id, et il y a des annotations sur les champs #[clap(long = "storage-s3-access-key-id", default_value_t)], vous devez donc les utiliser --storage-s3-access-key-idpour la configuration.

Cartographie dans Databend Meta

databend-metaLe fichier de configuration et la logique de ligne de commande de databend-querysont fondamentalement les mêmes que ceux de . Cependant, les variables d'environnement sont des relations de mappage serfigintégrées serde-envet auto-définies (mais vous pouvez également essayer de comprendre par « domaine de configuration » + « élément de configuration »).

Jetons également un coup d'œil à une configuration spécifique. Ici, nous prenons comme log_direxemple .

Pour les variables d'environnement, vous devez utiliser METASRV_LOG_DIRpour METASRVreprésenter le domaine où se trouve cette configuration, mais LOG_DIRl'élément de configuration spécifique.
Dans le fichier de configuration, cet élément de configuration agit globalement et nécessite uniquement :

log_dir                 = "./.databend/logs1"

--log-dirBien entendu, vous pouvez également le configurer directement sur la ligne de commande .

Déconstruisons son mappage via le code, situé à l'adresse src/meta/service/src/configs/outer_v0.rs.

#[derive(Clone, Debug, Serialize, Deserialize, PartialEq, Eq, Parser)]
#[clap(about, version = &**METASRV_COMMIT_VERSION, author)]
#[serde(default)]
pub struct Config {
    ...
    /// Log file dir
    #[clap(long = "log-dir", default_value = "./.databend/logs")]
    pub log_dir: String,
    ...
}

Les éléments de configuration liés aux fichiers de configuration et aux paramètres de ligne de commande sont Configgérés par la structure et la logique est databend-querycohérente avec , je n'entrerai donc pas dans les détails ici.

Les éléments de configuration des variables d'environnement sont ConfigViaEnvtraités par la structure, comme suit :

/// #[serde(flatten)] doesn't work correctly for env.
/// We should work around it by flatten them manually.
/// We are seeking for better solutions.
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq, Eq)]
#[serde(default)]
pub struct ConfigViaEnv {
    ...
    pub metasrv_log_dir: String,
    ...
}

ConfigLa relation de mappage entre et se situe dans les deux parties de impl From<Config> for ConfigViaEnvet impl Into<Config> for ConfigViaEnv. Pour metasrv_log_dir, il est mappé au log_dirchamp précédent.