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. # OpenSearch Indexation sans chaîne dans Amazon Neptune L' OpenSearch indexation sans chaîne dans Amazon Neptune permet de répliquer des valeurs autres que des chaînes pour les OpenSearch prédicats à l'aide du stream poller. Toutes les valeurs de prédicat qui peuvent être converties en toute sécurité en un OpenSearch mappage ou un type de données correspondant sont ensuite répliquées dans. OpenSearch Pour que l'indexation sans chaîne soit activée sur une nouvelle pile, l'`Enable Non-String Indexing`indicateur du CloudFormation modèle doit être défini sur. `true` Il s’agit du paramètre par défaut. Pour mettre à jour une pile existante afin de prendre en charge l'indexation hors chaîne, consultez [Mise à jour d'une pile existante](full-text-search-non-string-indexing-update.md) ci-dessous. **Note** Il est préférable de ne pas activer l'indexation hors chaîne sur les versions du moteur antérieures à **`1.0.4.2`**. OpenSearch les requêtes utilisant des expressions régulières pour les noms de champs correspondant à plusieurs champs, dont certains contiennent des valeurs de chaîne et d'autres des valeurs autres que des chaînes, échouent avec une erreur. Il en va de même si les requêtes de recherche en texte intégral dans Neptune sont de ce type. Lorsque vous effectuez un tri selon un champ autre qu'une chaîne, ajoutez « .value » au nom de ce champ pour le différencier d'un champ de chaîne. **Contents** + [Mise à jour d'une pile de recherche en texte intégral Neptune pour prendre en charge l'indexation hors chaîne](full-text-search-non-string-indexing-update.md) + [Filtrage des champs indexés dans la recherche en texte intégral Neptune](full-text-search-non-string-indexing-filters.md) + [Filtrage par nom de propriété ou de prédicat](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-name) + [Filtrage par type de propriété ou de valeur de prédicat](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-datatype) + [Mappage des types de données SPARQL et Gremlin vers OpenSearch](full-text-search-non-string-indexing-mapping.md) + [Validation des mappages de données](full-text-search-data-validation.md) + [Exemples de OpenSearch requêtes autres que des chaînes dans Neptune](full-text-search-non-string-examples.md) + [Obtenir tous les sommets de plus de 30 ans et dont le nom commence par « Si »](full-text-search-non-string-examples.md#full-text-search-non-string-example-1) + [Obtenir tous les nœuds âgés de 10 à 50 ans et dont le nom a une correspondance floue avec « Ronka »](full-text-search-non-string-examples.md#full-text-search-non-string-example-2) + [Obtenir tous les nœuds dont l'horodatage remonte aux 25 derniers jours](full-text-search-non-string-examples.md#full-text-search-non-string-example-3) + [Obtenir tous les nœuds dont l'horodatage correspond à une année ou à un mois donnés](full-text-search-non-string-examples.md#full-text-search-non-string-example-4) # Mise à jour d'une pile de recherche en texte intégral Neptune pour prendre en charge l'indexation hors chaîne Si vous utilisez déjà la recherche en texte intégral dans Neptune, voici les étapes à suivre pour prendre en charge l'indexation hors chaînes : 1. **Arrêtez la fonction Lambda d'interrogateur de flux.** Cette étape garantit qu'aucune nouvelle mise à jour n'est copiée lors de l'exportation. Pour ce faire, désactivez la règle d'événement cloud qui invoque cette fonction Lambda : + Dans le AWS Management Console, naviguez vers CloudWatch. + Sélectionnez **Règles**. + Choisissez la règle correspondant au nom de l'interrogateur de flux Lambda. + Sélectionnez **Désactiver** pour désactiver temporairement cette règle. 1. **Supprimez l'indice Neptune actuel dans. OpenSearch** Utilisez la `curl` requête suivante pour supprimer l'`amazon_neptune`index de votre OpenSearch cluster : ``` curl -X DELETE "your OpenSearch endpoint/amazon_neptune" ``` 1. **Lancez une exportation unique de Neptune vers. OpenSearch** Il est préférable de configurer une nouvelle OpenSearch pile à ce stade, afin que les nouveaux artefacts soient collectés pour le sondeur qui effectue l'exportation. Suivez les étapes [répertoriées ici GitHub]( https://github.com/awslabs/amazon-neptune-tools/blob/master/export-neptune-to-elasticsearch/readme.md) pour démarrer l'exportation unique de vos données Neptune vers. OpenSearch 1. **Mettez à jour les artefacts Lambda pour l'interrogateur de flux existant.** Une fois que l'exportation des données Neptune vers OpenSearch est terminée avec succès, procédez comme suit : + Dans le AWS Management Console, naviguez vers CloudFormation. + Choisissez la CloudFormation pile parent principale. + Sélectionnez l'option **Mettre à jour** pour cette pile. + Sélectionnez **Remplacer le modèle actuel à partir des options**. + Pour la source du modèle, sélectionnez **URL Amazon S3**. + Pour l'URL Amazon S3, entrez : ``` https://aws-neptune-customer-samples.s3.amazonaws.com/neptune-stream/neptune_to_elastic_search.json ``` + Choisissez **Next** sans modifier aucun des CloudFormation paramètres. + Sélectionnez **Mettre à jour la pile**. CloudFormation remplacera les artefacts du code Lambda pour le stream poller par les derniers artefacts. 1. **Redémarrez l'interrogateur de flux.** Pour ce faire, activez la CloudWatch règle appropriée : + Dans le AWS Management Console, naviguez vers CloudWatch. + Sélectionnez **Règles**. + Choisissez la règle correspondant au nom de l'interrogateur de flux Lambda. + Sélectionnez **activer**. # Filtrage des champs indexés dans la recherche en texte intégral Neptune Les détails du CloudFormation modèle comportent deux champs qui vous permettent de spécifier des clés de propriété ou de prédicat ou des types de données à exclure de l'indexation : OpenSearch ## Filtrage par nom de propriété ou de prédicat Vous pouvez utiliser le paramètre de CloudFormation modèle facultatif nommé `Properties to exclude from being inserted into Elastic Search Index` pour fournir une liste séparée par des virgules de clés de propriété ou de prédicat à exclure de l'indexation. OpenSearch Par exemple, supposons que vous définissiez ce paramètre sur `bob` : ``` "Properties to exclude from being inserted into Elastic Search Index" : bob ``` Dans ce cas, l'enregistrement de flux de la requête de mise à jour Gremlin suivante serait supprimé au lieu d'être intégré dans l'index : ``` g.V("1").property("bob", "test") ``` De même, vous pouvez définir le paramètre sur `http://my/example#bob` : ``` "Properties to exclude from being inserted into Elastic Search Index" : http://my/example#bob ``` Dans ce cas, l'enregistrement de flux de la requête de mise à jour SPARQL suivante serait supprimé au lieu d'être intégré dans l'index : ``` PREFIX ex: INSERT DATA { ex:s1 ex:bob "test"}. ``` Si vous n'entrez rien dans ce paramètre de CloudFormation modèle, toutes les clés de propriété non exclues seront indexées. ## Filtrage par type de propriété ou de valeur de prédicat Vous pouvez utiliser le paramètre de CloudFormation modèle facultatif nommé `Datatypes to exclude from being inserted into Elastic Search Index` pour fournir une liste séparée par des virgules de types de données de propriétés ou de valeurs de prédicat à exclure de l'indexation. OpenSearch Pour SPARQL, il n'est pas nécessaire de répertorier l'URI complet du type XSD. Vous pouvez simplement répertorier le jeton du type de données. Voici les jetons de type de données valides que vous pouvez répertorier : + `string` + `boolean` + `float` + `double` + `dateTime` + `date` + `time` + `byte` + `short` + `int` + `long` + `decimal` + `integer` + `nonNegativeInteger` + `nonPositiveInteger` + `negativeInteger` + `unsignedByte` + `unsignedShort` + `unsignedInt` + `unsignedLong` Pour Gremlin, voici les types de données valides que vous pouvez répertorier : + `string` + `date` + `bool` + `byte` + `short` + `int` + `long` + `float` + `double` Par exemple, supposons que vous définissiez ce paramètre sur `string` : ``` "Datatypes to exclude from being inserted into Elastic Search Index" : string ``` Dans ce cas, l'enregistrement de flux de la requête de mise à jour Gremlin suivante serait supprimé au lieu d'être intégré dans l'index : ``` g.V("1").property("myStringval", "testvalue") ``` De même, vous pouvez définir le paramètre sur `int` : ``` "Datatypes to exclude from being inserted into Elastic Search Index" : int ``` Dans ce cas, l'enregistrement de flux de la requête de mise à jour SPARQL suivante serait supprimé au lieu d'être intégré dans l'index : ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:s1 ex:bob "11"^^xsd:int }. ``` Si vous n'entrez rien dans ce paramètre de CloudFormation modèle, toutes les propriétés dont les valeurs peuvent être converties en toute sécurité en OpenSearch équivalents seront indexées. Les types répertoriés qui ne sont pas pris en charge par le langage de requête seront ignorés. # Mappage des types de données SPARQL et Gremlin vers OpenSearch Les nouveaux mappages de types de données OpenSearch sont créés en fonction du type de données utilisé dans la propriété ou l'objet. Commen certains champs comprennent des valeurs de différents types, le mappage initial peut exclure certaines valeurs du champ. Les types de données Neptune correspondent aux OpenSearch types de données comme suit : | Types SPARQL | Types Gremlin | OpenSearch types | | --- | --- | --- | | `XSD:int` `XSD:unsignedInt` `XSD:integer` `XSD:byte` `XSD:unsignedByte` `XSD:short` `XSD:unsignedShort` `XSD:long` `XSD:unsignedLong` | `byte` `short` `int` `long` | `long` | | `XSD:float` `XSD:double` `XSD:decimal` | `float` `double` | `double` | | `XSD:boolean` | `bool` | `boolean` | | `XSD:datetime` `XSD:date` | `date` | `date` | | `XSD:string` `XSD:time` | `string` | `text` | | *Type de données personnalisé* | *S/O* | `text` | | *Tout autre type de données* | *S/O* | `text` | Par exemple, la requête de mise à jour Gremlin suivante entraîne l'ajout d'un nouveau mappage pour « NewField » OpenSearch, à savoir : `{ "type" : "double" }` ``` g.V("1").property("newField" 10.5) ``` De même, la requête de mise à jour SPARQL suivante entraîne l'ajout d'un nouveau mappage pour « ex:byte », à OpenSearch savoir : `{ "type" : "long" }` ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:test ex:byte "123"^^xsd:byte }. ``` **Note** Comme vous pouvez le constater, un élément mappé depuis Neptune OpenSearch vers peut se retrouver avec un type de données différent de celui qu'il possède OpenSearch dans Neptune. Cependant, il existe un champ de texte explicite dans OpenSearch « datatype » qui enregistre le type de données que possède l'élément dans Neptune. # Validation des mappages de données Les données sont répliquées OpenSearch depuis Neptune selon le processus suivant : + Si un mappage pour le champ en question est déjà présent dans OpenSearch : + Si les données peuvent être converties en toute sécurité dans le mappage existant à l'aide des règles de validation des données, stockez le champ dans OpenSearch. + Si ce n'est pas le cas, abandonnez l'enregistrement de mise à jour du flux correspondant. + S'il n'existe aucun mappage pour le champ en question, recherchez un type de OpenSearch données correspondant au type de données du champ dans Neptune. + Si les données de champ peuvent être converties en toute sécurité au OpenSearch type de données à l'aide des règles de validation des données, stockez le nouveau mappage et les nouvelles données de champ dans. OpenSearch + Si ce n'est pas le cas, abandonnez l'enregistrement de mise à jour du flux correspondant. Les valeurs sont validées par rapport à des OpenSearch types équivalents ou à OpenSearch des mappages existants plutôt qu'aux types Neptune. Par exemple, la validation de la valeur `"123"` dans `"123"^^xsd:int` est effectuée par rapport au type `long` plutôt qu'au type `int`. Bien que Neptune essaie de répliquer toutes les données, dans certains cas OpenSearch, les types de données OpenSearch sont totalement différents de ceux de Neptune, et dans de tels cas, les enregistrements sont ignorés au lieu d'être indexés. OpenSearch Par exemple, dans Neptune, une propriété peut avoir plusieurs valeurs de types différents, alors que dans OpenSearch un champ, elle doit avoir le même type sur l'ensemble de l'index. En activant les journaux de débogage, vous pouvez voir quels enregistrements ont été supprimés lors de l'exportation de OpenSearch Neptune vers. Voici un exemple d'entrée du journal de débogage : ``` Dropping Record : Data type not a valid Gremlin type ``` Les types de données sont validés comme suit : + **`text`**— Toutes les valeurs de Neptune peuvent être mappées en toute sécurité au texte saisi. OpenSearch + **`long`**— Les règles suivantes pour les types de données Neptune s'appliquent lorsque le type de OpenSearch mappage est long (dans les exemples ci-dessous, on suppose qu'il `"testLong"` possède un `long` type de mappage) : + `boolean` : non valide, ne peut pas être converti, et l'enregistrement de mise à jour du flux correspondant est supprimé. Les exemples de G705 non valides sont les suivants : ``` "testLong" : true. "testLong" : false. ``` Voici des exemples de SPARQL non valides : ``` ":testLong" : "true"^^xsd:boolean ":testLong" : "false"^^xsd:boolean ``` + `datetime` : non valide, ne peut pas être converti, et l'enregistrement de mise à jour du flux correspondant est supprimé. Voici un exemple de G705 non valide : ``` ":testLong" : datetime('2018-11-04T00:00:00'). ``` Voici un exemple de SPARQL non valide : ``` ":testLong" : "2016-01-01"^^xsd:date ``` + `float``double`, ou `decimal` — Si la valeur dans Neptune est un entier pouvant contenir 64 bits, elle est valide et stockée sous forme longue, mais si elle comporte une partie fractionnaire, est a ou an, ou est supérieure à 9 223 372 036 854 775 807 ou inférieure à -9,223 372 036 854 775 808`INF`, elle n'est pas valide et l'enregistrement de mise à jour du flux correspondant est supprimé. OpenSearch `NaN` Les exemples valides de G705 sont les suivants : ``` "testLong" : 145.0. ":testLong" : 123 ":testLong" : -9223372036854775807 ``` Voici des exemples de SPARQL valides : ``` ":testLong" : "145.0"^^xsd:float ":testLong" : 145.0 ":testLong" : "145.0"^^xsd:double ":testLong" : "145.0"^^xsd:decimal ":testLong" : "-9223372036854775807" ``` Les exemples de G705 non valides sont les suivants : ``` "testLong" : 123.45 ":testLong" : 9223372036854775900 ``` Voici des exemples de SPARQL non valides : ``` ":testLong" : 123.45 ":testLong" : 9223372036854775900 ":testLong" : "123.45"^^xsd:float ":testLong" : "123.45"^^xsd:double ":testLong" : "123.45"^^xsd:decimal ``` + `string`— Si la valeur dans Neptune est une représentation sous forme de chaîne d'un entier pouvant être contenu dans un entier de 64 bits, elle est valide et est convertie en entrée. `long` OpenSearch Toute autre valeur de chaîne n'est pas valide pour un `long` mappage Elasticseearch, et l'enregistrement de mise à jour du flux correspondant est supprimé. Les exemples valides de G705 sont les suivants : ``` "testLong" : "123". ":testLong" : "145.0" ":testLong" : "-9223372036854775807" ``` Voici des exemples de SPARQL valides : ``` ":testLong" : "145.0"^^xsd:string ":testLong" : "-9223372036854775807"^^xsd:string ``` Les exemples de G705 non valides sont les suivants : ``` "testLong" : "123.45" ":testLong" : "9223372036854775900" ":testLong" : "abc" ``` Voici des exemples de SPARQL non valides : ``` ":testLong" : "123.45"^^xsd:string ":testLong" : "abc" ":testLong" : "9223372036854775900"^^xsd:string ``` + **`double`**— Si le type de OpenSearch mappage est le cas`double`, les règles suivantes s'appliquent (ici, le champ « TestDouble » est supposé contenir un `double` mappage OpenSearch) : + `boolean` : non valide, ne peut pas être converti, et l'enregistrement de mise à jour du flux correspondant est supprimé. Les exemples de G705 non valides sont les suivants : ``` "testDouble" : true. "testDouble" : false. ``` Voici des exemples de SPARQL non valides : ``` ":testDouble" : "true"^^xsd:boolean ":testDouble" : "false"^^xsd:boolean ``` + `datetime` : non valide, ne peut pas être converti, et l'enregistrement de mise à jour du flux correspondant est supprimé. Voici un exemple de G705 non valide : ``` ":testDouble" : datetime('2018-11-04T00:00:00'). ``` Voici un exemple de SPARQL non valide : ``` ":testDouble" : "2016-01-01"^^xsd:date ``` + Virgule flottante `NaN` ou `INF` — Si la valeur dans SPARQL est une valeur à virgule flottante `NaN` ou`INF`, elle n'est pas valide et l'enregistrement de mise à jour du flux correspondant est supprimé. Voici des exemples de SPARQL non valides : ``` " :testDouble" : "NaN"^^xsd:float ":testDouble" : "NaN"^^double ":testDouble" : "INF"^^double ":testDouble" : "-INF"^^double ``` + nombre ou chaîne numérique — Si la valeur dans Neptune est une autre représentation numérique ou sous forme de chaîne numérique d'un nombre qui peut être exprimé en toute sécurité sous la forme d'`double`un a, alors elle est valide et est convertie en entrée. `double` OpenSearch Toute autre valeur de chaîne n'est pas valide pour un OpenSearch `double` mappage et l'enregistrement de mise à jour du flux correspondant est supprimé. Les exemples valides de G705 sont les suivants : ``` "testDouble" : 123 ":testDouble" : "123" ":testDouble" : 145.67 ":testDouble" : "145.67" ``` Voici des exemples de SPARQL valides : ``` ":testDouble" : 123.45 ":testDouble" : 145.0 ":testDouble" : "123.45"^^xsd:float ":testDouble" : "123.45"^^xsd:double ":testDouble" : "123.45"^^xsd:decimal ":testDouble" : "123.45"^^xsd:string ``` Voici un exemple de G705 non valide : ``` ":testDouble" : "abc" ``` Voici un exemple de SPARQL non valide : ``` ":testDouble" : "abc" ``` + **`date`**— Si le type de OpenSearch mappage est`date`, Neptune `date` et sa `dateTime` valeur sont valides, de même que toute valeur de chaîne pouvant être analysée avec succès selon un format. `dateTime` Les exemples valides dans G705 ou SPARQL sont les suivants : ``` Date(2016-01-01) "2016-01-01" " 2003-09-25T10:49:41" "2003-09-25T10:49" "2003-09-25T10" "20030925T104941-0300" "20030925T104941" "2003-Sep-25" " Sep-25-2003" "2003.Sep.25" "2003/09/25" "2003 Sep 25" " Wed, July 10, '96" "Tuesday, April 12, 1952 AD 3:30:42pm PST" "123" "-123" "0" "-0" "123.00" "-123.00" ``` Les exemples suivants ne sont pas valides : ``` 123.45 True "abc" ``` # Exemples de OpenSearch requêtes autres que des chaînes dans Neptune Neptune ne prend actuellement pas directement en charge les requêtes OpenSearch de plage. Cependant, vous pouvez obtenir le même effet en utilisant la syntaxe Lucene et query-type="query\$1string", comme vous pouvez le voir dans les exemples de requêtes suivants. ## Obtenir tous les sommets de plus de 30 ans et dont le nom commence par « Si » Dans Gremlin : ``` g.withSideEffect('Neptune#fts.endpoint', 'http://your-es-endpoint') .withSideEffect("Neptune#fts.queryType", "query_string") .V().has('*', 'Neptune#fts predicates.age.value:>30 && predicates.name.value:Si*'); ``` En SPARQL : ``` PREFIX foaf: PREFIX neptune-fts: SELECT * WHERE { SERVICE neptune-fts:search { neptune-fts:config neptune-fts:endpoint 'http://localhost:9200' . neptune-fts:config neptune-fts:queryType 'query_string' . neptune-fts:config neptune-fts:query "predicates.\\*foaf\\*age.value:>30 AND predicates.\\*foaf\\*name.value:Si*" . neptune-fts:config neptune-fts:field '*' . neptune-fts:config neptune-fts:return ?res . } } ``` Dans ce cas, `"\\*foaf\\*age` est utilisé à la place de l'URI complet par souci de concision. Cette expression régulière récupère tous les champs contenant `foaf` et `age` dans l'URI. ## Obtenir tous les nœuds âgés de 10 à 50 ans et dont le nom a une correspondance floue avec « Ronka » Dans Gremlin : ``` g.withSideEffect('Neptune#fts.endpoint', 'http://your-es-endpoint') .withSideEffect("Neptune#fts.queryType", "query_string") .V().has('*', 'Neptune#fts predicates.age.value:[10 TO 50] AND predicates.name.value:Ronka~'); ``` En SPARQL : ``` PREFIX foaf: PREFIX neptune-fts: SELECT * WHERE { SERVICE neptune-fts:search { neptune-fts:config neptune-fts:endpoint 'http://localhost:9200' . neptune-fts:config neptune-fts:queryType 'query_string' . neptune-fts:config neptune-fts:query "predicates.\\*foaf\\*age.value:[10 TO 50] AND predicates.\\*foaf\\*name.value:Ronka~" . neptune-fts:config neptune-fts:field '*' . neptune-fts:config neptune-fts:return ?res . } } ``` ## Obtenir tous les nœuds dont l'horodatage remonte aux 25 derniers jours Dans Gremlin : ``` g.withSideEffect('Neptune#fts.endpoint', 'http://your-es-endpoint') .withSideEffect("Neptune#fts.queryType", "query_string") .V().has('*', 'Neptune#fts predicates.timestamp.value:>now-25d'); ``` En SPARQL : ``` PREFIX foaf: PREFIX neptune-fts: SELECT * WHERE { SELECT * WHERE { SERVICE neptune-fts:search { neptune-fts:config neptune-fts:endpoint 'http://localhost:9200' . neptune-fts:config neptune-fts:queryType 'query_string' . neptune-fts:config neptune-fts:query "predicates.\\*foaf\\*timestamp.value:>now-25d~" . neptune-fts:config neptune-fts:field '*' . neptune-fts:config neptune-fts:return ?res . } } ``` ## Obtenir tous les nœuds dont l'horodatage correspond à une année ou à un mois donnés Dans Gremlin, avec des [expressions mathématiques de date](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/common-options.html#date-math) dans la syntaxe de Lucene, pour décembre 2020 : ``` g.withSideEffect('Neptune#fts.endpoint', 'http://your-es-endpoint') .withSideEffect("Neptune#fts.queryType", "query_string") .V().has('*', 'Neptune#fts predicates.timestamp.value:>2020-12'); ``` Alternative Gremlin : ``` g.withSideEffect('Neptune#fts.endpoint', 'http://your-es-endpoint') .withSideEffect("Neptune#fts.queryType", "query_string") .V().has('*', 'Neptune#fts predicates.timestamp.value:[2020-12 TO 2021-01]'); ```