Lindorm:Secondary indexes

Relation entre les indexes et les tables principales

Chaque index secondaire correspond à une table de données physique indépendante, distincte de la table principale. Vous pouvez créer plusieurs indexes pour une seule table principale, y compris des indexes composites basés sur une ou plusieurs colonnes. Lorsque vous écrivez dans la table principale, Lindorm met automatiquement à jour toutes les tables d'index associées. Lors de l'interrogation, spécifiez les conditions dans la clause WHERE de la table principale ; Lindorm sélectionne automatiquement le meilleur index, avec un repli sur la table principale si aucun index ne convient.

Modification de schéma en ligne

Les modifications d'index (ajout, désactivation ou suppression) n'affectent pas les opérations de lecture ou d'écriture normales sur la table principale. Vous pouvez ajouter, supprimer ou mettre à jour des indexes à tout moment sans interruption de service.

Cohérence forte

La cohérence des données entre la table principale et les tables d'index est soumise aux contraintes suivantes :

• L'isolation par snapshot n'est pas prise en charge. Les données écrites dans la table principale peuvent ne pas être immédiatement visibles dans les tables d'index. Une fois que le serveur renvoie une réponse de succès, les données deviennent visibles dans les deux.

• Comportement en cas de délai d'attente client ou d'erreur d'E/S. Si une écriture échoue en raison d'un délai d'attente client ou d'une erreur d'E/S, les données peuvent ne pas apparaître dans la table principale ni dans les tables d'index. La cohérence à terme entre elles reste garantie.

Mutabilité

Chaque écriture dans une table indexée coûte plus cher qu'une écriture dans une table simple, car l'index doit être maintenu. Le coût réel dépend du fait que votre charge de travail mette à jour ou supprime des lignes existantes.

La propriété MUTABILITY indique à Lindorm les opérations effectuées par votre charge de travail, afin de minimiser la surcharge liée à la maintenance des indexes. Définissez cette propriété à l'aide de Table_Options lors de la création ou de la modification d'une table. Consultez la syntaxe CREATE TABLE.

Choisissez un paramètre de mutabilité en fonction de votre modèle d'écriture :

• Ajout uniquement, sans mise à jour ni suppression : utilisez IMMUTABLE

• Ajout et suppressions au niveau des lignes, sans mise à jour : utilisez IMMUTABLE_ROWS

• Mises à jour et suppressions, sans horodatage personnalisé : utilisez MUTABLE_LATEST (recommandé)

• Mises à jour et suppressions avec horodatage personnalisé : utilisez MUTABLE_UDT

MUTABLE_LATEST est le paramètre recommandé. Pour LindormTable 2.7.9 et versions ultérieures, il s'agit de la valeur par défaut. Si votre instance exécute une version antérieure, définissez explicitement MUTABILITY='MUTABLE_LATEST'.

Pour écrire des données avec un horodatage personnalisé, utilisez MUTABLE_UDT (nécessite LindormTable 2.6.7 ou version ultérieure). Planifiez cela avant de créer des indexes, car la propriété de mutabilité prend effet au moment de la création de l'index.

IMMUTABLE et IMMUTABLE_ROWS ne font l'objet d'aucune application côté serveur. Si votre charge de travail met à jour des données mais que la table est définie sur IMMUTABLE ou IMMUTABLE_ROWS , le serveur ne renvoie pas d'erreur, mais les données de l'index deviennent incohérentes avec la table principale. N'utilisez ces paramètres que si vous êtes certain qu'aucune mise à jour ne se produira. Étant donné que les tables IMMUTABLE n'impliquent aucune suppression, elles prennent entièrement en charge les déploiements actifs-actifs multi-centres de données Internet (IDC).

Index couvrants

Sans index couvrant, une requête qui correspond à une entrée d'index doit toujours récupérer la ligne complète depuis la table principale. Les rowkeys renvoyés par l'index peuvent être dispersés dans la table principale, ce qui nécessite plusieurs appels de procédure distante (RPC) et augmente le temps de réponse (RT) à mesure que l'ensemble de résultats s'agrandit.

