Lindorm:Secondary indexes

Relation entre les index 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 index pour une seule table principale, y compris des index 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 relative à 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. Ajoutez, supprimez ou mettez à jour des index à 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 instantané 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'expiration du client ou d'erreur d'E/S. Si une écriture échoue en raison d'un délai d'expiration du 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 ces dernières reste garantie.

Mutabilité

Toute é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 quelles opérations votre charge de travail effectue, afin de minimiser la surcharge liée à la maintenance des index. Définissez cette propriété à l'aide de Table_Options lors de la création ou de la modification d'une table. Consultez la rubrique Syntaxe CREATE TABLE.

Choisissez un paramètre de mutabilité adapté à 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

Le paramètre MUTABLE_LATEST est 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 cette configuration avant de créer les index, car la propriété de mutabilité prend effet au moment de la création de l'index.

Les paramètres IMMUTABLE et IMMUTABLE_ROWS ne font l'objet d'aucune application côté serveur. Si votre charge de travail met à jour des données alors que la table est configurée sur IMMUTABLE ou IMMUTABLE_ROWS , le serveur ne renvoie pas d'erreur, mais les données de l'index deviennent incohérentes avec celles de 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 actif-actif 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 dans 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 index secondaires de Lindorm prennent également en charge la mise à jour des données d'index lors de l'utilisation d'horodatages personnalisés, une fonctionnalité rare dans les systèmes NoSQL.

Deux cas d'utilisation où cela importe :

• Importation concurrente 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 sont prioritaires ; les importations historiques complètent uniquement les données qui n'ont pas encore été mises à jour.

• Rattrapage de messages : lorsqu'un système ignore les messages accumulés et traite d'abord les actuels, chaque message porte son propre horodatage. Le rattrapage ultérieur des messages antérieurs applique l'ordre de remplacement 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é. Le mode 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é pour la définir sur MUTABLE_UDT .

3. Créez à nouveau l'index.

Pour d'autres problèmes liés aux index, rejoignez le groupe DingTalk Lindorm ou ouvrez un ticket. Consultez la rubrique Support technique.