Auditez votre algorithme de base de données de partitionnement

Grace à Communauté ShardingSphere examen et commentaires continus pour développer des fonctionnalités telles que le partage de données et le fractionnement en lecture/écriture, notre équipe a constaté que certains utilisateurs créent de nombreux fragments lors de l’utilisation de la fonction de partage de données.

Dans de tels cas, il peut y avoir 1 000 tables physiques correspondant à une table logique de partitionnement, ce qui perturbe les utilisateurs.

Par exemple, un SELECT * FROM t_order conduira à un itinéraire complet, ce qui n’est évidemment pas le cas pour OLTP. Ce SQL peut être placé dans un autre Proxy pour éviter de bloquer d’autres requêtes.

Cependant, si les utilisateurs ne sont pas familiers avec Proxy ou comment écrire un where condition et que vous ne savez pas que le partitionnement n’est pas pris en charge dans cette condition, une route complète est toujours requise.

Une route complète peut réduire les performances du proxy et même entraîner l’échec d’une requête raisonnable. Imaginez qu’il y ait 1 000 partitions dans une base de données physique. S’ils sont exécutés en parallèle, 1 000 connexions sont nécessaires, et s’ils sont en série, la requête peut entraîner un délai d’attente. Pour cette raison, les utilisateurs de la communauté ont demandé si la demande déraisonnable pouvait être interceptée directement.

Notre équipe a examiné la question pendant un certain temps. Une option consiste simplement à bloquer l’opération de routage complet. Cela nécessite une vérification du code et l’ajout d’un commutateur au fichier de configuration. D’un autre côté, si l’utilisateur a ultérieurement besoin de définir une table en lecture seule ou si l’opération de mise à jour doit porter une limit, cela signifie-t-il que le code et la configuration changent à nouveau ? Cette approche va évidemment à l’encontre de la logique pluggable de Proxy.

En réponse aux problèmes ci-dessus, le récent Apache ShardingSphere 5.2.0 fournit aux utilisateurs un audit pour la fonction de partitionnement SQL. L’audit peut être soit une opération d’interception, soit une opération statistique. Semblable aux algorithmes de partitionnement et de génération de clé unique, l’algorithme d’audit est orienté plug-in, défini par l’utilisateur et configurable.

[ Related read 5 new improvements in Apache ShardingSphere ]

Ensuite, je développerai la logique de mise en œuvre pour auditer le partage de données avec des exemples SQL spécifiques.

Audit pour l’interface de partitionnement

L’entrée de l’audit d’Apache ShardingSphere se trouve dans le org.apache.shardingsphere.infra.executor.check.SQLCheckEngine classe, qui invoquera la check méthode de la SQLChecker interface. Actuellement, l’audit ShardingSphere contient un audit pour l’autorisation (vérifier le nom d’utilisateur et le mot de passe) et un audit pour le sharding.

Cet exemple se concentre sur l’interface parent implémentée dans le ShardingAuditChecker d’audit pour le partage.

Vous pouvez apprendre rapidement ses principes de fonctionnement en consultant le check code de org.apache.shardingsphere.sharding.checker.audit.ShardingAuditChecker.

public interface ShardingAuditAlgorithm extends ShardingSphereAlgorithm {
    
    /**
     * Sharding audit algorithm SQL check.
     *
     * @param sqlStatementContext SQL statement context
     * @param parameters SQL parameters
     * @param grantee grantee
     * @param database database
     * @return SQL check result
     */
    SQLCheckResult CHECK(SQLStatementContext<?> sqlStatementContext, List<Object> parameters, Grantee grantee, ShardingSphereDatabase DATABASE);
}

Cette méthode obtient les stratégies d’audit de toutes les tables de partitionnement impliquées et appelle les algorithmes d’audit configurés dans chaque stratégie d’audit de table de partitionnement. Une exception est affichée à l’utilisateur si un algorithme d’audit échoue.

Certains utilisateurs peuvent se demander ce disableAuditNames fait ici. L’audit de partitionnement permet également aux utilisateurs d’ignorer ce processus. Dans certains cas, les utilisateurs peuvent avoir besoin d’exécuter du SQL qui aurait dû être bloqué par l’audit, et ils sont conscients de l’impact de ce SQL.

Les utilisateurs peuvent utiliser le Hint: disableAuditNames pour ignorer l’interception d’audit, qui sera décrite avec des exemples pratiques plus tard. Les administrateurs proxy peuvent configurer allowHintDisable pour contrôler s’il faut autoriser les utilisateurs à ignorer ce processus. La valeur par défaut est trueindiquant qu’un saut basé sur l’indice est autorisé.

Audit pour l’algorithme de partitionnement