Un index couvrant inclut directement les colonnes de la table principale dans la table d'index, éliminant ainsi les recherches dans la table principale pour ces colonnes. Lindorm prend en charge trois modes de couverture :

• Specific columns : répertoriez les colonnes à répliquer depuis la table principale.

• Toutes les colonnes du schéma (COVERED_ALL_COLUMNS_IN_SCHEMA) : inclut toutes les colonnes actuellement définies dans le schéma de la table principale. Lorsqu'une nouvelle colonne est ajoutée à la table principale, l'index l'inclut automatiquement, sans nécessiter de réindexation.

• Colonnes dynamiques (DYNAMIC) : inclut toutes les colonnes dynamiques de la table principale, ainsi que toutes les colonnes définies par le schéma.

Horodatages personnalisés (User-Defined Timestamp, UDT)

Lindorm prend en charge les horodatages personnalisés au niveau des colonnes. L'écriture de données avec un horodatage personnalisé est courante dans les systèmes basés sur HBase pour contrôler la durée de vie (TTL) et gérer les écritures hors ordre ou idempotentes. Les indexes secondaires dans Lindorm prennent également en charge la mise à jour des données d'index lorsque des horodatages personnalisés sont utilisés, une capacité rare dans les systèmes NoSQL.

Deux cas d'utilisation où cela importe :

• Importation simultanée et mises à jour en temps réel : utilisez l'heure actuelle pour les écritures en temps réel et un horodatage antérieur (par exemple, 23:59:59 de la veille) pour les importations historiques. Les écritures en temps réel ont la priorité ; les importations historiques ne remplissent que les données non encore mises à jour.

• Rattrapage de messages : lorsqu'un système ignore les messages accumulés et traite d'abord les messages actuels, chaque message porte son propre horodatage. Le rattrapage des messages antérieurs applique ultérieurement l'ordre d'écrasement correct, indépendamment de la séquence de traitement.

-- Create the primary table
CREATE TABLE orders (
  order_id VARCHAR NOT NULL,
  user_id  VARCHAR,
  status   VARCHAR,
  amount   DOUBLE,
  created  BIGINT,
  PRIMARY KEY(order_id)
) WITH (CONSISTENCY = 'strong', MUTABILITY = 'MUTABLE_LATEST');

-- Create a covering index on user_id, including all schema columns
-- Queries filtering on user_id hit this index and avoid primary table lookups
CREATE INDEX idx_user ON orders(user_id) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

-- This query uses idx_user automatically
SELECT * FROM orders WHERE user_id = 'u123';

SHOW INDEX FROM orders;

-- Activate an index
ALTER INDEX IF EXISTS idx_user ON orders ACTIVE;

-- Disable an index
ALTER INDEX idx_user ON orders DISABLED;

DROP INDEX IF EXISTS idx_user ON orders;

CREATE TABLE dt (rowkey VARCHAR, c1 VARCHAR, c2 VARCHAR, c3 VARCHAR, c4 VARCHAR, c5 VARCHAR, PRIMARY KEY(rowkey));
CREATE INDEX idx1 ON dt(c1);
CREATE INDEX idx2 ON dt(c2, c3, c4);
CREATE INDEX idx3 ON dt(c3) INCLUDE(c1, c2, c4);
CREATE INDEX idx4 ON dt(c5 DESC) WITH (INDEX_COVERED_TYPE = 'COVERED_ALL_COLUMNS_IN_SCHEMA');

Pourquoi l'erreur User-Defined-Timestamp(UDT) is not supported by table in MUTABLE_LATEST mode apparaît-elle ?

Vous avez créé un index alors que la mutabilité de la table était définie sur MUTABLE_LATEST, mais votre application écrit des données avec un horodatage personnalisé. MUTABLE_LATEST ne prend pas en charge les horodatages personnalisés.

Pour résoudre ce problème :

1. Supprimez l'index de la table principale.

2. Modifiez la propriété de mutabilité en MUTABLE_UDT.

3. Créez à nouveau l'index.

Pour d'autres problèmes liés aux indexes, rejoignez le groupe DingTalk Lindorm ou soumettez un ticket. Consultez le support technique.