Les fonctionnalités de LindormTable — TTL, TTL au niveau des cellules, gestion des versions des données et tables immuables — peuvent générer des résultats de requête inattendus en cas de mauvaise configuration. Cette rubrique présente neuf causes courantes pour vous aider à diagnostiquer et résoudre les problèmes de requête.
LindormTable est un moteur de données NoSQL qui stocke les informations selon une structure Log-Structured Merge Tree (LSM-Tree). Lors de l'écriture, les données sont d'abord enregistrées dans les journaux WAL (Write-Ahead Log) avant d'être validées dans la base de données. En l'absence d'erreur, l'écriture réussit et les données peuvent être restaurées à partir des journaux WAL en cas de défaillance du serveur, garantissant ainsi leur durabilité.
Index de diagnostic rapide
Utilisez ce tableau pour associer votre symptôme à la section correspondante.
| Symptôme | Cause probable |
|---|---|
| Les données ont été écrites avec succès mais ne peuvent pas être interrogées | Données non encore écrites ou requête exécutée avant la fin de l'écriture |
| Une requête de correspondance exacte ne renvoie aucun résultat malgré des données correctes | Le champ STRING contient des caractères d'arrêt ou invisibles |
| La requête ne renvoie aucun résultat pour une colonne dont vous connaissez l'existence | La casse du nom de colonne est incorrecte ou la famille de colonnes est manquante |
| Les données disparaissent après un certain temps | Expiration des données basée sur le TTL au niveau de la table |
| Une colonne renvoie une valeur plus ancienne inattendue après un certain temps | Expiration des données basée sur un TTL au niveau de la cellule |
| Une opération DELETE a supprimé plus de données que prévu | L'horodatage de suppression a effacé plus de données que prévu |
| Les données apparaissent brièvement, puis disparaissent | Condition de concurrence écriture-suppression dans le flux de données |
| Chaque écriture devient immédiatement non interrogeable | Attribut VERSIONS défini sur 0 |
| Les résultats de la requête varient selon le chemin de recherche | Données mises à jour ou supprimées dans une table immuable |
Causes courantes
Données non encore écrites ou requête exécutée avant la fin de l'écriture
Dans les pipelines de big data, une défaillance ou un retard à n'importe quel stade du processus d'écriture peut empêcher les données d'atteindre LindormTable au moment attendu. Si une requête ne renvoie aucun résultat, il est possible que les données n'aient pas encore été écrites.
Diagnostic : Ajoutez une indication à votre requête pour renvoyer l'horodatage avec les résultats. Comparez cet horodatage à l'heure à laquelle l'écriture devait être terminée.
Pour plus de détails sur l'ajout d'indications afin de récupérer les horodatages, consultez la rubrique Utiliser des indications pour implémenter la gestion des versions des données.
Si aucun horodatage n'est spécifié lors de l'écriture d'une ligne, l'horodatage renvoyé reflète l'heure réelle d'écriture de la ligne dans la table.
Le champ STRING contient des caractères d'arrêt ou invisibles
Si la valeur d'une colonne STRING contient des caractères invisibles (ajoutés par exemple par un bug logiciel), une requête de correspondance exacte échoue car la valeur stockée diffère de la valeur recherchée.
Exemple : Une valeur stockée sous la forme 1000<caractère invisible> ne correspond pas à la condition where orderID = "1000".
Diagnostic : Exécutez une requête de plage pour inspecter la valeur réellement stockée :
SELECT * FROM <table> WHERE orderID > "1000" LIMIT 1;Si la ligne est renvoyée, la valeur comporte probablement un caractère invisible final. Corrigez le processus d'écriture pour supprimer ces caractères avant l'enregistrement.
Caractères d'arrêt au milieu d'une chaîne : LindormTable ne prend pas en charge les caractères d'arrêt au milieu d'une valeur STRING. L'écriture d'une chaîne telle que "1000\<caractère d'arrêt>\1000" provoque une exception d'encodage et empêche toute interrogation de cette valeur.
La casse du nom de colonne est incorrecte ou la famille de colonnes est manquante
Deux erreurs de configuration distinctes peuvent toutes deux produire des résultats vides.
Incohérence de casse : Les noms de colonnes dans Lindorm sont sensibles à la casse. Une requête utilisant OrderID ne correspond pas à une colonne nommée orderID.
Préfixe de famille de colonnes manquant : Les tables larges de LindormTable prennent en charge plusieurs familles de colonnes. Si aucune famille de colonnes n'est spécifiée lors de la création de la table, toutes les colonnes sont placées dans la famille de colonnes par défaut f et aucun préfixe n'est nécessaire. Toutefois, si la table comporte plusieurs familles de colonnes, les requêtes omettant le préfixe de la famille de colonnes recherchent uniquement dans f.
Exemple : Une colonne nommée column1 réside dans une famille de colonnes nommée meta. Une requête utilisant where column1 = xxx effectue sa recherche dans f et ne renvoie rien. Utilisez plutôt where meta:column1 = xxx.
Expiration des données basée sur le TTL au niveau de la table
Le TTL de LindormTable est exprimé en secondes. Les horodatages écrits avec les données sont en millisecondes.
Si le TTL est correctement configuré, les données expirent naturellement après la période définie. Par exemple, des données écrites aujourd'hui expireront demain si le TTL est de 86 400 secondes (un jour).
Deux cas limites entraînent la suppression immédiate des données juste après leur écriture :
Horodatage trop faible : Si vous spécifiez un horodatage antérieur lors de l'écriture des données et que la différence entre cet horodatage et l'heure actuelle dépasse le TTL spécifié, les données peuvent être supprimées immédiatement après leur insertion dans la table. Les numéros de version personnalisés tels que
1,2ou3sont particulièrement sujets à ce problème.Unité d'horodatage incorrecte : Si un horodatage en microsecondes ou nanosecondes est écrit au lieu de millisecondes, la valeur de l'horodatage est bien plus grande que prévu. Les données peuvent ne jamais expirer comme souhaité, ou être considérées comme écrites plusieurs millions de secondes dans le futur.
Dans LindormTable, le numéro de version d'une paire clé-valeur équivaut à un horodatage. Si vous spécifiez de petites valeurs (comme 1, 2 et 3) comme numéros de version personnalisés, les données risquent d'être effacées en fonction du TTL spécifié. De même, si vous spécifiez une valeur élevée, telle qu'un horodatage en microsecondes ou nanosecondes au lieu de millisecondes, comme horodatage ou numéro de version personnalisé, les données ne pourront pas être effacées comme prévu selon le TTL indiqué.
Vérifier le TTL d'une table :
Connectez-vous au système de gestion de cluster.
Sur la page Overview, cliquez sur le nom de la table.
Dans la section Current table details, cliquez sur View table properties.
Vérifiez la valeur de TTL.
Modifier le TTL :
Expiration des données basée sur un TTL au niveau de la cellule
LindormTable prend en charge un TTL en millisecondes sur des paires clé-valeur individuelles, appelé TTL au niveau de la cellule. Lorsqu'un TTL de cellule est défini, l'heure d'expiration réelle d'une paire clé-valeur est :
min(expiration based on cell TTL, expiration based on table TTL)Le TTL de la cellule et le TTL de la table sont tous deux calculés à partir de l'horodatage ou du numéro de version de la paire clé-valeur. Si l'horodatage est trop faible ou trop élevé, la paire peut expirer plus tôt ou plus tard que prévu.
Exemple de comportement :
Une colonne contient deux paires clé-valeur, KV1 (avec un TTL de cellule) et KV2 (sans TTL de cellule).
Avant l'expiration de KV1 : les requêtes peuvent renvoyer KV1 car son horodatage est plus récent.
Après l'expiration de KV1 : KV1 est effacé et KV2 est renvoyé à la place, ce qui peut ne pas correspondre à la valeur attendue.
La possibilité d'interroger KV2 dépend également de l'attribut VERSIONS et de la compaction majeure. Si VERSIONS est défini sur 1, KV2 est supprimé lors de la compaction majeure dès que KV1 est effacé, même si aucun TTL de cellule n'était défini sur KV2.
L'horodatage de suppression a effacé plus de données que prévu
Une opération DELETE supprime toutes les données écrites dans la ligne ou la colonne cible avant l'horodatage ou le numéro de version spécifié. Si aucun horodatage n'est fourni, LindormTable utilise l'heure actuelle, supprimant ainsi toutes les données écrites avant ce moment.
Deux problèmes peuvent survenir :
Les données écrites après l'horodatage de suppression ne sont pas supprimées : Si une ligne a été écrite après l'horodatage indiqué dans la requête DELETE, elle n'est pas supprimée et apparaît dans les requêtes suivantes.
Les écritures postérieures à la suppression sont immédiatement effacées : Si un horodatage élevé est spécifié dans la requête DELETE, les écritures ultérieures avec des horodatages plus faibles (normaux) sont considérées comme antérieures au marqueur de suppression et sont supprimées immédiatement.
Les horodatages ne peuvent pas être spécifiés dans les instructions SQL DELETE.
Exemple : DELETE FROM sensor WHERE p1 = 10; supprime toutes les versions des lignes correspondantes écrites avant l'heure actuelle (le 16 janvier 2024 à 16:00:00 dans cet exemple).
Condition de concurrence écriture-suppression dans le flux de données
Dans les pipelines de big data où les écritures et les suppressions proviennent de programmes ou de processus distincts, une opération de suppression peut arriver dans LindormTable avant l'écriture qu'elle était censée suivre. Dans ce cas, l'écriture intervient après la suppression : la ligne apparaît brièvement, puis est supprimée.
Problème lié au connecteur Flink : Les anciennes versions du connecteur Lindorm pour Realtime Compute for Apache Flink présentent un bug permettant à une opération d'écriture d'être écrasée par une suppression simultanée. Pour contourner ce problème, définissez ignoreDelete=true dans votre configuration Flink.
Pour plus de détails, consultez la rubrique Connecteur Lindorm.
Attribut VERSIONS défini sur 0
L'attribut VERSIONS contrôle le nombre de versions d'une paire clé-valeur conservées. Lorsque VERSIONS est défini sur 0, aucune donnée n'est conservée : chaque écriture est immédiatement supprimée et ne peut pas être interrogée.
La valeur par défaut de VERSIONS est 1 (une version conservée). L'attribut MIN_VERSIONS a pour valeur par défaut 0 et ne cause pas de perte de données.
Si VERSIONS a été défini par erreur sur 0 :
Supprimez la table et recréez-la en définissant VERSIONS sur
1ou une valeur supérieure, ouModifiez VERSIONS pour le définir sur
1ou une valeur supérieure en utilisant Lindorm Shell ou ALTER TABLE.
Vérifier l'attribut VERSIONS :
Connectez-vous au système de gestion de cluster.
Sur la page Overview, cliquez sur le nom de la table.
Dans la section Current table details, cliquez sur View table properties.
Vérifiez la valeur de VERSIONS.
Modifier VERSIONS :
Pour en savoir plus sur la gestion des versions des données, consultez la rubrique Utiliser des indications pour implémenter la gestion des versions des données.
Données mises à jour ou supprimées dans une table immuable
Lorsque l'attribut MUTABILITY d'une table est défini sur IMMUTABLE, les données ne peuvent être écrites qu'à l'aide d'une seule instruction UPSERT. Les mises à jour et les suppressions ne sont pas autorisées.
Cependant, LindormTable ne bloque pas strictement les opérations de mise à jour et de suppression sur les tables immuables. L'exécution de telles opérations entraîne une incohérence des données entre la table d'index et la table de base : la même requête peut correspondre à différentes lignes selon la table utilisée pour la recherche.
Pour récupérer les données, reconstruisez la table d'index et cessez d'émettre des opérations de mise à jour ou de suppression sur la table immuable.