L’interface d’audit pour l’algorithme de partitionnement org.apache.shardingsphere.sharding.spi.ShardingAuditAlgorithm est hérité de la classe SPI ShardingSphereAlgorithm. Il hérite type et props propriétés et définit ses propres check méthode. Si vous souhaitez personnaliser votre algorithme d’audit, implémentez simplement l’interface et ajoutez-la à INF.services.

public interface ShardingAuditAlgorithm extends ShardingSphereAlgorithm {
    
    /**
     * Sharding audit algorithm SQL check.
     *
     * @param sqlStatementContext SQL statement context
     * @param parameters SQL parameters
     * @param grantee grantee
     * @param database database
     * @return SQL check result
     */
    SQLCheckResult CHECK(SQLStatementContext<?> sqlStatementContext, List<Object> parameters, Grantee grantee, ShardingSphereDatabase DATABASE);
}

Apache ShardingSphere implémente un audit général pour l’algorithme de partitionnement org.apache.shardingsphere.sharding.algorithm.audit.DMLShardingConditionsShardingAuditAlgorithmà savoir l’instruction SQL mentionnée ci-dessus qui intercepte la route complète.

L’algorithme prend des décisions en déterminant si la condition de partitionnement est null. Bien sûr, il n’interceptera pas les tables de diffusion et les tables non partitionnées.

public final class DMLShardingConditionsShardingAuditAlgorithm implements ShardingAuditAlgorithm {
    
    @Getter
    private Properties props;
    
    @Override
    public void init(final Properties props) {
        this.props = props;
    }
    
    @SuppressWarnings({"rawtypes", "unchecked"})
    @Override
    public SQLCheckResult CHECK(final SQLStatementContext<?> sqlStatementContext, final List<Object> parameters, final Grantee grantee, final ShardingSphereDatabase DATABASE) {
        IF (sqlStatementContext.getSqlStatement() instanceof DMLStatement) {
            ShardingRule rule = DATABASE.getRuleMetaData().getSingleRule(ShardingRule.class);
            IF (rule.isAllBroadcastTables(sqlStatementContext.getTablesContext().getTableNames())
                    || sqlStatementContext.getTablesContext().getTableNames().stream().noneMatch(rule::isShardingTable)) {
                RETURN NEW SQLCheckResult(TRUE, "");
            }
            ShardingConditionEngine shardingConditionEngine = ShardingConditionEngineFactory.createShardingConditionEngine(sqlStatementContext, DATABASE, rule);
            IF (shardingConditionEngine.createShardingConditions(sqlStatementContext, parameters).isEmpty()) {
                RETURN NEW SQLCheckResult(FALSE, "Not allow DML operation without sharding conditions");
            }
        }
        RETURN NEW SQLCheckResult(TRUE, "");
    }
    
    @Override
    public String getType() {
        RETURN "DML_SHARDING_CONDITIONS";
    }
}

J’aimerais introduire un autre audit pour l’algorithme de partitionnement : LimitRequiredShardingAuditAlgorithm. Cet algorithme peut intercepter SQL sans porter de limit dans le update et delete opérations.

Comme cet algorithme est moins universel, il n’est actuellement pas intégré à Apache ShardingSphere. Comme vous pouvez le voir, il est très facile d’implémenter un algorithme personnalisé, c’est pourquoi l’audit pour le framework de partitionnement est nécessaire. Grâce à son architecture orientée plugin, ShardingSphere bénéficie d’une grande évolutivité.

public final class LimitRequiredShardingAuditAlgorithm implements ShardingAuditAlgorithm {
    
    @Getter
    private Properties props;
    
    @Override
    public void init(final Properties props) {
        this.props = props;
    }
    
    @SuppressWarnings({"rawtypes", "unchecked"})
    @Override
    public SQLCheckResult CHECK(final SQLStatementContext<?> sqlStatementContext, final List<Object> parameters, final Grantee grantee, final ShardingSphereDatabase DATABASE) {
        IF (sqlStatementContext instanceof UpdateStatementContext && !((MySQLUpdateStatement) sqlStatementContext.getSqlStatement()).getLimit().isPresent()) {
            RETURN NEW SQLCheckResult(FALSE, "Not allow update without limit");
        }
        IF (sqlStatementContext instanceof DeleteStatementContext && !((MySQLDeleteStatement) sqlStatementContext.getSqlStatement()).getLimit().isPresent()) {
            RETURN NEW SQLCheckResult(FALSE, "Not allow delete without limit");
        }
        RETURN NEW SQLCheckResult(TRUE, "");
    }
    
    @Override
    public String getType() {
        RETURN "LIMIT_REQUIRED";
    }
}

