Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisation des données et de l'historique dans Amazon QLDB
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Les rubriques suivantes fournissent des exemples de base d'instructions de *création, de lecture, de mise à jour et de suppression* (CRUD). [Vous pouvez exécuter ces instructions manuellement à l'aide de l'*éditeur partiQL* de la [console QLDB ou du shell QLDB](console_QLDB.md).](data-shell.md) Ce guide explique également comment QLDB gère vos données lorsque vous apportez des modifications à votre registre.
QLDB prend en charge le langage de requête [partiQL](https://partiql.org/).
Pour des exemples de code montrant comment exécuter des instructions similaires par programmation à l'aide du pilote QLDB, consultez les didacticiels dans. [Commencer à utiliser le chauffeur](getting-started-driver.md)
**Astuce**
Voici un bref résumé des conseils et des meilleures pratiques pour travailler avec partiQL dans QLDB :
**Comprenez la simultanéité et les limites de transaction** — Toutes les déclarations, y compris les `SELECT` requêtes, sont soumises à des conflits [optimistes en matière de contrôle simultané (OCC)](concurrency.md) et à des [limites de transaction](limits.md#limits.fixed), y compris un délai d'expiration de 30 secondes pour les transactions.
**Utiliser des index** : utilisez des index à cardinalité élevée et exécutez des requêtes ciblées pour optimiser vos instructions et éviter d'analyser des tables complètes. Pour en savoir plus, consultez [Optimisation des performances des requêtes](working.optimize.md).
**Utiliser des prédicats d'égalité : les** recherches indexées nécessitent un opérateur d'*égalité* (ou)`=`. `IN` Les opérateurs d'inégalité (`<`,`>`,`LIKE`,`BETWEEN`) ne sont pas éligibles aux recherches indexées et donnent lieu à des analyses complètes des tables.
**Utilisez uniquement les jointures internes** : QLDB ne prend en charge que les jointures internes. Il est recommandé de joindre des champs indexés pour chaque table que vous joignez. Choisissez des indices de cardinalité élevés pour les critères de jointure et les prédicats d'égalité.
**Topics**
+ [
# Création de tables avec index et insertion de documents
](working.create.md)
+ [
# Interrogation de vos données
](working.userdata.md)
+ [
# Interrogation des métadonnées d'un document
](working.metadata.md)
+ [
# Utilisation de la clause BY pour demander l'ID du document
](working.metadata.by-clause.md)
+ [
# Mettre à jour et supprimer des documents
](working.revisions.md)
+ [
# Consultation de l'historique des révisions
](working.history.md)
+ [
# Rédaction de révisions de documents
](working.redaction.md)
+ [
# Optimisation des performances des requêtes
](working.optimize.md)
+ [
# Obtenir les statistiques des instructions PartiQL
](working.statement-stats.md)
+ [
# Interrogation du catalogue du système
](working.catalog.md)
+ [
# Gestion des tables
](working.manage-tables.md)
+ [
# Gestion des index
](working.manage-indexes.md)
+ [
# Unique IDs dans Amazon QLDB
](working.unique-id.md)
# Création de tables avec index et insertion de documents
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Après avoir créé un registre Amazon QLDB, la première étape consiste à créer une table avec une instruction de base. [CREATE TABLE](ql-reference.create-table.md) Les tables se composent de [Documents QLDB](ql-reference.docs.md) jeux de données au `struct` format [Amazon Ion](ion.md).
**Topics**
+ [
## Création de tables et d'index
](#working.create.tables-indexes)
+ [
## Insertion de documents
](#working.create.insert)
## Création de tables et d'index
Les tables ont des noms simples, sensibles aux majuscules et minuscules, sans espaces de noms. QLDB prend en charge le contenu ouvert et n'applique pas le schéma. Vous ne définissez donc pas d'attributs ou de types de données lors de la création de tables.
```
CREATE TABLE VehicleRegistration
```
```
CREATE TABLE Vehicle
```
Une `CREATE TABLE` instruction renvoie l'ID attribué par le système à la nouvelle table. Tous les identifiants uniques universels ( IDsUUID) [assignés au système](working.unique-id.md) dans QLDB sont chacun représentés dans une chaîne codée en Base62.
**Note**
Vous pouvez éventuellement définir des balises pour une ressource de table pendant que vous créez la table. Pour savoir comment procéder, veuillez consulter la section [Marquer les tables lors de leur création](working.manage-tables.md#working.manage-tables.tags).
Vous pouvez également créer des index sur les tables afin d'optimiser les performances des requêtes.
```
CREATE INDEX ON VehicleRegistration (VIN)
```
```
CREATE INDEX ON VehicleRegistration (LicensePlateNumber)
```
```
CREATE INDEX ON Vehicle (VIN)
```
**Important**
QLDB a besoin d'un index pour rechercher efficacement un document. Sans index, QLDB doit effectuer une analyse complète de la table lors de la lecture de documents. Cela peut entraîner des problèmes de performances sur de grandes tables, notamment des conflits de simultanéité et des délais d'expiration des transactions.
Pour éviter de scanner des tables, vous devez exécuter des instructions contenant une clause de `WHERE` prédicat à l'aide d'un opérateur d'*égalité* (`=`ou`IN`) sur un champ indexé ou un identifiant de document. Pour de plus amples informations, veuillez consulter [Optimisation des performances des requêtes](working.optimize.md).
Tenez compte des contraintes suivantes lors de la création d'index :
+ Un index ne peut être créé que sur un seul champ de niveau supérieur. Les index composites, imbriqués, uniques et basés sur des fonctions ne sont pas pris en charge.
+ Vous pouvez créer un index sur tous les [types de données Ion](ql-reference.data-types.md), y compris `list` et`struct`. Cependant, vous ne pouvez effectuer la recherche indexée que par égalité de la valeur totale de l'ion, quel que soit le type d'ion. Par exemple, lorsque vous utilisez un `list` type comme index, vous ne pouvez pas effectuer de recherche indexée par un élément de la liste.
+ Les performances des requêtes ne sont améliorées que lorsque vous utilisez un prédicat d'égalité ; par exemple, `WHERE indexedField = 123` ou`WHERE indexedField IN (456, 789)`.
QLDB n'honore pas les inégalités dans les prédicats de requête. Par conséquent, les scans filtrés par plage ne sont pas implémentés.
+ Les noms des champs indexés distinguent les majuscules et minuscules et peuvent comporter un maximum de 128 caractères.
+ La création d'index dans QLDB est asynchrone. Le temps nécessaire pour terminer la création d'un index sur une table non vide varie en fonction de la taille de la table. Pour de plus amples informations, veuillez consulter [Gestion des index](working.manage-indexes.md).
## Insertion de documents
Vous pouvez ensuite insérer des documents dans vos tableaux. Les documents QLDB sont stockés au format Amazon Ion. Les [INSERT](ql-reference.insert.md) instructions partiQL suivantes incluent un sous-ensemble des échantillons de données d'immatriculation des véhicules utilisés dans. [Commencer à utiliser la console Amazon QLDB](getting-started.md)
```
INSERT INTO VehicleRegistration
<< {
'VIN' : '1N4AL11D75C109151',
'LicensePlateNumber' : 'LEWISR261LL',
'State' : 'WA',
'City' : 'Seattle',
'PendingPenaltyTicketAmount' : 90.25,
'ValidFromDate' : `2017-08-21T`,
'ValidToDate' : `2020-05-11T`,
'Owners' : {
'PrimaryOwner' : { 'PersonId' : '294jJ3YUoH1IEEm8GSabOs' },
'SecondaryOwners' : [ { 'PersonId' : '5Ufgdlnj06gF5CWcOIu64s' } ]
}
},
{
'VIN' : 'KM8SRDHF6EU074761',
'LicensePlateNumber' : 'CA762X',
'State' : 'WA',
'City' : 'Kent',
'PendingPenaltyTicketAmount' : 130.75,
'ValidFromDate' : `2017-09-14T`,
'ValidToDate' : `2020-06-25T`,
'Owners' : {
'PrimaryOwner' : { 'PersonId': 'IN7MvYtUjkp1GMZu0F6CG9' },
'SecondaryOwners' : []
}
} >>
```
```
INSERT INTO Vehicle
<< {
'VIN' : '1N4AL11D75C109151',
'Type' : 'Sedan',
'Year' : 2011,
'Make' : 'Audi',
'Model' : 'A5',
'Color' : 'Silver'
} ,
{
'VIN' : 'KM8SRDHF6EU074761',
'Type' : 'Sedan',
'Year' : 2015,
'Make' : 'Tesla',
'Model' : 'Model S',
'Color' : 'Blue'
} >>
```
**Syntaxe et sémantique partiQL**
+ Les noms des champs sont placés entre guillemets simples (`'...'`).
+ Les valeurs de chaîne sont également placées entre guillemets simples (`'...'`).
+ Les horodatages sont encadrés par des backticks (). ``...`` Les backticks peuvent être utilisés pour désigner n'importe quel littéral ionique.
+ Les nombres entiers et décimaux sont des valeurs littérales qui n'ont pas besoin d'être indiquées.
Pour plus de détails sur la syntaxe et la sémantique de partiQL, consultez. [Interroger Ion avec PartiQL dans Amazon QLDB](ql-reference.query.md)
Une `INSERT` instruction crée la révision initiale d'un document dont le numéro de version est zéro. Pour identifier de manière unique chaque document, QLDB attribue *un ID de document* dans le cadre des métadonnées. Les instructions d'insertion renvoient l'ID de chaque document inséré.
**Important**
Comme QLDB n'applique pas le schéma, vous pouvez insérer le même document plusieurs fois dans une table. Chaque instruction d'insertion valide une entrée de document distincte dans le journal, et QLDB attribue à chaque document un identifiant unique.
Pour savoir comment rechercher les documents que vous avez insérés dans votre tableau, passez à[Interrogation de vos données](working.userdata.md).
# Interrogation de vos données
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
La *vue utilisateur* renvoie uniquement la dernière révision non supprimée de vos données utilisateur. Il s'agit de la vue par défaut dans Amazon QLDB. Cela signifie qu'aucun qualificatif spécial n'est nécessaire lorsque vous souhaitez interroger uniquement vos données.
Pour plus de détails sur la syntaxe et les paramètres des exemples de requêtes suivants, consultez la [SELECT](ql-reference.select.md) référence *Amazon QLDB partiQL*.
**Topics**
+ [
## Requêtes de base
](#working.userdata.basic)
+ [
## Projections et filtres
](#working.userdata.projections-filters)
+ [
## Jointures
](#working.userdata.joins)
+ [
## Données imbriquées
](#working.userdata.nested)
## Requêtes de base
Les `SELECT` requêtes de base renvoient les documents que vous avez insérés dans le tableau.
**Avertissement**
Lorsque vous exécutez une requête dans QLDB sans recherche indexée, une analyse complète de la table est déclenchée. partiQL prend en charge ces requêtes car il est compatible avec SQL. Cependant, *n'exécutez pas* d'analyses de tables pour les cas d'utilisation en production dans QLDB. L'analyse des tables peut entraîner des problèmes de performance sur les tables de grande taille, notamment des conflits de simultanéité et des délais d'expiration des transactions.
Pour éviter de scanner des tables, vous devez exécuter des instructions contenant une clause de `WHERE` prédicat à l'aide d'un opérateur d'*égalité* sur un champ indexé ou un identifiant de document ; par exemple, `WHERE indexedField = 123` ou. `WHERE indexedField IN (456, 789)` Pour de plus amples informations, veuillez consulter [Optimisation des performances des requêtes](working.optimize.md).
Les requêtes suivantes affichent les résultats des documents d'immatriculation du véhicule que vous avez insérés précédemment[Création de tables avec index et insertion de documents](working.create.md). L'ordre des résultats n'est pas spécifique et peut varier pour chaque `SELECT` requête. Vous ne devez pas vous fier à l'ordre des résultats pour aucune requête dans QLDB.
```
SELECT * FROM VehicleRegistration
WHERE LicensePlateNumber IN ('LEWISR261LL', 'CA762X')
```
```
{
VIN: "1N4AL11D75C109151",
LicensePlateNumber: "LEWISR261LL",
State: "WA",
City: "Seattle",
PendingPenaltyTicketAmount: 90.25,
ValidFromDate: 2017-08-21T,
ValidToDate: 2020-05-11T,
Owners: {
PrimaryOwner: { PersonId: "294jJ3YUoH1IEEm8GSabOs" },
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
}
},
{
VIN: "KM8SRDHF6EU074761",
LicensePlateNumber: "CA762X",
State: "WA",
City: "Kent",
PendingPenaltyTicketAmount: 130.75,
ValidFromDate: 2017-09-14T,
ValidToDate: 2020-06-25T,
Owners: {
PrimaryOwner: { PersonId: "IN7MvYtUjkp1GMZu0F6CG9" },
SecondaryOwners: []
}
}
```
```
SELECT * FROM Vehicle
WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
```
{
VIN: "1N4AL11D75C109151",
Type: "Sedan",
Year: 2011,
Make: "Audi",
Model: "A5",
Color: "Silver"
},
{
VIN: "KM8SRDHF6EU074761",
Type: "Sedan",
Year: 2015,
Make: "Tesla",
Model: "Model S",
Color: "Blue"
}
```
**Important**
Dans PartiQL, vous utilisez des guillemets simples pour désigner des chaînes dans le langage de manipulation de données (DML) ou des instructions de requête. Mais la console QLDB et le shell QLDB renvoient les résultats de la requête au format texte Amazon Ion. Vous pouvez donc voir des chaînes entre guillemets doubles.
Cette syntaxe permet au langage de requête partiQL de maintenir la compatibilité SQL et au format de texte Amazon Ion de maintenir la compatibilité JSON.
## Projections et filtres
Vous pouvez effectuer des projections (ciblées`SELECT`) et d'autres filtres standard (`WHERE`clauses). La requête suivante renvoie un sous-ensemble de champs de document à partir de la `VehicleRegistration` table. Il filtre les véhicules selon les critères suivants :
+ **Filtre de chaînes** — Il est enregistré à Seattle.
+ **Filtre décimal** — Le montant du ticket de pénalité en attente est inférieur à`100.0`.
+ **Filtre de date** — Sa date d'enregistrement est valide le 4 septembre 2019 ou après cette date.
```
SELECT r.VIN, r.PendingPenaltyTicketAmount, r.Owners
FROM VehicleRegistration AS r
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
AND r.City = 'Seattle' --string
AND r.PendingPenaltyTicketAmount < 100.0 --decimal
AND r.ValidToDate >= `2019-09-04T` --timestamp with day precision
```
```
{
VIN: "1N4AL11D75C109151",
PendingPenaltyTicketAmount: 90.25,
Owners: {
PrimaryOwner: { PersonId: "294jJ3YUoH1IEEm8GSabOs" },
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
}
}
```
## Jointures
Vous pouvez également écrire des requêtes de jointure internes. L'exemple suivant montre une requête de jointure interne implicite qui renvoie tous les documents d'immatriculation ainsi que les attributs des véhicules immatriculés.
```
SELECT * FROM VehicleRegistration AS r, Vehicle AS v
WHERE r.VIN = v.VIN
AND r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
```
{
VIN: "1N4AL11D75C109151",
LicensePlateNumber: "LEWISR261LL",
State: "WA",
City: "Seattle",
PendingPenaltyTicketAmount: 90.25,
ValidFromDate: 2017-08-21T,
ValidToDate: 2020-05-11T,
Owners: {
PrimaryOwner: { PersonId: "294jJ3YUoH1IEEm8GSabOs" },
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
},
Type: "Sedan",
Year: 2011,
Make: "Audi",
Model: "A5",
Color: "Silver"
},
{
VIN: "KM8SRDHF6EU074761",
LicensePlateNumber: "CA762X",
State: "WA",
City: "Kent",
PendingPenaltyTicketAmount: 130.75,
ValidFromDate: 2017-09-14T,
ValidToDate: 2020-06-25T,
Owners: {
PrimaryOwner: { PersonId: "IN7MvYtUjkp1GMZu0F6CG9" },
SecondaryOwners: []
},
Type: "Sedan",
Year: 2015,
Make: "Tesla",
Model: "Model S",
Color: "Blue"
}
```
Vous pouvez également écrire la même requête de jointure interne dans la syntaxe explicite suivante.
```
SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v
ON r.VIN = v.VIN
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
## Données imbriquées
Vous pouvez utiliser PartiQL dans QLDB pour interroger des données imbriquées dans des documents. L'exemple suivant montre une sous-requête corrélée qui aplatit les données imbriquées. Le `@` personnage est techniquement facultatif ici. Mais cela indique explicitement que vous voulez y inclure la `Owners` structure`VehicleRegistration`, et non une collection différente nommée `Owners` (s'il en existait une).
```
SELECT
r.VIN,
o.SecondaryOwners
FROM
VehicleRegistration AS r, @r.Owners AS o
WHERE
r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
```
{
VIN: "1N4AL11D75C109151",
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
},
{
VIN: "KM8SRDHF6EU074761",
SecondaryOwners: []
}
```
Ce qui suit montre une sous-requête de la `SELECT` liste qui projette des données imbriquées, en plus d'une jointure interne.
```
SELECT
v.Make,
v.Model,
(SELECT VALUE o.PrimaryOwner.PersonId FROM @r.Owners AS o) AS PrimaryOwner
FROM
VehicleRegistration AS r, Vehicle AS v
WHERE
r.VIN = v.VIN AND r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
```
{
Make: "Audi",
Model: "A5",
PrimaryOwner: ["294jJ3YUoH1IEEm8GSabOs"]
},
{
Make: "Tesla",
Model: "Model S",
PrimaryOwner: ["IN7MvYtUjkp1GMZu0F6CG9"]
}
```
La requête suivante renvoie le numéro d'index (ordinal) `PersonId` et de chaque personne figurant dans la `Owners.SecondaryOwners` liste d'un `VehicleRegistration` document.
```
SELECT s.PersonId, owner_idx
FROM VehicleRegistration AS r, @r.Owners.SecondaryOwners AS s AT owner_idx
WHERE r.VIN = '1N4AL11D75C109151'
```
```
{
PersonId: "5Ufgdlnj06gF5CWcOIu64s",
owner_idx: 0
}
```
Pour savoir comment interroger les métadonnées de votre document, passez à[Interrogation des métadonnées d'un document](working.metadata.md).
# Interrogation des métadonnées d'un document
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Une `INSERT` instruction crée la révision initiale d'un document dont le numéro de version est zéro. Pour identifier de manière unique chaque document, Amazon QLDB attribue *un ID de document* dans le cadre des métadonnées.
Outre l'ID du document et le numéro de version, QLDB stocke d'autres métadonnées générées par le système pour chaque document dans un tableau. Ces métadonnées incluent les informations relatives aux transactions, les attributs du journal et la valeur de hachage du document.
Tous les identifiants uniques universels (UUID) assignés par le système IDs sont chacun représentés dans une chaîne codée en Base62. Pour de plus amples informations, veuillez consulter [Unique IDs dans Amazon QLDB](working.unique-id.md).
**Topics**
+ [
## Un point de vue engagé
](#working.metadata.committed)
+ [
## Rejoindre les opinions des utilisateurs et des utilisateurs
](#working.metadata.committed-joins)
## Un point de vue engagé
Vous pouvez accéder aux métadonnées du document en interrogeant la *vue validée*. Cette vue renvoie les documents de la table définie par le système qui correspond directement à votre table utilisateur. Il inclut la dernière révision validée et non supprimée de vos données et des métadonnées générées par le système. Pour interroger cette vue, ajoutez le préfixe `_ql_committed_` au nom de la table dans votre requête. (Le préfixe `_ql_` est réservé dans QLDB aux objets système.)
```
SELECT * FROM _ql_committed_VehicleRegistration AS r
WHERE r.data.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
En utilisant les données précédemment insérées[Création de tables avec index et insertion de documents](working.create.md), le résultat de cette requête affiche le contenu système de la dernière révision de chaque document non supprimé. Le document système contient des métadonnées imbriquées dans le `metadata` champ, et vos données utilisateur sont imbriquées dans le `data` champ.
```
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:14
},
hash:{{wCsmM6qD4STxz0WYmE+47nZvWtcCz9D6zNtCiM5GoWg=}},
data:{
VIN: "1N4AL11D75C109151",
LicensePlateNumber: "LEWISR261LL",
State: "WA",
City: "Seattle",
PendingPenaltyTicketAmount: 90.25,
ValidFromDate: 2017-08-21T,
ValidToDate: 2020-05-11T,
Owners: {
PrimaryOwner: { PersonId: "294jJ3YUoH1IEEm8GSabOs" },
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
}
},
metadata:{
id:"3Qv67yjXEwB9SjmvkuG6Cp",
version:0,
txTime:2019-06-05T20:53:321d-3Z,
txId:"HgXAkLjAtV0HQ4lNYdzX60"
}
},
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:14
},
hash:{{wPuwH60TtcCvg/23BFp+redRXuCALkbDihkEvCX22Jk=}},
data:{
VIN: "KM8SRDHF6EU074761",
LicensePlateNumber: "CA762X",
State: "WA",
City: "Kent",
PendingPenaltyTicketAmount: 130.75,
ValidFromDate: 2017-09-14T,
ValidToDate: 2020-06-25T,
Owners: {
PrimaryOwner: { PersonId: "IN7MvYtUjkp1GMZu0F6CG9" },
SecondaryOwners: []
}
},
metadata:{
id:"JOzfB3lWqGU727mpPeWyxg",
version:0,
txTime:2019-06-05T20:53:321d-3Z,
txId:"HgXAkLjAtV0HQ4lNYdzX60"
}
}
```
**Champs de vue dédiés**
+ `blockAddress`— L'emplacement du bloc dans le journal de votre registre où la révision du document a été validée. Une adresse, qui peut être utilisée pour la vérification cryptographique, comporte les deux champs suivants.
+ `strandId`— L'identifiant unique du volet du journal qui contient le bloc.
+ `sequenceNo`— Numéro d'index qui indique l'emplacement du bloc dans le fil.
**Note**
Dans cet exemple, les deux documents ont un identique `blockAddress` avec le même`sequenceNo`. Comme ces documents ont été insérés dans une seule transaction (et dans ce cas, dans une seule déclaration), ils ont été validés dans le même bloc.
+ `hash`— La valeur de hachage SHA-256 Ion qui représente de manière unique la révision du document. Le hachage couvre les révisions et les `metadata` champs `data` et peut être utilisé pour la vérification [cryptographique](verification.md).
+ `data`— Les attributs des données utilisateur du document.
Si vous rédigez une révision, cette `data` structure est remplacée par un `dataHash` champ dont la valeur est le hachage ionique de la structure supprimée`data`.
+ `metadata`— Les attributs de métadonnées du document.
+ `id`— L'identifiant unique du document attribué par le système.
+ `version`— Numéro de version du document. Il s'agit d'un entier de base zéro qui augmente à chaque révision du document.
+ `txTime`— L'horodatage auquel la révision du document a été validée dans le journal.
+ `txId`— L'identifiant unique de la transaction qui a validé la révision du document.
## Rejoindre les opinions des utilisateurs et des utilisateurs
Vous pouvez écrire des requêtes qui joignent une table dans la vue validée à une table dans la vue utilisateur. Par exemple, vous souhaiterez peut-être joindre le document `id` d'une table à un champ défini par l'utilisateur d'une autre table.
La requête suivante joint deux tables nommées `DriversLicense` et `Person` dans leurs `PersonId` `id` champs de document respectivement, en utilisant la vue validée pour cette dernière.
```
SELECT * FROM DriversLicense AS d INNER JOIN _ql_committed_Person AS p
ON d.PersonId = p.metadata.id
WHERE p.metadata.id = '1CWScY2qHYI9G88C2SjvtH'
```
Pour savoir comment interroger le champ ID du document dans la vue utilisateur par défaut, passez à[Utilisation de la clause BY pour demander l'ID du document](working.metadata.by-clause.md).
# Utilisation de la clause BY pour demander l'ID du document
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Bien que vous puissiez définir des champs destinés à être des identifiants uniques (par exemple, le VIN d'un véhicule), le véritable identifiant unique d'un document est le champ de `id` métadonnées, comme décrit dans[Insertion de documents](working.create.md#working.create.insert). Pour cette raison, vous pouvez utiliser le `id` champ pour créer des relations entre les tables.
Le `id` champ du document est directement accessible uniquement dans la vue validée, mais vous pouvez également le projeter dans la vue utilisateur par défaut en utilisant la `BY` clause. Pour un exemple, consultez la requête suivante et ses résultats.
```
SELECT r_id, r.VIN, r.LicensePlateNumber, r.State, r.City, r.Owners
FROM VehicleRegistration AS r BY r_id
WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'
```
```
{
r_id: "3Qv67yjXEwB9SjmvkuG6Cp",
VIN: "1N4AL11D75C109151",
LicensePlateNumber: "LEWISR261LL",
State: "WA",
City: "Seattle",
Owners: {
PrimaryOwner: { PersonId: "294jJ3YUoH1IEEm8GSabOs" },
SecondaryOwners: [{ PersonId: "5Ufgdlnj06gF5CWcOIu64s" }]
}
}
```
Dans cette requête, `r_id` il s'agit d'un alias défini par l'utilisateur déclaré dans la `FROM` clause à l'aide du `BY` mot clé. Cet `r_id` alias est lié au champ de `id` métadonnées de chaque document du jeu de résultats de la requête. Vous pouvez utiliser cet alias dans la `SELECT` clause ainsi que dans la `WHERE` clause d'une requête dans la *vue utilisateur*.
Pour accéder à d'autres attributs de métadonnées, vous devez toutefois interroger la vue validée.
## Rejoindre sur le document ID
Supposons que vous utilisiez le document `id` d'une table comme clé étrangère dans un champ défini par l'utilisateur d'une autre table. Vous pouvez utiliser la `BY` clause pour écrire une requête de jointure interne pour les deux tables de ces champs (comme [Rejoindre les opinions des utilisateurs et des utilisateurs](working.metadata.md#working.metadata.committed-joins) dans la rubrique précédente).
L'exemple suivant joint deux tables nommées `DriversLicense` et `Person` dans leurs `PersonId` `id` champs de document respectivement, en utilisant la `BY` clause correspondante.
```
SELECT * FROM DriversLicense AS d INNER JOIN Person AS p BY pid
ON d.PersonId = pid
WHERE pid = '1CWScY2qHYI9G88C2SjvtH'
```
Pour savoir comment apporter des modifications à un document de votre tableau, passez à[Mettre à jour et supprimer des documents](working.revisions.md).
# Mettre à jour et supprimer des documents
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Dans Amazon QLDB, *une révision de document* est une structure Amazon Ion qui représente une version unique d'une séquence de documents identifiés par un identifiant de document unique. Chaque révision contient le jeu de données complet du document, y compris vos données utilisateur et les métadonnées générées par le système. Chaque révision est identifiée de manière unique par une combinaison de l'ID du document et d'un numéro de version à base zéro.
Lorsque vous mettez à jour un document, QLDB crée une nouvelle révision avec le même ID de document et un numéro de version incrémenté. Le cycle de vie d'un document prend fin lorsque vous le supprimez d'un tableau. Cela signifie qu'aucune révision de document portant le même identifiant de document ne peut être créée à nouveau.
## Révision de documents
Par exemple, les instructions suivantes insèrent une nouvelle immatriculation de véhicule, mettent à jour la ville d'immatriculation, puis suppriment l'immatriculation. Cela donne lieu à trois révisions d'un document.
```
INSERT INTO VehicleRegistration
{
'VIN' : '1HVBBAANXWH544237',
'LicensePlateNumber' : 'LS477D',
'State' : 'WA',
'City' : 'Tacoma',
'PendingPenaltyTicketAmount' : 42.20,
'ValidFromDate' : `2011-10-26T`,
'ValidToDate' : `2023-09-25T`,
'Owners' : {
'PrimaryOwner' : { 'PersonId': 'KmA3XPKKFqYCP2zhR3d0Ho' },
'SecondaryOwners' : []
}
}
```
**Note**
Les instructions d'insertion et les autres instructions DML renvoient l'ID de chaque document concerné. Avant de continuer, enregistrez cet identifiant car vous en aurez besoin pour la fonction d'historique de la rubrique suivante. Vous pouvez également trouver l'ID du document à l'aide de la requête suivante.
```
SELECT r_id FROM VehicleRegistration AS r BY r_id
WHERE r.VIN = '1HVBBAANXWH544237'
```
```
UPDATE VehicleRegistration AS r
SET r.City = 'Bellevue'
WHERE r.VIN = '1HVBBAANXWH544237'
```
```
DELETE FROM VehicleRegistration AS r
WHERE r.VIN = '1HVBBAANXWH544237'
```
Pour plus d'exemples et d'informations sur la syntaxe de ces instructions DML, consultez [UPDATE](ql-reference.update.md) et [DELETE](ql-reference.delete.md) dans la référence *Amazon QLDB partiQL*.
Pour insérer et supprimer des éléments spécifiques dans un document, vous pouvez utiliser `UPDATE` des instructions ou d'autres instructions DML commençant par le `FROM` mot clé. Pour plus d'informations et des exemples, consultez la [DE (INSÉRER, SUPPRIMER ou DÉFINIR)](ql-reference.from.md) référence.
Une fois que vous avez supprimé un document, vous ne pouvez plus l'interroger dans les vues de validation ou d'utilisateur. Pour savoir comment interroger l'historique des révisions de ce document à l'aide de la fonction d'historique intégrée, passez à[Consultation de l'historique des révisions](working.history.md).
# Consultation de l'historique des révisions
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Amazon QLDB stocke l'historique complet de chaque document dans un tableau. Vous pouvez voir les trois révisions du document d'immatriculation du véhicule que vous avez précédemment inséré, mis à jour et supprimé en [Mettre à jour et supprimer des documents](working.revisions.md) interrogeant la fonction d'historique intégrée.
**Topics**
+ [
## Fonction d'historique
](#working.history.function)
+ [
## Exemple de requête d'historique
](#working.history.example)
## Fonction d'historique
La fonction d'historique de QLDB est une extension partiQL qui renvoie les révisions depuis la vue définie par le système de votre table. Elle inclut donc à la fois vos données et les métadonnées associées dans le même schéma que la vue validée.
**Syntaxe**
```
SELECT * FROM history( table_name | 'table_id' [, `start-time` [, `end-time` ] ] ) AS h
[ WHERE h.metadata.id = 'id' ]
```Arguments
***table\$1name* \$1 '*table\$1id*'**
Le nom ou l'ID de la table. Le nom d'une table est un identifiant PartiQL que vous pouvez indiquer par des guillemets doubles ou sans guillemets. Un identifiant de table est une chaîne littérale qui doit être placée entre guillemets simples. Pour en savoir plus sur l'utilisation du tableau IDs, voir[Consultation de l'historique des tables inactives](working.manage-tables.md#working.history.inactive-table).
**`*start-time*`, `*end-time*`**
(Facultatif) Spécifie la plage de temps pendant laquelle les révisions étaient actives. *Ces paramètres ne spécifient pas la période pendant laquelle les révisions ont été validées dans le journal dans le cadre d'une transaction.*
Les heures de début et de fin sont des littéraux d'horodatage ioniques qui peuvent être indiqués par des backticks (). ``...`` Pour en savoir plus, consultez [Interroger Ion avec PartiQL dans Amazon QLDB](ql-reference.query.md).
Ces paramètres temporels se comportent comme suit :
+ L'heure de *début et l'heure* *de fin* sont toutes deux incluses. Ils doivent être au format de date et d'heure [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) et en temps universel coordonné (UTC).
+ L'*heure* de début doit être inférieure ou égale à l'*heure de fin* et peut être une date arbitraire dans le passé.
+ L'*heure de fin* doit être inférieure ou égale à la date et à l'heure UTC actuelles.
+ Si vous spécifiez une *heure de début* mais pas une *heure de fin*, votre requête définit par défaut la date et l'heure actuelles pour l'*heure de fin*. Si vous ne spécifiez ni l'un ni l'autre, votre requête renvoie l'historique complet.
**'*id*'**
(Facultatif) L'ID du document pour lequel vous souhaitez consulter l'historique des révisions, indiqué par des guillemets simples.
**Astuce**
Il est recommandé de qualifier une requête d'historique à la fois par une plage de dates (heure de *début et heure* de *fin*) et par un identifiant de document (`metadata.id`). Dans QLDB, `SELECT` chaque requête est traitée dans le cadre d'une transaction et est soumise à un délai [d'](limits.md#limits.fixed)expiration de transaction.
Les requêtes d'historique n'utilisent pas les index que vous créez sur une table. L'historique QLDB est indexé uniquement par identifiant de document, et vous ne pouvez pas créer d'index d'historique supplémentaires pour le moment. Les requêtes d'historique qui incluent une heure de début et une heure de fin bénéficient de la qualification par plage de dates.
## Exemple de requête d'historique
Pour consulter l'historique du document d'immatriculation du véhicule, utilisez celui `id` que vous avez précédemment enregistré[Mettre à jour et supprimer des documents](working.revisions.md). Par exemple, la requête d'historique suivante renvoie toutes les révisions de l'ID de document `ADR2Ll1fGsU4Jr4EqTdnQF` qui ont été actives entre `2019-06-05T00:00:00Z` et`2019-06-05T23:59:59Z`.
**Note**
N'oubliez pas que les paramètres d'heure de début et de fin *ne spécifient pas* la plage de temps pendant laquelle les révisions ont été validées dans le journal dans le cadre d'une transaction. Par exemple, si une révision a été validée avant cette date de début `2019-06-05T00:00:00Z` et qu'elle est restée active après cette date de début, cet exemple de requête renverra cette révision dans les résultats.
Assurez-vous de remplacer l'`id`heure de début et l'heure de fin par vos propres valeurs, le cas échéant.
```
SELECT * FROM history(VehicleRegistration, `2019-06-05T00:00:00Z`, `2019-06-05T23:59:59Z`) AS h
WHERE h.metadata.id = 'ADR2Ll1fGsU4Jr4EqTdnQF' --replace with your id
```
Les résultats de votre requête doivent ressembler à ce qui suit.
```
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:14
},
hash:{{B2wYwrHKOWsmIBmxUgPRrTx9lv36tMlod2xVvWNiTbo=}},
data: {
VIN: "1HVBBAANXWH544237",
LicensePlateNumber: "LS477D",
State: "WA",
City: "Tacoma",
PendingPenaltyTicketAmount: 42.20,
ValidFromDate: 2011-10-26T,
ValidToDate: 2023-09-25T,
Owners: {
PrimaryOwner: { PersonId: "KmA3XPKKFqYCP2zhR3d0Ho" },
SecondaryOwners: []
}
},
metadata:{
id:"ADR2Ll1fGsU4Jr4EqTdnQF",
version:0,
txTime:2019-06-05T20:53:321d-3Z,
txId:"HgXAkLjAtV0HQ4lNYdzX60"
}
},
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:17
},
hash:{{LGSFZ4iEYWZeMwmAqcxxNyT4wbCtuMOmFCj8pEd6Mp0=}},
data: {
VIN: "1HVBBAANXWH544237",
LicensePlateNumber: "LS477D",
State: "WA",
PendingPenaltyTicketAmount: 42.20,
ValidFromDate: 2011-10-26T,
ValidToDate: 2023-09-25T,
Owners: {
PrimaryOwner: { PersonId: "KmA3XPKKFqYCP2zhR3d0Ho" },
SecondaryOwners: []
},
City: "Bellevue"
},
metadata:{
id:"ADR2Ll1fGsU4Jr4EqTdnQF",
version:1,
txTime:2019-06-05T21:01:442d-3Z,
txId:"9cArhIQV5xf5Tf5vtsPwPq"
}
},
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:19
},
hash:{{7bm5DUwpqJFGrmZpb7h9wAxtvggYLPcXq+LAobi9fDg=}},
metadata:{
id:"ADR2Ll1fGsU4Jr4EqTdnQF",
version:2,
txTime:2019-06-05T21:03:76d-3Z,
txId:"9GslbtDtpVHAgYghR5FXbZ"
}
}
```
La sortie inclut des attributs de métadonnées qui fournissent des détails sur le moment où chaque élément a été modifié et par quelle transaction. À partir de ces données, vous pouvez voir ce qui suit :
+ Le document est identifié de manière unique par son assigné par le système `id` :. `ADR2Ll1fGsU4Jr4EqTdnQF` Il s'agit d'un UUID représenté dans une chaîne codée en Base62.
+ Une `INSERT` instruction crée la révision initiale d'un document (version`0`).
+ Chaque mise à jour suivante crée une nouvelle révision avec le même document `id` et un numéro de version incrémenté.
+ Le `txId` champ indique la transaction qui a validé chaque révision et `txTime` indique quand chacune a été validée.
+ Une `DELETE` instruction crée une nouvelle mais dernière révision d'un document. Cette révision finale contient uniquement des métadonnées.
Pour savoir comment supprimer définitivement une révision, passez à[Rédaction de révisions de documents](working.redaction.md).
# Rédaction de révisions de documents
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Dans Amazon QLDB, `DELETE` une instruction ne supprime logiquement un document qu'en créant une nouvelle révision qui le marque comme supprimé. QLDB prend également en charge *une opération de rédaction de données* qui vous permet de supprimer définitivement les révisions de document inactives dans l'historique d'un tableau.
**Note**
Les registres créés avant le 22 juillet 2021 ne sont actuellement pas éligibles à la rédaction. Vous pouvez consulter l'heure de création de votre registre sur la console Amazon QLDB.
L'opération de rédaction supprime uniquement les données utilisateur dans la révision spécifiée et laisse inchangées la séquence du journal et les métadonnées du document. Cela permet de préserver l'intégrité globale des données de votre registre.
Avant de commencer à rédiger des données dans QLDB, assurez-vous de les consulter dans la référence Amazon QLDB partiQL [Considérations et limites relatives à la rédaction](ql-stored-procedures.redact_revision.md#ql-stored-procedures.redact_revision.considerations) *partiQL*.
**Topics**
+ [
## Procédure stockée de rédaction
](#working.redaction.stored-proc)
+ [
## Vérifier si une rédaction est complète
](#working.redaction.check-completion)
+ [
## Exemple de rédaction
](#working.redaction.example)
+ [
## Supprimer et biffer une révision active
](#working.redaction.active-revision)
+ [
## Rédaction d'un champ particulier dans une révision
](#working.redaction.field)
## Procédure stockée de rédaction
Vous pouvez utiliser la procédure [RÉDACTION\$1RÉVISION](ql-stored-procedures.redact_revision.md) stockée pour supprimer définitivement une révision individuelle inactive dans un registre. Cette procédure stockée supprime toutes les données utilisateur de la révision spécifiée, à la fois dans le stockage indexé et dans le stockage des journaux. Cependant, la séquence du journal et les métadonnées du document, y compris l'identifiant et le hachage du document, restent inchangées. *Cette opération est irréversible.*
La révision de document spécifiée doit être une révision inactive dans l'historique. La dernière révision active d'un document n'est pas éligible à la rédaction.
Pour supprimer plusieurs révisions, vous devez exécuter la procédure stockée une fois pour chaque révision. Vous pouvez supprimer une révision par transaction.
**Syntaxe**
```
EXEC REDACT_REVISION `block-address`, 'table-id', 'document-id'
```Arguments
`*block-address*`
Emplacement du bloc de journal où se trouve la révision du document à supprimer. Une adresse est une structure Amazon Ion qui comporte deux champs : `strandId` et`sequenceNo`.
Il s'agit d'une valeur littérale ionique qui est indiquée par des backticks. Par exemple :
```
`{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`
```
'*table-id*'
L'ID unique du tableau dont vous souhaitez supprimer la révision du document, indiqué par des guillemets simples.
'*document-id*'
L'ID de document unique de la révision à supprimer, indiqué par des guillemets simples.
## Vérifier si une rédaction est complète
Lorsque vous soumettez une demande de suppression en exécutant la procédure stockée, QLDB traite la rédaction des données de manière asynchrone. Une fois la révision terminée, les données utilisateur (représentées par la `data` structure) sont supprimées définitivement. Pour vérifier si une demande de rédaction est terminée, vous pouvez utiliser l'une des méthodes suivantes :
+ [Exportation de journaux](export-journal.md)
+ [Stream du journal](streams.md)
+ [GetBlock Opération d'API](https://docs.aws.amazon.com/qldb/latest/developerguide/API_GetBlock.html)
+ [GetRevision Opération d'API](https://docs.aws.amazon.com/qldb/latest/developerguide/API_GetRevision.html)
+ [Fonction d'historique](working.history.md#working.history.function)— **Remarque :** une fois qu'une rédaction est terminée dans le journal, il peut s'écouler un certain temps avant que les requêtes d'historique n'affichent le résultat de la rédaction. Il se peut que certaines révisions soient expurgées avant d'autres lorsque la rédaction asynchrone est terminée, mais les requêtes d'historique finiront par afficher les résultats complets.
Une fois la rédaction d'une révision terminée, la `data` structure de la révision est remplacée par un nouveau `dataHash` champ. La valeur de ce champ est le hachage ionique de la `data` structure supprimée, comme indiqué dans l'exemple suivant. Par conséquent, le registre conserve l'intégrité globale de ses données et reste vérifiable cryptographiquement par le biais des opérations d'API de vérification existantes. Pour en savoir plus sur la vérification, consultez[Vérification des données dans Amazon QLDB](verification.md).
## Exemple de rédaction
Prenez en compte le document d'immatriculation du véhicule que vous avez examiné précédemment[Consultation de l'historique des révisions](working.history.md). Supposons que vous souhaitiez supprimer la deuxième révision (`version:1`). L'exemple de requête suivant montre cette révision avant la rédaction. Dans les résultats de la requête, la `data` structure qui sera expurgée est surlignée dans*red italics*.
```
SELECT * FROM history(VehicleRegistration) AS h
WHERE h.metadata.id = 'ADR2Ll1fGsU4Jr4EqTdnQF' --replace with your id
AND h.metadata.version = 1
```
```
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:17
},
hash:{{LGSFZ4iEYWZeMwmAqcxxNyT4wbCtuMOmFCj8pEd6Mp0=}},
data: {
VIN: "1HVBBAANXWH544237",
LicensePlateNumber: "LS477D",
State: "WA",
PendingPenaltyTicketAmount: 42.20,
ValidFromDate: 2011-10-26T,
ValidToDate: 2023-09-25T,
Owners: {
PrimaryOwner: { PersonId: "KmA3XPKKFqYCP2zhR3d0Ho" },
SecondaryOwners: []
},
City: "Bellevue"
},
metadata:{
id:"ADR2Ll1fGsU4Jr4EqTdnQF",
version:1,
txTime:2019-06-05T21:01:442d-3Z,
txId:"9cArhIQV5xf5Tf5vtsPwPq"
}
}
```
Notez cela `blockAddress` dans les résultats de la requête, car vous devez transmettre cette valeur à la procédure `REDACT_REVISION` stockée. Recherchez ensuite l'ID unique de la `VehicleRegistration` table en interrogeant le [catalogue du système](working.catalog.md), comme suit.
```
SELECT tableId FROM information_schema.user_tables
WHERE name = 'VehicleRegistration'
```
Utilisez cet ID de table ainsi que l'ID du document et l'adresse du bloc pour exécuter`REDACT_REVISION`. L'ID de table et l'ID de document sont des chaînes littérales qui doivent être placées entre guillemets simples, et l'adresse du bloc est un littéral Ion entouré de backticks. Assurez-vous de remplacer ces arguments par vos propres valeurs, le cas échéant.
```
EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'
```
**Astuce**
*Lorsque vous utilisez la console QLDB ou le shell QLDB pour rechercher un ID de table ou de document (ou toute valeur littérale de chaîne), la valeur renvoyée est placée entre guillemets doubles.* Toutefois, lorsque vous spécifiez les arguments ID de table et ID de document de la procédure `REDACT_REVISION` stockée, vous devez placer les valeurs entre guillemets *simples*.
Cela est dû au fait que vous écrivez des instructions au format partiQL, alors que QLDB renvoie les résultats au format Amazon Ion. Pour plus de détails sur la syntaxe et la sémantique de partiQL dans QLDB, consultez. [Interroger Ion avec PartiQL](ql-reference.query.md)
Une demande de rédaction valide renvoie une structure Ion qui représente la révision du document que vous êtes en train de rédiger, comme suit.
```
{
blockAddress: {
strandId: "JdxjkR9bSYB5jMHWcI464T",
sequenceNo: 17
},
tableId: "5PLf9SXwndd63lPaSIa0O6",
documentId: "ADR2Ll1fGsU4Jr4EqTdnQF",
version: 1
}
```
Lorsque vous exécutez cette procédure stockée, QLDB traite votre demande de rédaction de manière asynchrone. Une fois la rédaction terminée, la `data` structure est définitivement supprimée et remplacée par un nouveau *`dataHash`* champ. La valeur de ce champ est le hachage ionique de la `data` structure supprimée, comme suit.
**Note**
Cet `dataHash` exemple est fourni à titre informatif uniquement et n'est pas une véritable valeur de hachage calculée.
```
{
blockAddress:{
strandId:"JdxjkR9bSYB5jMHWcI464T",
sequenceNo:17
},
hash:{{LGSFZ4iEYWZeMwmAqcxxNyT4wbCtuMOmFCj8pEd6Mp0=}},
dataHash: {{s83jd7sfhsdfhksj7hskjdfjfpIPP/DP2hvionas2d4=}},
metadata:{
id:"ADR2Ll1fGsU4Jr4EqTdnQF",
version:1,
txTime:2019-06-05T21:01:442d-3Z,
txId:"9cArhIQV5xf5Tf5vtsPwPq"
}
}
```
## Supprimer et biffer une révision active
Les révisions de document actives (c'est-à-dire les dernières révisions non supprimées de chaque document) ne sont pas éligibles à la rédaction des données. Avant de pouvoir supprimer une révision active, vous devez d'abord la mettre à jour ou la supprimer. Cela place la révision précédemment active dans l'historique et la rend éligible à la rédaction.
Si votre cas d'utilisation nécessite que l'intégralité du document soit marquée comme supprimée, vous devez d'abord utiliser une instruction [DELETE](ql-reference.delete.md). Par exemple, l'instruction suivante supprime logiquement le `VehicleRegistration` document dont le numéro VIN est. `1HVBBAANXWH544237`
```
DELETE FROM VehicleRegistration AS r
WHERE r.VIN = '1HVBBAANXWH544237'
```
Rédigez ensuite la révision précédente avant cette suppression, comme décrit précédemment. Si nécessaire, vous pouvez également modifier individuellement les révisions précédentes.
Si votre cas d'utilisation nécessite que le document reste actif, vous devez d'abord utiliser une instruction [UPDATE](ql-reference.update.md) ou [FROM](ql-reference.from.md) pour masquer ou supprimer les champs que vous souhaitez expurger. Ce processus est décrit dans la section suivante.
## Rédaction d'un champ particulier dans une révision
QLDB ne prend pas en charge la rédaction d'un champ particulier dans le cadre d'une révision de document. Pour ce faire, vous pouvez d'abord utiliser une instruction [UPDATE-REMOVE](ql-reference.update.md) ou [FROM-REMOVE pour supprimer](ql-reference.from.md) un champ existant d'une révision. Par exemple, l'instruction suivante supprime le `LicensePlateNumber` champ du `VehicleRegistration` document dont le numéro VIN est`1HVBBAANXWH544237`.
```
UPDATE VehicleRegistration AS r
REMOVE r.LicensePlateNumber
WHERE r.VIN = '1HVBBAANXWH544237'
```
Rédigez ensuite la révision précédente avant cette suppression, comme décrit précédemment. Si nécessaire, vous pouvez également supprimer individuellement toutes les révisions précédentes qui incluent ce champ désormais supprimé.
Pour savoir comment optimiser vos requêtes, passez à[Optimisation des performances des requêtes](working.optimize.md).
# Optimisation des performances des requêtes
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Amazon QLDB est conçu pour répondre aux besoins des charges de travail de traitement des transactions en ligne (OLTP) à hautes performances. Cela signifie que QLDB est optimisé pour un ensemble spécifique de modèles de requêtes, même s'il prend en charge les fonctionnalités de requête de type SQL. Il est essentiel de concevoir des applications et leurs modèles de données pour fonctionner avec ces modèles de requêtes. Dans le cas contraire, au fur et à mesure que vos tables s'agrandissent, vous rencontrerez des problèmes de performances importants, notamment la latence des requêtes, les délais d'expiration des transactions et les conflits de simultanéité.
Cette section décrit les contraintes de requête dans QLDB et fournit des conseils pour écrire des requêtes optimales compte tenu de ces contraintes.
**Topics**
+ [
## Limite de délai d'expiration des transactions
](#working.optimize.txn-timeout)
+ [
## Conflits de simultanéité
](#working.optimize.occ)
+ [
## Modèles de requêtes optimaux
](#working.optimize.patterns)
+ [
## Modèles de requêtes à éviter
](#working.optimize.avoid)
+ [
## Surveillance des performances
](#working.optimize.monitor)
## Limite de délai d'expiration des transactions
[Dans QLDB, chaque instruction partiQL (y compris `SELECT` chaque requête) est traitée dans une transaction et est soumise à une limite de délai d'expiration de transaction.](limits.md#limits.fixed) Une transaction peut être exécutée pendant **30 secondes** au maximum avant d'être validée. Après cette limite, QLDB rejette tout travail effectué sur la transaction et supprime la session qui a exécuté [la](concurrency.md#concurrency.sessions) transaction. Cette limite protège le client du service contre les fuites de sessions en démarrant des transactions et non en les validant ou en les annulant.
## Conflits de simultanéité
QLDB implémente le contrôle de simultanéité en *utilisant le contrôle de simultanéité optimiste* (OCC). Les requêtes sous-optimales peuvent également entraîner davantage de conflits OCC. Pour plus d'informations sur l'OCC, consultez[Modèle de simultanéité Amazon QLDB](concurrency.md).
## Modèles de requêtes optimaux
Il est recommandé d'exécuter des instructions avec une clause de `WHERE` prédicat filtrant en fonction d'un champ indexé ou d'un identifiant de document. QLDB nécessite *un opérateur d'*égalité `=` (`IN`ou) sur un champ indexé pour rechercher efficacement un document.
Vous trouverez ci-dessous des exemples de modèles de requêtes optimaux dans la [vue utilisateur](working.userdata.md).
```
--Indexed field (VIN) lookup using the = operator
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151'
--Indexed field (VIN) AND non-indexed field (City) lookup
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle'
--Indexed field (VIN) lookup using the IN operator
SELECT * FROM VehicleRegistration
WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
--Document ID (r_id) lookup using the BY clause
SELECT * FROM VehicleRegistration BY r_id
WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'
```
Toute requête qui ne suit pas ces modèles appelle une *analyse complète de la table*. L'analyse des tables peut entraîner l'expiration des délais de transaction pour les requêtes portant sur des tables volumineuses ou les requêtes renvoyant de grands ensembles de résultats. Ils peuvent également [entraîner des conflits entre l'OCC et des transactions concurrentes](concurrency.md#concurrency.indexes).
**Indices de cardinalité élevés**
Nous recommandons d'indexer les champs contenant des valeurs de cardinalité élevées. Par exemple, les `LicensePlateNumber` champs `VIN` et de la `VehicleRegistration` table sont des champs indexés conçus pour être uniques.
Évitez d'indexer les champs à faible cardinalité tels que les codes de statut, les états ou provinces d'adresse et les codes postaux. Si vous indexez un tel champ, vos requêtes peuvent produire de grands ensembles de résultats *susceptibles d'entraîner des délais d'expiration des transactions ou de provoquer des conflits OCC involontaires*.
**Requêtes d'affichage validées**
Les requêtes que vous exécutez dans la [vue validée](working.metadata.md) suivent les mêmes directives d'optimisation que les requêtes de vue utilisateur. Les index que vous créez sur une table sont également utilisés pour les requêtes dans la vue validée.
**Historique des requêtes relatives aux fonctions**
Les requêtes de [fonction d'historique](working.history.md) n'utilisent pas les index que vous créez sur une table. L'historique QLDB est indexé uniquement par identifiant de document, et vous ne pouvez pas créer d'index d'historique supplémentaires pour le moment.
Il est recommandé de qualifier une requête d'historique à la fois par une plage de dates (heure de *début et heure* de *fin*) et par un identifiant de document (`metadata.id`). Les requêtes d'historique qui incluent une heure de début et une heure de fin bénéficient de la qualification par plage de dates.
**Requêtes de jointure internes**
Pour les requêtes de jointure interne, utilisez des critères de jointure qui incluent au moins un champ indexé pour la table sur le côté droit de la jointure. Sans index de jointure, une requête de jointure appelle plusieurs scans de table : pour chaque document de la table de gauche de la jointure, la requête scanne entièrement la table de droite. La meilleure pratique consiste à joindre des champs indexés pour chaque table que vous joignez, en plus de spécifier un prédicat d'`WHERE`égalité pour au moins une table.
Par exemple, la requête suivante joint les `Vehicle` tables `VehicleRegistration` et dans leurs `VIN` champs respectifs, qui sont tous deux indexés. Cette requête possède également un prédicat d'égalité activé`VehicleRegistration.VIN`.
```
SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v
ON r.VIN = v.VIN
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')
```
Choisissez des indices de cardinalité élevés pour les critères de jointure et les prédicats d'égalité dans vos requêtes de jointure.
## Modèles de requêtes à éviter
Voici quelques exemples d'instructions **sous-optimales** qui ne s'adaptent pas bien aux grandes tables de QLDB. Nous vous recommandons vivement de ne pas vous fier à ce type de requêtes pour les tables qui s'agrandissent au fil du temps, car vos requêtes finiront par entraîner des délais d'expiration des transactions. Les tables contenant des documents dont la taille varie, il est difficile de définir des limites précises pour les requêtes non indexées.
```
--No predicate clause
SELECT * FROM Vehicle
--COUNT() is not an optimized function
SELECT COUNT(*) FROM Vehicle
--Low-cardinality predicate
SELECT * FROM Vehicle WHERE Color = 'Silver'
--Inequality (>) does not qualify for indexed lookup
SELECT * FROM Vehicle WHERE "Year" > 2019
--Inequality (LIKE)
SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%'
--Inequality (BETWEEN)
SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration
WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T`
--No predicate clause
DELETE FROM Vehicle
--No document id, and no date range for the history() function
SELECT * FROM history(Vehicle)
```
En général, nous *ne recommandons pas* d'exécuter les types de modèles de requête suivants pour les cas d'utilisation en production dans QLDB :
+ Requêtes de traitement analytique en ligne (OLAP)
+ Requêtes exploratoires sans clause de prédicat
+ Requêtes relatives aux rapports
+ Recherche de texte
Nous vous recommandons plutôt de diffuser vos données vers un service de base de données spécialement conçu et optimisé pour les cas d'utilisation analytiques. Par exemple, vous pouvez diffuser des données QLDB vers OpenSearch Amazon Service afin de fournir des fonctionnalités de recherche en texte intégral sur des documents. Pour un exemple d'application illustrant ce cas d'utilisation, consultez le GitHub référentiel [amazon-qldb-streaming-amazonaws-samples/](https://github.com/aws-samples/amazon-qldb-streaming-amazon-opensearch-service-sample-python) -. opensearch-service-sample-python Pour plus d'informations sur les flux QLDB, consultez. [Diffusion en continu de données de journaux depuis Amazon QLDB](streams.md)
## Surveillance des performances
Le pilote QLDB fournit des informations de synchronisation et d'utilisation des E/S consommées dans l'objet de résultat d'une instruction. Vous pouvez utiliser ces métriques pour identifier les instructions partiQL inefficaces. Pour en savoir plus, rendez-vous sur[Obtenir les statistiques des instructions PartiQL](working.statement-stats.md).
Vous pouvez également utiliser Amazon CloudWatch pour suivre les performances de votre registre en matière d'opérations de données. Surveillez la `CommandLatency` métrique pour une valeur spécifiée `LedgerName` et`CommandType`. Pour de plus amples informations, veuillez consulter [Surveillance avec Amazon CloudWatch](monitoring-cloudwatch.md). Pour savoir comment QLDB utilise les commandes pour gérer les opérations de données, consultez. [Gestion des sessions avec le chauffeur](driver-session-management.md)
# Obtenir les statistiques des instructions PartiQL
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Amazon QLDB fournit des statistiques d'exécution des instructions qui peuvent vous aider à optimiser votre utilisation de QLDB en exécutant des instructions partiQL plus efficaces. QLDB renvoie ces statistiques ainsi que les résultats de l'instruction. Ils incluent des métriques qui quantifient l'utilisation des E/S consommées et le temps de traitement côté serveur, que vous pouvez utiliser pour identifier les instructions inefficaces.
[Cette fonctionnalité est actuellement disponible dans l'*éditeur partiQL* de la [console QLDB, du shell QLDB](console_QLDB.md)[et dans la dernière version du pilote QLDB](data-shell.md) pour toutes les langues prises en charge.](getting-started-driver.md) Vous pouvez également consulter les statistiques des relevés relatives à l'historique de vos requêtes sur la console.
**Topics**
+ [
## Utilisation des E/S
](#statement-stats.io-usage)
+ [
## Informations de chronométrage
](#statement-stats.timing-information)
## Utilisation des E/S
La métrique d'utilisation des E/S décrit le nombre de demandes d'E/S de lecture. Si le nombre de demandes d'E/S de lecture est plus élevé que prévu, cela indique que l'instruction n'est pas optimisée, par exemple en l'absence d'index. Nous vous recommandons de passer [Modèles de requêtes optimaux](working.optimize.md#working.optimize.patterns) en revue dans la rubrique précédente, *Optimisation des performances des requêtes*.
**Note**
Lorsque vous exécutez une `CREATE INDEX` instruction sur une table non vide, la métrique d'utilisation des E/S inclut uniquement les demandes de lecture pour l'appel de création d'index synchrone.
QLDB crée l'index de tous les documents existants dans la table de manière asynchrone. Ces demandes de lecture asynchrones ne sont pas incluses dans la métrique d'utilisation des E/S figurant dans les résultats de votre relevé. Les demandes de lecture asynchrones sont facturées séparément et sont ajoutées à votre total d'E/S de lecture une fois la création de l'index terminée.
### Utilisation de la console QLDB
Pour connaître l'utilisation des E/S de lecture d'une instruction à l'aide de la console QLDB, procédez comme suit :
1. [Ouvrez la console Amazon QLDB à l'adresse /qldb. https://console.aws.amazon.com](https://console.aws.amazon.com/qldb)
1. Dans le volet de navigation, choisissez l'éditeur **PartiQL**.
1. Choisissez un registre dans la liste déroulante des livres.
1. Dans la fenêtre de l'éditeur de requêtes, entrez l'instruction de votre choix, puis choisissez **Exécuter**. Voici un exemple de requête.
```
SELECT * FROM testTable WHERE firstName = 'Jim'
```
Pour exécuter une instruction, vous pouvez également utiliser le raccourci clavier Ctrl \$1 Enter pour Windows ou Cmd \$1 Return pour macOS. Pour plus de raccourcis clavier, voir[Raccourcis clavier de l'éditeur PartiQL](console_QLDB.md#console_QLDB.partiql-editor-shortcuts).
1. Sous la fenêtre de l'éditeur de requêtes, les résultats de votre requête incluent les *E/S de lecture*, c'est-à-dire le nombre de demandes de lecture effectuées par l'instruction.
Vous pouvez également consulter les E/S lues de l'historique de vos requêtes en procédant comme suit :
1. Dans le volet de navigation, choisissez **Recent queries** sous l'éditeur **partiQL**.
1. La colonne **Read I/Os** affiche le nombre de demandes de lecture effectuées par chaque instruction.
### Utilisation du pilote QLDB
Pour connaître l'utilisation des E/S d'une instruction à l'aide du pilote QLDB, appelez `getConsumedIOs` le curseur de flux ou le curseur mis en mémoire tampon du résultat.
Les exemples de code suivants montrent comment obtenir des E/S de lecture à partir du *curseur de flux* du résultat d'une instruction.
------
#### [ Java ]
```
import com.amazon.ion.IonSystem;
import com.amazon.ion.IonValue;
import com.amazon.ion.system.IonSystemBuilder;
import software.amazon.qldb.IOUsage;
import software.amazon.qldb.Result;
IonSystem ionSystem = IonSystemBuilder.standard().build();
IonValue ionFirstName = ionSystem.newString("Jim");
driver.execute(txn -> {
Result result = txn.execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
for (IonValue ionValue : result) {
// User code here to handle results
}
IOUsage ioUsage = result.getConsumedIOs();
long readIOs = ioUsage.getReadIOs();
});
```
------
#### [ .NET ]
```
using Amazon.IonDotnet.Builders;
using Amazon.IonDotnet.Tree;
using Amazon.QLDB.Driver;
using IAsyncResult = Amazon.QLDB.Driver.IAsyncResult;
// This is one way of creating Ion values. We can also use a ValueFactory.
// For more details, see: https://docs.aws.amazon.com/qldb/latest/developerguide/driver-cookbook-dotnet.html#cookbook-dotnet.ion
IIonValue ionFirstName = IonLoader.Default.Load("Jim");
await driver.Execute(async txn =>
{
IAsyncResult result = await txn.Execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
// Iterate through stream cursor to accumulate read IOs.
await foreach (IIonValue ionValue in result)
{
// User code here to handle results.
// Warning: It is bad practice to rely on results within a lambda block, unless
// it is to check the state of a result. This is because lambdas are retryable.
}
var ioUsage = result.GetConsumedIOs();
var readIOs = ioUsage?.ReadIOs;
});
```
**Note**
Pour convertir en code synchrone, supprimez les `async` mots clés `await` et, puis remplacez le `IAsyncResult` type par. `IResult`
------
#### [ Go ]
```
import (
"context"
"fmt"
"github.com/awslabs/amazon-qldb-driver-go/v2/qldbdriver"
)
driver.Execute(context.Background(), func(txn qldbdriver.Transaction) (interface{}, error) {
result, err := txn.Execute("SELECT * FROM testTable WHERE firstName = ?", "Jim")
if err != nil {
panic(err)
}
for result.Next(txn) {
// User code here to handle results
}
ioUsage := result.GetConsumedIOs()
readIOs := *ioUsage.GetReadIOs()
fmt.Println(readIOs)
return nil,nil
})
```
------
#### [ Node.js ]
```
import { IOUsage, ResultReadable, TransactionExecutor } from "amazon-qldb-driver-nodejs";
await driver.executeLambda(async (txn: TransactionExecutor) => {
const result: ResultReadable = await txn.executeAndStreamResults("SELECT * FROM testTable WHERE firstName = ?", "Jim");
for await (const chunk of result) {
// User code here to handle results
}
const ioUsage: IOUsage = result.getConsumedIOs();
const readIOs: number = ioUsage.getReadIOs();
});
```
------
#### [ Python ]
```
def get_read_ios(transaction_executor):
cursor = transaction_executor.execute_statement("SELECT * FROM testTable WHERE firstName = ?", "Jim")
for row in cursor:
# User code here to handle results
pass
consumed_ios = cursor.get_consumed_ios()
read_ios = consumed_ios.get('ReadIOs')
qldb_driver.execute_lambda(lambda txn: get_read_ios(txn))
```
------
Les exemples de code suivants montrent comment obtenir des E/S de lecture à partir du *curseur mis en mémoire tampon du résultat* d'une instruction. Cela renvoie le nombre total d'E/S de lecture `ExecuteStatement` et de `FetchPage` demandes.
------
#### [ Java ]
```
import com.amazon.ion.IonSystem;
import com.amazon.ion.IonValue;
import com.amazon.ion.system.IonSystemBuilder;
import software.amazon.qldb.IOUsage;
import software.amazon.qldb.Result;
IonSystem ionSystem = IonSystemBuilder.standard().build();
IonValue ionFirstName = ionSystem.newString("Jim");
Result result = driver.execute(txn -> {
return txn.execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
});
IOUsage ioUsage = result.getConsumedIOs();
long readIOs = ioUsage.getReadIOs();
```
------
#### [ .NET ]
```
using Amazon.IonDotnet.Builders;
using Amazon.IonDotnet.Tree;
using Amazon.QLDB.Driver;
using IAsyncResult = Amazon.QLDB.Driver.IAsyncResult;
IIonValue ionFirstName = IonLoader.Default.Load("Jim");
IAsyncResult result = await driver.Execute(async txn =>
{
return await txn.Execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
});
var ioUsage = result.GetConsumedIOs();
var readIOs = ioUsage?.ReadIOs;
```
**Note**
Pour convertir en code synchrone, supprimez les `async` mots clés `await` et, puis remplacez le `IAsyncResult` type par. `IResult`
------
#### [ Go ]
```
import (
"context"
"fmt"
"github.com/awslabs/amazon-qldb-driver-go/v2/qldbdriver"
)
result, err := driver.Execute(context.Background(), func(txn qldbdriver.Transaction) (interface{}, error) {
result, err := txn.Execute("SELECT * FROM testTable WHERE firstName = ?", "Jim")
if err != nil {
return nil, err
}
return txn.BufferResult(result)
})
if err != nil {
panic(err)
}
qldbResult := result.(*qldbdriver.BufferedResult)
ioUsage := qldbResult.GetConsumedIOs()
readIOs := *ioUsage.GetReadIOs()
fmt.Println(readIOs)
```
------
#### [ Node.js ]
```
import { IOUsage, Result, TransactionExecutor } from "amazon-qldb-driver-nodejs";
const result: Result = await driver.executeLambda(async (txn: TransactionExecutor) => {
return await txn.execute("SELECT * FROM testTable WHERE firstName = ?", "Jim");
});
const ioUsage: IOUsage = result.getConsumedIOs();
const readIOs: number = ioUsage.getReadIOs();
```
------
#### [ Python ]
```
cursor = qldb_driver.execute_lambda(
lambda txn: txn.execute_statement("SELECT * FROM testTable WHERE firstName = ?", "Jim"))
consumed_ios = cursor.get_consumed_ios()
read_ios = consumed_ios.get('ReadIOs')
```
------
**Note**
Le curseur de flux est dynamique car il pagine le jeu de résultats. Par conséquent, les `getTimingInformation` opérations `getConsumedIOs` et renvoient les métriques accumulées à partir du moment où vous les appelez.
Le curseur mis en mémoire tampon met en mémoire tampon le jeu de résultats et renvoie le total des métriques cumulées.
## Informations de chronométrage
La métrique des informations temporelles décrit le temps de traitement côté serveur en millisecondes. Le temps de traitement côté serveur est défini comme le temps que QLDB consacre au traitement d'une instruction. Cela n'inclut pas le temps passé sur les appels réseau ou les pauses. Cette métrique permet de distinguer le temps de traitement côté service QLDB du temps de traitement côté client.
### Utilisation de la console QLDB
Pour obtenir les informations temporelles d'une instruction à l'aide de la console QLDB, procédez comme suit :
1. [Ouvrez la console Amazon QLDB à l'adresse /qldb. https://console.aws.amazon.com](https://console.aws.amazon.com/qldb)
1. Dans le volet de navigation, choisissez l'éditeur **PartiQL**.
1. Choisissez un registre dans la liste déroulante des livres.
1. Dans la fenêtre de l'éditeur de requêtes, entrez l'instruction de votre choix, puis choisissez **Exécuter**. Voici un exemple de requête.
```
SELECT * FROM testTable WHERE firstName = 'Jim'
```
Pour exécuter une instruction, vous pouvez également utiliser le raccourci clavier Ctrl \$1 Enter pour Windows ou Cmd \$1 Return pour macOS. Pour plus de raccourcis clavier, voir[Raccourcis clavier de l'éditeur PartiQL](console_QLDB.md#console_QLDB.partiql-editor-shortcuts).
1. Sous la fenêtre de l'éditeur de requêtes, les résultats de votre requête incluent la *latence côté serveur*, c'est-à-dire le délai entre le moment où QLDB a reçu la demande d'instruction et le moment où il a envoyé la réponse. Il s'agit d'un sous-ensemble de la durée totale de la requête.
Vous pouvez également consulter les informations temporelles de l'historique de vos requêtes en procédant comme suit :
1. Dans le volet de navigation, choisissez **Recent queries** sous l'éditeur **partiQL**.
1. La colonne **Temps d'exécution (ms)** affiche ces informations temporelles pour chaque instruction.
### Utilisation du pilote QLDB
Pour obtenir les informations temporelles d'une instruction à l'aide du pilote QLDB, appelez `getTimingInformation` le curseur de flux ou le curseur mis en mémoire tampon du résultat.
Les exemples de code suivants montrent comment obtenir le temps de traitement à partir du *curseur de flux* du résultat d'une instruction.
------
#### [ Java ]
```
import com.amazon.ion.IonSystem;
import com.amazon.ion.IonValue;
import com.amazon.ion.system.IonSystemBuilder;
import software.amazon.qldb.Result;
import software.amazon.qldb.TimingInformation;
IonSystem ionSystem = IonSystemBuilder.standard().build();
IonValue ionFirstName = ionSystem.newString("Jim");
driver.execute(txn -> {
Result result = txn.execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
for (IonValue ionValue : result) {
// User code here to handle results
}
TimingInformation timingInformation = result.getTimingInformation();
long processingTimeMilliseconds = timingInformation.getProcessingTimeMilliseconds();
});
```
------
#### [ .NET ]
```
using Amazon.IonDotnet.Builders;
using Amazon.IonDotnet.Tree;
using Amazon.QLDB.Driver;
using IAsyncResult = Amazon.QLDB.Driver.IAsyncResult;
IIonValue ionFirstName = IonLoader.Default.Load("Jim");
await driver.Execute(async txn =>
{
IAsyncResult result = await txn.Execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
// Iterate through stream cursor to accumulate processing time.
await foreach(IIonValue ionValue in result)
{
// User code here to handle results.
// Warning: It is bad practice to rely on results within a lambda block, unless
// it is to check the state of a result. This is because lambdas are retryable.
}
var timingInformation = result.GetTimingInformation();
var processingTimeMilliseconds = timingInformation?.ProcessingTimeMilliseconds;
});
```
**Note**
Pour convertir en code synchrone, supprimez les `async` mots clés `await` et, puis remplacez le `IAsyncResult` type par. `IResult`
------
#### [ Go ]
```
import (
"context"
"fmt"
"github.com/awslabs/amazon-qldb-driver-go/v2/qldbdriver"
)
driver.Execute(context.Background(), func(txn qldbdriver.Transaction) (interface{}, error) {
result, err := txn.Execute("SELECT * FROM testTable WHERE firstName = ?", "Jim")
if err != nil {
panic(err)
}
for result.Next(txn) {
// User code here to handle results
}
timingInformation := result.GetTimingInformation()
processingTimeMilliseconds := *timingInformation.GetProcessingTimeMilliseconds()
fmt.Println(processingTimeMilliseconds)
return nil, nil
})
```
------
#### [ Node.js ]
```
import { ResultReadable, TimingInformation, TransactionExecutor } from "amazon-qldb-driver-nodejs";
await driver.executeLambda(async (txn: TransactionExecutor) => {
const result: ResultReadable = await txn.executeAndStreamResults("SELECT * FROM testTable WHERE firstName = ?", "Jim");
for await (const chunk of result) {
// User code here to handle results
}
const timingInformation: TimingInformation = result.getTimingInformation();
const processingTimeMilliseconds: number = timingInformation.getProcessingTimeMilliseconds();
});
```
------
#### [ Python ]
```
def get_processing_time_milliseconds(transaction_executor):
cursor = transaction_executor.execute_statement("SELECT * FROM testTable WHERE firstName = ?", "Jim")
for row in cursor:
# User code here to handle results
pass
timing_information = cursor.get_timing_information()
processing_time_milliseconds = timing_information.get('ProcessingTimeMilliseconds')
qldb_driver.execute_lambda(lambda txn: get_processing_time_milliseconds(txn))
```
------
Les exemples de code suivants montrent comment obtenir le temps de traitement à partir du *curseur mis en mémoire tampon* du résultat d'une instruction. Cela renvoie le temps de traitement total des `FetchPage` demandes `ExecuteStatement` et des demandes.
------
#### [ Java ]
```
import com.amazon.ion.IonSystem;
import com.amazon.ion.IonValue;
import com.amazon.ion.system.IonSystemBuilder;
import software.amazon.qldb.Result;
import software.amazon.qldb.TimingInformation;
IonSystem ionSystem = IonSystemBuilder.standard().build();
IonValue ionFirstName = ionSystem.newString("Jim");
Result result = driver.execute(txn -> {
return txn.execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
});
TimingInformation timingInformation = result.getTimingInformation();
long processingTimeMilliseconds = timingInformation.getProcessingTimeMilliseconds();
```
------
#### [ .NET ]
```
using Amazon.IonDotnet.Builders;
using Amazon.IonDotnet.Tree;
using Amazon.QLDB.Driver;
using IAsyncResult = Amazon.QLDB.Driver.IAsyncResult;
IIonValue ionFirstName = IonLoader.Default.Load("Jim");
IAsyncResult result = await driver.Execute(async txn =>
{
return await txn.Execute("SELECT * FROM testTable WHERE firstName = ?", ionFirstName);
});
var timingInformation = result.GetTimingInformation();
var processingTimeMilliseconds = timingInformation?.ProcessingTimeMilliseconds;
```
**Note**
Pour convertir en code synchrone, supprimez les `async` mots clés `await` et, puis remplacez le `IAsyncResult` type par. `IResult`
------
#### [ Go ]
```
import (
"context"
"fmt"
"github.com/awslabs/amazon-qldb-driver-go/v2/qldbdriver"
)
result, err := driver.Execute(context.Background(), func(txn qldbdriver.Transaction) (interface{}, error) {
result, err := txn.Execute("SELECT * FROM testTable WHERE firstName = ?", "Jim")
if err != nil {
return nil, err
}
return txn.BufferResult(result)
})
if err != nil {
panic(err)
}
qldbResult := result.(*qldbdriver.BufferedResult)
timingInformation := qldbResult.GetTimingInformation()
processingTimeMilliseconds := *timingInformation.GetProcessingTimeMilliseconds()
fmt.Println(processingTimeMilliseconds)
```
------
#### [ Node.js ]
```
import { Result, TimingInformation, TransactionExecutor } from "amazon-qldb-driver-nodejs";
const result: Result = await driver.executeLambda(async (txn: TransactionExecutor) => {
return await txn.execute("SELECT * FROM testTable WHERE firstName = ?", "Jim");
});
const timingInformation: TimingInformation = result.getTimingInformation();
const processingTimeMilliseconds: number = timingInformation.getProcessingTimeMilliseconds();
```
------
#### [ Python ]
```
cursor = qldb_driver.execute_lambda(
lambda txn: txn.execute_statement("SELECT * FROM testTable WHERE firstName = ?", "Jim"))
timing_information = cursor.get_timing_information()
processing_time_milliseconds = timing_information.get('ProcessingTimeMilliseconds')
```
------
**Note**
Le curseur de flux est dynamique car il pagine le jeu de résultats. Par conséquent, les `getTimingInformation` opérations `getConsumedIOs` et renvoient les métriques accumulées à partir du moment où vous les appelez.
Le curseur mis en mémoire tampon met en mémoire tampon le jeu de résultats et renvoie le total des métriques cumulées.
Pour savoir comment interroger le catalogue du système, passez à[Interrogation du catalogue du système](working.catalog.md).
# Interrogation du catalogue du système
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Chaque table que vous créez dans un registre Amazon QLDB possède un identifiant unique attribué par le système. Vous pouvez trouver l'ID d'une table, sa liste d'index et d'autres métadonnées en interrogeant la table du catalogue du système. `information_schema.user_tables`
Tous les identifiants uniques universels (UUID) assignés par le système IDs sont chacun représentés dans une chaîne codée en Base62. Pour de plus amples informations, veuillez consulter [Unique IDs dans Amazon QLDB](working.unique-id.md).
L'exemple suivant montre les résultats d'une requête qui renvoie les attributs de métadonnées de la `VehicleRegistration` table.
```
SELECT * FROM information_schema.user_tables
WHERE name = 'VehicleRegistration'
```
```
{
tableId: "5PLf9SXwndd63lPaSIa0O6",
name: "VehicleRegistration",
indexes: [
{ indexId: "Djg2nt0yIs2GY0T29Kud1z", expr: "[VIN]", status: "ONLINE" },
{ indexId: "4tPW3fUhaVhDinRgKRLhGU", expr: "[LicensePlateNumber]", status: "BUILDING" }
],
status: "ACTIVE"
}
```
**Champs de métadonnées de table**
+ `tableId`— L'identifiant unique de la table.
+ `name`— Le nom de la table.
+ `indexes`— Liste des index de la table.
+ `indexId`— L'identifiant unique de l'index.
+ `expr`— Le chemin du document indexé. Ce champ est une chaîne au format :`[fieldName]`.
+ `status`— État actuel de l'index (`BUILDING``FINALIZING`,`ONLINE`,`FAILED`, ou`DELETING`). QLDB n'utilise pas l'index dans les requêtes tant que le statut n'est pas atteint. `ONLINE`
+ `message`— Le message d'erreur qui décrit la raison pour laquelle l'index possède un `FAILED` statut. Ce champ n'est inclus que pour les index défaillants.
+ `status`— L'état actuel de la table (`ACTIVE`ou`INACTIVE`). Une table devient `INACTIVE` quand vous êtes `DROP` assise.
Pour savoir comment gérer les tables à l'aide `UNDROP TABLE` des instructions `DROP TABLE` et, passez à[Gestion des tables](working.manage-tables.md).
# Gestion des tables
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Cette section explique comment gérer les tables à l'aide des `UNDROP TABLE` instructions `DROP TABLE` and dans Amazon QLDB. Il décrit également comment baliser les tables pendant leur création. Les quotas relatifs au nombre de tables actives et au nombre total de tables que vous pouvez créer sont définis dans[Quotas et limites dans Amazon QLDB](limits.md#limits.fixed).
**Topics**
+ [
## Marquer les tables lors de leur création
](#working.manage-tables.tags)
+ [
## Tables rabattables
](#working.manage-tables.drop)
+ [
## Consultation de l'historique des tables inactives
](#working.history.inactive-table)
+ [
## Réactivation des tables
](#working.history.undrop-table)
## Marquer les tables lors de leur création
**Note**
Le balisage des tables lors de leur création est actuellement pris en charge pour les registres en mode `STANDARD` autorisations uniquement.
Vous pouvez baliser les ressources de votre table. Pour gérer les balises pour les tables existantes, utilisez les opérations AWS Management Console ou l'API `TagResource``UntagResource`, et`ListTagsForResource`. Pour de plus amples informations, veuillez consulter [Balisage des ressources Amazon QLDB](tagging.md).
Vous pouvez également définir des balises de table lors de la création de la table à l'aide de la console QLDB ou en les spécifiant dans une `CREATE TABLE` instruction partiQL. L'exemple suivant crée une table nommée `Vehicle` avec la balise`environment=production`.
```
CREATE TABLE Vehicle WITH (aws_tags = `{'environment': 'production'}`)
```
En attribuant des étiquettes aux ressources au moment de la création, vous pouvez supprimer la nécessité d'exécuter des scripts d'identification personnalisés après la création de ressources. Une fois qu'une table est balisée, vous pouvez contrôler l'accès à la table en fonction de ces balises. Par exemple, vous pouvez accorder un accès complet uniquement aux tables dotées d'une balise spécifique. Pour un exemple de politique JSON, consultez[Accès complet à toutes les actions en fonction des balises du tableau](security_iam_id-based-policy-examples.md#security_iam_id-based-policy-examples-full-tags).
## Tables rabattables
Pour supprimer un tableau, utilisez une [DROP TABLE](ql-reference.drop-table.md) instruction de base. Lorsque vous déposez une table dans QLDB, vous la désactivez simplement.
Par exemple, l'instruction suivante désactive la `VehicleRegistration` table.
```
DROP TABLE VehicleRegistration
```
Une `DROP TABLE` instruction renvoie l'ID attribué par le système à la table. Le statut de `VehicleRegistration` devrait désormais figurer `INACTIVE` dans la table du catalogue système [information\$1schema.user\$1tables](working.catalog.md).
```
SELECT status FROM information_schema.user_tables
WHERE name = 'VehicleRegistration'
```
## Consultation de l'historique des tables inactives
Outre le nom d'une table, vous pouvez également interroger le [Fonction d'historique](working.history.md#working.history.function) QLDB avec un ID de table comme premier argument d'entrée. Vous devez utiliser l'ID de table pour consulter l'historique d'une table inactive. Une fois qu'une table est désactivée, vous ne pouvez plus consulter son historique à l'aide du nom de la table.
Recherchez d'abord l'ID de la table en interrogeant la table du catalogue du système. Par exemple, la requête suivante renvoie le `tableId` de la `VehicleRegistration` table.
```
SELECT tableId FROM information_schema.user_tables
WHERE name = 'VehicleRegistration'
```
Vous pouvez ensuite utiliser cet ID pour exécuter la même requête d'historique à partir de[Consultation de l'historique des révisions](working.history.md). Voici un exemple qui interroge l'historique de l'ID de document `ADR2Ll1fGsU4Jr4EqTdnQF` à partir de l'ID de table`5PLf9SXwndd63lPaSIa0O6`. L'ID de table est une chaîne littérale qui doit être placée entre guillemets simples.
```
--replace both the table and document IDs with your values
SELECT * FROM history('5PLf9SXwndd63lPaSIa0O6', `2000T`, `2019-06-05T23:59:59Z`) AS h
WHERE h.metadata.id = 'ADR2Ll1fGsU4Jr4EqTdnQF'
```
## Réactivation des tables
Après avoir désactivé une table dans QLDB, vous pouvez utiliser l'instruction pour [TABLEAU DE DÉBALLAGE](ql-reference.undrop-table.md) la réactiver.
Tout d'abord, trouvez l'ID de la table à partir de`information_schema.user_tables`. Par exemple, la requête suivante renvoie le `tableId` de la `VehicleRegistration` table. Le statut doit être`INACTIVE`.
```
SELECT tableId FROM information_schema.user_tables
WHERE name = 'VehicleRegistration'
```
Utilisez ensuite cet identifiant pour réactiver la table. Voici un exemple qui permet de récupérer *l'ID de* table. `5PLf9SXwndd63lPaSIa0O6` Dans ce cas, l'ID de table est un identifiant unique que vous placez entre guillemets doubles.
```
UNDROP TABLE "5PLf9SXwndd63lPaSIa0O6"
```
Le statut de `VehicleRegistration` devrait désormais être`ACTIVE`.
Pour savoir comment créer, décrire et supprimer des index, passez à[Gestion des index](working.manage-indexes.md).
# Gestion des index
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Cette section explique comment créer, décrire et supprimer des index dans Amazon QLDB. Le quota du nombre d'index que vous pouvez créer par table est défini dans[Quotas et limites dans Amazon QLDB](limits.md#limits.fixed).
**Topics**
+ [
## Création d'index
](#working.manage-indexes.create)
+ [
## Décrire les index
](#working.manage-indexes.describe)
+ [
## Suppression d'index
](#working.manage-indexes.drop)
+ [
## Erreurs courantes
](#working.manage-indexes.errors)
## Création d'index
Comme décrit également dans[Création de tables et d'index](working.create.md#working.create.tables-indexes), vous pouvez utiliser l'instruction [CREATE INDEX](ql-reference.create-index.md) pour créer un index sur une table pour un champ de niveau supérieur spécifié, comme suit. Le nom de la table et le nom du champ indexé distinguent tous deux les majuscules et minuscules.
```
CREATE INDEX ON VehicleRegistration (VIN)
```
```
CREATE INDEX ON VehicleRegistration (LicensePlateNumber)
```
Chaque index que vous créez sur une table possède un identifiant unique attribué par le système. Pour trouver cet identifiant d'index, consultez la section suivante[Décrire les index](#working.manage-indexes.describe).
**Important**
QLDB a besoin d'un index pour rechercher efficacement un document. Sans index, QLDB doit effectuer une analyse complète de la table lors de la lecture de documents. Cela peut entraîner des problèmes de performances sur de grandes tables, notamment des conflits de simultanéité et des délais d'expiration des transactions.
Pour éviter de scanner des tables, vous devez exécuter des instructions contenant une clause de `WHERE` prédicat à l'aide d'un opérateur d'*égalité* (`=`ou`IN`) sur un champ indexé ou un identifiant de document. Pour de plus amples informations, veuillez consulter [Optimisation des performances des requêtes](working.optimize.md).
Tenez compte des contraintes suivantes lors de la création d'index :
+ Un index ne peut être créé que sur un seul champ de niveau supérieur. Les index composites, imbriqués, uniques et basés sur des fonctions ne sont pas pris en charge.
+ Vous pouvez créer un index sur tous les [types de données Ion](ql-reference.data-types.md), y compris `list` et`struct`. Cependant, vous ne pouvez effectuer la recherche indexée que par égalité de la valeur totale de l'ion, quel que soit le type d'ion. Par exemple, lorsque vous utilisez un `list` type comme index, vous ne pouvez pas effectuer de recherche indexée par un élément de la liste.
+ Les performances des requêtes ne sont améliorées que lorsque vous utilisez un prédicat d'égalité ; par exemple, `WHERE indexedField = 123` ou`WHERE indexedField IN (456, 789)`.
QLDB n'honore pas les inégalités dans les prédicats de requête. Par conséquent, les scans filtrés par plage ne sont pas implémentés.
+ Les noms des champs indexés distinguent les majuscules et minuscules et peuvent comporter un maximum de 128 caractères.
+ La création d'index dans QLDB est asynchrone. Le temps nécessaire pour terminer la création d'un index sur une table non vide varie en fonction de la taille de la table. Pour de plus amples informations, veuillez consulter [Gestion des index](#working.manage-indexes).
## Décrire les index
La création d'index dans QLDB est asynchrone. Le temps nécessaire pour terminer la création d'un index sur une table non vide varie en fonction de la taille de la table. Pour vérifier l'état d'une création d'index, vous pouvez interroger la table du catalogue système [information\$1schema.user\$1tables](working.catalog.md).
Par exemple, l'instruction suivante interroge le catalogue système pour tous les index de la `VehicleRegistration` table.
```
SELECT VALUE indexes
FROM information_schema.user_tables info, info.indexes indexes
WHERE info.name = 'VehicleRegistration'
```
```
{
indexId: "Djg2nt0yIs2GY0T29Kud1z",
expr: "[VIN]",
status: "ONLINE"
},
{
indexId: "4tPW3fUhaVhDinRgKRLhGU",
expr: "[LicensePlateNumber]",
status: "FAILED",
message: "aws.ledger.errors.InvalidEntityError: Document contains multiple values for indexed field: LicensePlateNumber"
}
```
**Champs d'index**
+ `indexId`— L'identifiant unique de l'index.
+ `expr`— Le chemin du document indexé. Ce champ est une chaîne au format :`[fieldName]`.
+ `status`— L'état actuel de l'indice. Le statut d'un index peut être l'une des valeurs suivantes :
+ `BUILDING`— Construit activement l'index de la table.
+ `FINALIZING`— A terminé la création de l'index et commence à l'activer pour l'utiliser.
+ `ONLINE`— Est actif et prêt à être utilisé dans les requêtes. QLDB n'utilise pas l'index dans les requêtes tant que le statut n'est pas en ligne.
+ `FAILED`— Impossible de créer l'index en raison d'une erreur irrécupérable. Les index dans cet état sont toujours pris en compte dans votre quota d'index par table. Pour de plus amples informations, veuillez consulter [Erreurs courantes](#working.manage-indexes.errors).
+ `DELETING`— Supprime activement l'index après qu'un utilisateur l'ait déposé.
+ `message`— Le message d'erreur qui décrit la raison pour laquelle l'index possède un `FAILED` statut. Ce champ n'est inclus que pour les index défaillants.
### Utilisation de la console
Vous pouvez également utiliser le AWS Management Console pour vérifier le statut d'un index.
**Pour vérifier l'état d'un index (console)**
1. [Connectez-vous à la AWS Management Console console Amazon QLDB et ouvrez-la à l'adresse /qldb. https://console.aws.amazon.com](https://console.aws.amazon.com/qldb)
1. Dans le volet de navigation, choisissez **Ledgers**.
1. Dans la liste des **registres**, choisissez le nom du registre dont vous souhaitez gérer les index.
1. Sur la page des détails du registre, sous l'onglet **Tables**, choisissez le nom de la table dont vous souhaitez vérifier l'index.
1. Sur la page des détails du tableau, recherchez la fiche **Champs indexés**. La colonne **État de l'index** affiche l'état actuel de chaque index de la table.
## Suppression d'index
Utilisez l'[DROP INDEX](ql-reference.drop-index.md)instruction pour supprimer un index. Lorsque vous supprimez un index, il est définitivement supprimé de la table.
Tout d'abord, trouvez l'identifiant de l'index à partir de`information_schema.user_tables`. Par exemple, la requête suivante renvoie le `LicensePlateNumber` champ indexé `indexId` de la `VehicleRegistration` table.
```
SELECT indexes.indexId
FROM information_schema.user_tables info, info.indexes indexes
WHERE info.name = 'VehicleRegistration' and indexes.expr = '[LicensePlateNumber]'
```
Utilisez ensuite cet identifiant pour supprimer l'index. Voici un exemple qui supprime l'ID d'index`4tPW3fUhaVhDinRgKRLhGU`. L'ID d'index est un identifiant unique qui doit être placé entre guillemets doubles.
```
DROP INDEX "4tPW3fUhaVhDinRgKRLhGU" ON VehicleRegistration WITH (purge = true)
```
**Note**
La clause `WITH (purge = true)` est obligatoire pour toutes les `DROP INDEX` instructions et `true` est actuellement la seule valeur prise en charge.
Le mot clé `purge` distingue les majuscules des minuscules et doit être entièrement en minuscules.
### Utilisation de la console
Vous pouvez également utiliser le AWS Management Console pour supprimer un index.
**Pour supprimer un index (console)**
1. [Connectez-vous à la AWS Management Console console Amazon QLDB et ouvrez-la à l'adresse /qldb. https://console.aws.amazon.com](https://console.aws.amazon.com/qldb)
1. Dans le volet de navigation, choisissez **Ledgers**.
1. Dans la liste des **registres**, choisissez le nom du registre dont vous souhaitez gérer les index.
1. Sur la page des détails du registre, sous l'onglet **Tables**, choisissez le nom de la table dont vous souhaitez supprimer l'index.
1. Sur la page des détails du tableau, recherchez la fiche **Champs indexés**. Sélectionnez l'index que vous souhaitez supprimer, puis choisissez Supprimer **l'index**.
## Erreurs courantes
Cette section décrit les erreurs courantes que vous pouvez rencontrer lors de la création d'index et suggère des solutions possibles.
**Note**
Les index dont le statut est `FAILED` toujours pris en compte dans votre quota d'index par table. Un index défaillant vous empêche également de modifier ou de supprimer les documents à l'origine de l'échec de la création de l'index sur la table.
Vous devez [supprimer](#working.manage-indexes.drop) explicitement l'index pour le supprimer du quota.
**Le document contient plusieurs valeurs pour le champ indexé :*fieldName*.**
QLDB n'est pas en mesure de créer un index pour le nom de champ spécifié car la table contient un document contenant plusieurs valeurs pour le même champ (c'est-à-dire des noms de champs dupliqués).
Vous devez d'abord supprimer l'index défaillant. Assurez-vous ensuite que tous les documents de la table n'ont qu'une seule valeur pour chaque nom de champ avant de réessayer de créer l'index. Vous pouvez également créer un index pour un autre champ dépourvu de doublons.
QLDB renvoie également cette erreur si vous essayez d'insérer un document contenant plusieurs valeurs pour un champ déjà indexé dans la table.
**Limite d'index dépassée : la table possède *tableName* déjà *n* des index et ne peut pas en créer d'autres.**
QLDB impose une limite de cinq index par table, y compris les index défaillants. Vous devez supprimer un index existant avant d'en créer un nouveau.
**Aucun index défini avec identifiant :*indexId*.**
Vous avez essayé de supprimer un index qui n'existe pas pour la combinaison table et ID d'index spécifiée. Pour savoir comment vérifier les index existants, consultez[Décrire les index](#working.manage-indexes.describe).
# Unique IDs dans Amazon QLDB
**Important**
Avis de fin de support : les clients existants pourront utiliser Amazon QLDB jusqu'à la fin du support le 31 juillet 2025. Pour plus de détails, consultez [Migrer un registre Amazon QLDB vers Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/migrate-an-amazon-qldb-ledger-to-amazon-aurora-postgresql/).
Cette section décrit les propriétés et les directives d'utilisation des identifiants uniques attribués par le système dans Amazon QLDB. Il fournit également quelques exemples de QLDB uniques. IDs
**Topics**
+ [
## Propriétés
](#working.unique-id.properties)
+ [
## Utilisation
](#working.unique-id.usage)
+ [
## Exemples
](#working.unique-id.examples)
## Propriétés
Tous les identifiants uniques universels ( IDs UUID) assignés au système dans QLDB sont des identifiants uniques universels. Chaque identifiant possède les propriétés suivantes :
+ Numéro UUID 128 bits
+ Représenté dans du texte codé en Base62
+ Chaîne alphanumérique de longueur fixe de 22 caractères (par exemple :`3Qv67yjXEwB9SjmvkuG6Cp`)
## Utilisation
Lorsque vous utilisez QLDB IDs unique dans votre application, respectez les consignes suivantes :
**Fais**
+ Traitez l'identifiant comme une chaîne.
**Ne**
+ Essayez de décoder la chaîne.
+ Attribuez une signification sémantique à la chaîne (comme la dérivation d'une composante temporelle).
+ Triez les chaînes dans un ordre sémantique.
## Exemples
Les attributs suivants sont des exemples d'attributs uniques IDs dans QLDB :
+ Identifiant du document
+ Identifiant de l'indice
+ ID de la plage
+ ID de table
+ Identifiant de transaction