ApsaraDB for SelectDB:Colocation join

+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | D | | A | | B | | C | | D |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+

CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
    "colocate_with" = "group1"
);

Groupes de colocation inter-bases de données

Pour co-localiser des tables situées dans différentes bases de données, préfixez le nom du groupe avec __global__ :

CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
    "colocate_with" = "__global__group1"
);

Un CG global n'appartient à aucune base de données spécifique et son nom est globalement unique au sein du cluster.

-- Create tbl1 and tbl2 in the same CG, then run:
DESC SELECT * FROM tbl1 INNER JOIN tbl2 ON (tbl1.k2 = tbl2.k2);

| 2:HASH JOIN                                      |
| |  join op: INNER JOIN                           |
| |  colocate: true                                |
| |    `tbl1`.`k2` = `tbl2`.`k2`                   |

| 2:HASH JOIN                                       |
| |  join op: INNER JOIN (BROADCAST)                |
| |  colocate: false, reason: group is not stable   |
| |    `tbl1`.`k2` = `tbl2`.`k2`                    |
...
| 3:EXCHANGE                                        |

Consulter les informations du CG

Exécutez la commande suivante pour lister tous les CG du cluster (le rôle administrateur est requis) :

SHOW PROC '/colocation_group';

Exemple de sortie :

+-------------+--------------+--------------+------------+----------------+----------+----------+
| GroupId     | GroupName    | TableIds     | BucketsNum | ReplicationNum | DistCols | IsStable |
+-------------+--------------+--------------+------------+----------------+----------+----------+
| 10005.10008 | 10005_group1 | 10007, 10040 | 10         | 3              | int(11)  | true     |
+-------------+--------------+--------------+------------+----------------+----------+----------+

Pour examiner le mappage bucket-BE d'un CG spécifique :

SHOW PROC '/colocation_group/10005.10008';

Exemple de sortie :

+-------------+------------+
| BucketIndex | BackendIds |
+-------------+------------+
| 0           | 10004      |
| 1           | 10003      |
| 2           | 10002      |
| 3           | 10003      |
| 4           | 10002      |
| 5           | 10003      |
| 6           | 10003      |
| 7           | 10003      |
+-------------+------------+

Le rôle administrateur est nécessaire pour exécuter les commandes SHOW PROC. Les utilisateurs standard ne peuvent pas exécuter ces commandes.

Modifier la propriété de colocation d'une table

Pour déplacer une table vers un autre CG :

ALTER TABLE tbl SET ("colocate_with" = "group2");

• Si la table n'appartient encore à aucun CG, SelectDB vérifie le schéma et l'ajoute au CG spécifié (en créant le CG si nécessaire).

• Si la table fait déjà partie d'un CG, SelectDB la retire du CG actuel pour l'ajouter au CG spécifié (en créant le CG si nécessaire).

Pour supprimer la propriété de colocation d'une table :

ALTER TABLE tbl SET ("colocate_with" = "");

Supprimer une table de colocation

Lorsque vous exécutez DROP TABLE, la table est déplacée vers la corbeille où elle reste pendant un jour avant suppression définitive. Une fois la dernière table d'un CG supprimée définitivement, le CG est automatiquement retiré.

Contraintes liées aux modifications de schéma

Lorsque vous ajoutez des partitions (ADD PARTITION) ou modifiez le nombre de réplicas d'une table de colocation, SelectDB valide la modification par rapport au CGS. Si la modification enfreint les contraintes du CGS, SelectDB la rejette.

Paramètres de configuration FE

Les paramètres de configuration frontend (FE) suivants contrôlent le comportement du colocation join. Vous pouvez modifier dynamiquement disable_colocate_relocate et disable_colocate_balance à l'aide de ADMIN SET CONFIG. Pour consulter les valeurs actuelles ou obtenir des informations sur la syntaxe de configuration, exécutez HELP ADMIN SHOW CONFIG; et HELP ADMIN SET CONFIG;.

API RESTful HTTP

SelectDB expose des endpoints d'API RESTful HTTP pour consulter et gérer les CG. Tous les endpoints sont servis par les nœuds FE à l'adresse fe_host:fe_http_port et nécessitent le rôle administrateur.

Consulter toutes les informations de colocation :

GET /api/colocate

Renvoie les informations de colocation au format JSON :

{
    "msg": "success",
    "code": 0,
    "data": {
        "infos": [
            ["10003.12002", "10003_group1", "10037, 10043", "1", "1", "int(11)", "true"]
        ],
        "unstableGroupIds": [],
        "allGroupIds": [{"dbId": 10003, "grpId": 12002}]
    },
    "count": 0
}

Marquer un CG comme Stable :

DELETE /api/colocate/group_stable?db_id=10005&group_id=10008

Return value: 200

Marquer un CG comme Unstable :

POST /api/colocate/group_stable?db_id=10005&group_id=10008

Return value: 200

Configurer manuellement la distribution des buckets :

POST /api/colocate/bucketseq?db_id=10005&group_id=10008

Body:
[[10004],[10003],[10002],[10003],[10002],[10003],[10003],[10003],[10003],[10002]]

Return value: 200

Le corps de la requête est un tableau imbriqué où chaque élément liste les ID des nœuds BE correspondant à cet index de bucket.

Fonctionnement de la réparation des réplicas

Les réplicas de colocation sont assignés à des nœuds BE spécifiques. Si un nœud BE tombe en panne ou est mis hors service, SelectDB sélectionne le nœud BE disponible le moins chargé comme remplacement et commence à réparer tous les tablets affectés. Pendant cette migration, le CG est marqué Unstable.

Fonctionnement du rééquilibrage des réplicas

Pour les tables classiques, SelectDB équilibre les réplicas individuellement en trouvant un BE approprié pour chaque réplica de manière indépendante. Pour les tables de colocation, les réplicas sont équilibrés au niveau du bucket : tous les réplicas d'un bucket sont migrés ensemble afin de préserver la garantie de co-localisation.

L'algorithme d'équilibrage répartit la séquence de buckets sur les nœuds BE en fonction du nombre de réplicas, et non de la taille réelle des données.

L'algorithme d'équilibrage actuel peut ne pas répartir la charge uniformément dans les déploiements hétérogènes, où les nœuds BE ont des capacités de disque, des nombres de disques ou des types de disques (SSD vs HDD) différents. Dans de tels environnements, les nœuds de faible capacité et ceux de grande capacité peuvent finir par héberger le même nombre de réplicas.

Si un CG devient Unstable et que vous souhaitez empêcher le rééquilibrage automatique de perturber répétitivement les requêtes, définissez disable_colocate_balance sur true. Rétablissez la valeur à false lorsque vous êtes prêt à autoriser à nouveau le rééquilibrage.