Utiliser l’audit pour le partage

L’audit pour le partitionnement nécessite que vous configuriez une stratégie d’audit pour les tables logiques. Pour vous aider à démarrer rapidement, sa configuration est la même que celle de l’algorithme de partitionnement et du générateur de valeur de clé de partitionnement.

Il existe une définition d’algorithme et une définition de stratégie, et une stratégie d’audit par défaut est également prise en charge. Si la stratégie d’audit est configurée dans la table logique, elle n’affecte que cette table logique.

Si defaultAuditStrategy est configuré dans la table logique, il prend effet pour toutes les tables logiques sous la règle de partitionnement. Auditors sont similaires à ShardingAlgorithms, auditStrategy à databaseStrategyet defaultAuditStrategy à defaultDatabaseStrategy ou defaultTableStrategy.

Veuillez vous référer à l’exemple suivant. Seule la configuration de l’audit pour le sharding est affichée. Vous devez configurer vous-même l’algorithme de partitionnement et la source de données.

rules:
  - !SHARDING
    TABLES:
      t_order:
        actualDataNodes: ds_${0..1}.t_order_${0..1}
        auditStrategy:
          auditorNames:
            - sharding_key_required_auditor
          allowHintDisable: TRUE
    defaultAuditStrategy:
      auditorNames:
        - sharding_key_required_auditor
      allowHintDisable: TRUE
    auditors:
      sharding_key_required_auditor:
        TYPE: DML_SHARDING_CONDITIONS

Étape 1: Exécute une opération de requête. Une erreur s’affiche lorsque la stratégie d’audit pour intercepter la route de la base de données complète est configurée.

mysql> SELECT * FROM t_order;
ERROR 13000 (44000): SQL CHECK failed, error message: NOT allow DML operation WITHOUT sharding conditions

Étape 2: Ajouter HINT. Le nom du HINT est /* ShardingSphere hint: disableAuditNames */,et disableAuditNames est suivi de la auditorsNames configuré dans la commande précédente.

Si plusieurs noms existent, séparez-les par des espaces tels que/* ShardingSphere hint: disableAuditNames=auditName1 auditName2*/. Après avoir utilisé HINTvous pouvez voir que l’opération SQL est exécutée avec succès.

mysql> /* ShardingSphere hint: disableAuditNames=sharding_key_required_auditor */ SELECT * FROM t_order;
+----------+---------+------------+--------+
| order_id | user_id | address_id | STATUS |
+----------+---------+------------+--------+
|       30 |      20 |         10 | 20     |
|       32 |      22 |         10 | 20     |
+----------+---------+------------+--------+
2 ROWS IN SET (0.01 sec)

Noter: HINT vous oblige à modifier le server.yaml configuration du Proxy. De plus, si vous utilisez un terminal MySQL pour vous connecter directement à Proxy, vous devez ajouter le -c propriété—sinon, HINT les commentaires seront filtrés du terminal MySQL et ne seront pas analysés par Proxy sur le backend.

rules:
  - !SQL_PARSER
    sqlCommentParseEnabled: TRUE
    sqlStatementCache:
      initialCapacity: 2000
      maximumSize: 65535
    parseTreeCache:
      initialCapacity: 128
      maximumSize: 1024
props:
  proxy-hint-enabled: TRUE
mysql -uroot -proot -h127.0.0.1 -P3307  -c

DistSQL avec audit pour le partitionnement

Comme vous pouvez le voir sur notes de versionApache ShardingSphere 5.2.0 prend en charge les éléments suivants DistSQL avec audit pour la fonction de partage :

CREATE SHARDING AUDITOR
ALTER SHARDING AUDITOR
SHOW SHARDING AUDIT ALGORITHMS

The following DistSQL will be supported IN future releases:
DROP SHARDING AUDITOR
SHOW UNUSED SHARDING AUDIT ALGORITHMS
CREATE SHARDING TABLE RULE # including AUDIT_STRATEGY

Cet article a présenté le fonctionnement de l’audit pour le partage avec des exemples spécifiques. Je pense que vous avez déjà une compréhension de base de cette fonction et que vous pouvez l’utiliser chaque fois que vous en avez besoin ou utiliser un algorithme personnalisé.

Vous êtes également invités à soumettre des algorithmes généraux à la communauté. Si vous avez des idées à contribuer ou si vous rencontrez des problèmes avec votre ShardingSphere, n’hésitez pas à les publier sur GitHub.

Cet article est initialement paru sur ShardingSphere 5.2.0 : l’audit de partitionnement intercepte les demandes déraisonnables dans les scénarios multi-fragments et est republié avec autorisation.