La console OpenSearch propose quatre méthodes pour définir un schéma d'application. L'édition Algorithme Industriel d'OpenSearch prend en charge les schémas multi-tables, vous permettant de modéliser des relations de données complexes entre une table principale et jusqu'à 10 tables secondaires. Lors de l'indexation, OpenSearch effectue une jointure LEFT JOIN sur ces tables pour générer une table large servant de base à l'index de recherche.
Fonctionnement
Lors de l'indexation, OpenSearch exécute une opération LEFT JOIN entre la table principale et toutes les tables secondaires associées. Le résultat est une table large dont le nombre de lignes correspond à celui de la table principale : un document de recherche par enregistrement principal. Les champs des tables secondaires sans enregistrement correspondant reçoivent des valeurs par défaut : 0 pour les champs INT et null pour les champs STRING.
L'index est construit à partir de cette table large et traite toutes les requêtes de recherche.
Règles d'association
Respectez les règles suivantes lors de la conception d'un schéma multi-tables :
Une seule table principale par application. Seule une table peut être définie comme table principale.
Ratio d'enregistrements N:1 ou 1:1 uniquement. Chaque enregistrement de la table principale correspond au maximum à un seul enregistrement de la table secondaire. Un enregistrement principal unique ne peut pas correspondre à plusieurs enregistrements secondaires (le ratio 1:N n'est pas pris en charge).
Association basée sur les clés. Une table secondaire rejoint la table principale via sa clé primaire, qui doit correspondre à une clé étrangère dans la table principale. La clé étrangère de la table principale ne peut référencer que la clé primaire d'une table secondaire.
Même type de champ requis. Le mappage des champs entre les tables n'est possible que s'ils partagent le même type. Par exemple, une clé primaire INT dans une table secondaire ne peut être mappée qu'à un champ INT dans la table principale.
Jusqu'à deux niveaux d'association pour les applications standard ; les applications exclusives prennent en charge jusqu'à trois niveaux.
Jusqu'à 10 tables secondaires par application ; les applications exclusives peuvent dépasser cette limite.
Modèles d'association pris en charge
| Modèle | Association | Pris en charge |
|---|---|---|
| Principale + 1 secondaire | Principale → Secondaire | Oui |
| Principale + 2 secondaires en chaîne | Principale → B → C | Oui |
| Principale + plusieurs secondaires (fan-out) | Principale → B, Principale → C, Principale → D (≤2 niveaux, ≤10 tables) | Oui |
| Principale + chaîne à 3 niveaux | Principale → B → C → D (>2 niveaux) | Non, sauf pour les applications exclusives (jusqu'à 3 niveaux) |
| Association cyclique | Principale → B, B → Principale | Non |
| Principale + >10 secondaires | Plus de 10 tables secondaires | Non, sauf pour les applications exclusives |
Limites et notes opérationnelles
Délai de mise à jour lorsque N est élevé
Si le ratio d'enregistrements entre la table principale et la table secondaire est de N:1 avec un N élevé, la mise à jour d'un seul enregistrement secondaire déclenche N mises à jour de l'index de la table principale. Cela peut entraîner des délais de mise à jour pour les deux tables. Maintenez N à 10 ou moins pour minimiser ce risque.
Valeurs par défaut pour les champs non appariés
Après l'opération LEFT JOIN, tout champ de la table secondaire sans enregistrement correspondant dans la table principale reçoit une valeur par défaut dans la table large :
| Type de champ | Valeur par défaut |
|---|---|
| INT | 0 |
| STRING | null |