Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Indexación de OpenSearch sin cadenas en Amazon Neptune La indexación de OpenSearch sin cadenas en Amazon Neptune permite replicar en OpenSearch valores que no son cadenas para predicados mediante el sondeador de flujos. Todos los valores de predicados que se puedan convertir de forma segura en un mapeo o tipo de datos de OpenSearch correspondiente se replican en OpenSearch. Para habilitar la indexación sin cadenas en una pila nueva, el indicador `Enable Non-String Indexing` de la plantilla CloudFormation debe estar establecido en `true`. Este es el valor predeterminado. Para actualizar una pila existente para que sea compatible con la indexación sin cadenas, consulte [Actualización de una pila existente](full-text-search-non-string-indexing-update.md) a continuación. **nota** Es mejor no habilitar la indexación sin cadenas en las versiones del motor anteriores a **`1.0.4.2`**. Las consultas de OpenSearch que utilizan expresiones regulares para nombres de campo que coinciden con varios campos, algunos de los cuales contienen valores de cadena y otros contienen valores que sin cadenas, fallan y se produce un error. Lo mismo ocurre si las consultas de búsqueda de texto completo en Neptune son de ese tipo. Al ordenar por un campo sin cadenas, añada ".value" al nombre del campo para diferenciarlo de un campo de cadena. **Contents** + [Actualización de una pila de búsqueda de texto completo de Neptune existente para admitir la indexación sin cadenas](full-text-search-non-string-indexing-update.md) + [Filtrado de los campos que se indexan en la búsqueda de texto completo de Neptune](full-text-search-non-string-indexing-filters.md) + [Filtre por propiedad o nombre de predicado](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-name) + [Filtre por propiedad o tipo de valor de predicado](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-datatype) + [Mapeo de tipos de datos SPARQL y Gremlin a OpenSearch](full-text-search-non-string-indexing-mapping.md) + [Validación de mapeos de datos](full-text-search-data-validation.md) + [Ejemplos de consultas de OpenSearch sin cadenas en Neptune](full-text-search-non-string-examples.md) + [Obtenga todos los vértices con una antigüedad superior a 30 años y un nombre que comience por "Si"](full-text-search-non-string-examples.md#full-text-search-non-string-example-1) + [Obtenga todos los nodos con una antigüedad comprendida entre 10 y 50 años y un nombre con una coincidencia parcial con "Ronka"](full-text-search-non-string-examples.md#full-text-search-non-string-example-2) + [Obtenga todos los nodos con una marca temporal que esté comprendida dentro de los últimos 25 días](full-text-search-non-string-examples.md#full-text-search-non-string-example-3) + [Obtenga todos los nodos con una marca temporal que esté dentro de un año y un mes determinados](full-text-search-non-string-examples.md#full-text-search-non-string-example-4) # Actualización de una pila de búsqueda de texto completo de Neptune existente para admitir la indexación sin cadenas Si ya utiliza la búsqueda de texto completo en Neptune, estos son los pasos que debe seguir para admitir la indexación sin cadenas: 1. **Detenga la función de Lambda del sondeador de flujo.** Esto garantiza que no se copien nuevas actualizaciones durante la exportación. Para ello, deshabilite la regla de eventos de nube que invoca la función de Lambda: + En la Consola de administración de AWS, vaya a CloudWatch. + Seleccione **Reglas**. + Elija la regla con el nombre del sondeador de flujo de Lambda. + Seleccione **Deshabilitar** para deshabilitar temporalmente la regla. 1. **Elimine el índice de Neptune actual en OpenSearch.** Utilice la siguiente consulta `curl` para eliminar el índice `amazon_neptune` del clúster de OpenSearch: ``` curl -X DELETE "your OpenSearch endpoint/amazon_neptune" ``` 1. **Inicie una exportación puntual de Neptune a OpenSearch.** Lo mejor es configurar una nueva pila de OpenSearch en este momento, de forma que el buscador que realice la exportación pueda obtener los nuevos artefactos. Siga los pasos que se indican [aquí en GitHub]( https://github.com/awslabs/amazon-neptune-tools/blob/master/export-neptune-to-elasticsearch/readme.md) para iniciar la exportación puntual de sus datos de Neptune a OpenSearch. 1. **Actualice los artefactos de Lambda para el sondeador de flujos existente.** Una vez que la exportación de los datos de Neptune a OpenSearch se haya realizado correctamente, siga estos pasos: + En la Consola de administración de AWS, vaya a CloudFormation. + Elija la pila CloudFormation principal. + Seleccione la opción **Actualizar** para esa pila. + Seleccione **Reemplazar la plantilla actual desde opciones**. + En el origen de la plantilla, seleccione **URL de Amazon S3**. + Para la URL de Amazon S3, introduzca: ``` https://aws-neptune-customer-samples.s3.amazonaws.com/neptune-stream/neptune_to_elastic_search.json ``` + Seleccione **Siguiente** sin cambiar ningún parámetro de CloudFormation. + Seleccione **Actualizar pila**. CloudFormation sustituirá a los artefactos del código de Lambda del sondeador de flujos por los artefactos más recientes. 1. **Vuelva a iniciar el sondeador de flujo.** Para ello, habilite la regla de CloudWatch adecuada: + En la Consola de administración de AWS, vaya a CloudWatch. + Seleccione **Reglas**. + Elija la regla con el nombre del sondeador de flujo de Lambda. + Seleccione **Habilitar**. # Filtrado de los campos que se indexan en la búsqueda de texto completo de Neptune Hay dos campos en los detalles de la plantilla de CloudFormation que permiten especificar las claves de propiedades o predicados o los tipos de datos que se van a excluir de la indexación de OpenSearch: ## Filtre por propiedad o nombre de predicado Puede usar el parámetro de plantilla de CloudFormation opcional denominado `Properties to exclude from being inserted into Elastic Search Index` para proporcionar una lista delimitada por comas de claves de predicados o propiedades que desee excluir de la indexación de OpenSearch. Por ejemplo, supongamos que establece este parámetro en `bob`. ``` "Properties to exclude from being inserted into Elastic Search Index" : bob ``` En ese caso, el registro de flujo de la siguiente consulta de actualización de Gremlin se eliminaría en lugar de pasar al índice: ``` g.V("1").property("bob", "test") ``` Del mismo modo, puede establecer el parámetro en `http://my/example#bob`: ``` "Properties to exclude from being inserted into Elastic Search Index" : http://my/example#bob ``` En ese caso, el registro de flujo de la siguiente consulta de actualización de SPARQL se eliminaría en lugar de pasar al índice: ``` PREFIX ex: INSERT DATA { ex:s1 ex:bob "test"}. ``` Si no introduce nada en este parámetro de plantilla de CloudFormation, se indexarán todas las claves de propiedad que no se excluyan de algún modo. ## Filtre por propiedad o tipo de valor de predicado Puede usar el parámetro de plantilla de CloudFormation opcional denominado `Datatypes to exclude from being inserted into Elastic Search Index` para proporcionar una lista delimitada por comas de tipos de datos de valores de predicados o propiedades que desee excluir de la indexación de OpenSearch. En el caso de SPARQL, no es necesario incluir el URI de tipo XSD completo, sino simplemente el token del tipo de datos. Los tokens de tipos de datos válidos que puede enumerar son: + `string` + `boolean` + `float` + `double` + `dateTime` + `date` + `time` + `byte` + `short` + `int` + `long` + `decimal` + `integer` + `nonNegativeInteger` + `nonPositiveInteger` + `negativeInteger` + `unsignedByte` + `unsignedShort` + `unsignedInt` + `unsignedLong` En el caso de Gremlin, los tipos de datos válidos que se pueden enumerar son: + `string` + `date` + `bool` + `byte` + `short` + `int` + `long` + `float` + `double` Por ejemplo, supongamos que establece este parámetro en `string`. ``` "Datatypes to exclude from being inserted into Elastic Search Index" : string ``` En ese caso, el registro de flujo de la siguiente consulta de actualización de Gremlin se eliminaría en lugar de pasar al índice: ``` g.V("1").property("myStringval", "testvalue") ``` Del mismo modo, puede establecer el parámetro en `int`: ``` "Datatypes to exclude from being inserted into Elastic Search Index" : int ``` En ese caso, el registro de flujo de la siguiente consulta de actualización de SPARQL se eliminaría en lugar de pasar al índice: ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:s1 ex:bob "11"^^xsd:int }. ``` Si no introduce nada en este parámetro de plantilla de CloudFormation, se indexarán todas las propiedades cuyos valores se puedan convertir de forma segura en equivalentes de OpenSearch. Se omiten los tipos enumerados que no son compatibles con el lenguaje de consulta. # Mapeo de tipos de datos SPARQL y Gremlin a OpenSearch Los nuevos mapeos de tipos de datos en OpenSearch se crean en función del tipo de datos que se utiliza en la propiedad u objeto. Dado que algunos campos contienen valores de distintos tipos, es posible que en el mapeo inicial se excluyan algunos valores del campo. Los tipos de datos de Neptune se mapean a los tipos de datos de OpenSearch de la siguiente manera: | Tipos de SPARQL | Tipos de Gremlin | Tipos de OpenSearch | | --- | --- | --- | | `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` | | *Tipo de datos personalizado* | *N/A* | `text` | | *Cualquier otro tipo de datos* | *N/A* | `text` | Por ejemplo, la siguiente consulta de actualización de Gremlin hace que se añada un nuevo mapeo de "newField" a OpenSearch, es decir, `{ "type" : "double" }`: ``` g.V("1").property("newField" 10.5) ``` Del mismo modo, la siguiente consulta de actualización de SPARQL hace que se añada un nuevo mapeo de "ex:byte" a OpenSearch, es decir, `{ "type" : "long" }`: ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:test ex:byte "123"^^xsd:byte }. ``` **nota** Como puede ver, un elemento mapeado de Neptune a OpenSearch puede terminar con un tipo de datos diferente en OpenSearch al que tiene en Neptune. Sin embargo, hay un campo de texto explícito en OpenSearch, "datatype", que registra el tipo de datos que tiene el elemento en Neptune. # Validación de mapeos de datos Los datos se replican a OpenSearch desde Neptune mediante este proceso: + Si ya hay un mapeo del campo en cuestión en OpenSearch: + Si los datos se pueden convertir de forma segura al mapeo existente mediante reglas de validación de datos, guarde el campo en OpenSearch. + Si no es así, borre el registro de actualización del flujo correspondiente. + Si no existe ningún mapeo para el campo en cuestión, busque un tipo de datos de OpenSearch que corresponda al tipo de dato del campo en Neptune. + Si los datos del campo se pueden convertir de forma segura al tipo de dato de OpenSearch mediante reglas de validación de datos, almacene los nuevos datos de mapeo y campo en OpenSearch. + Si no es así, borre el registro de actualización del flujo correspondiente. Los valores se validan con los tipos de OpenSearch equivalentes o mapeos de OpenSearch existentes en lugar de con los tipos de Neptune. Por ejemplo, la validación del valor `"123"` en `"123"^^xsd:int` se realiza en función del tipo `long` y no del tipo `int`. Aunque Neptune intenta replicar todos los datos en OpenSearch, hay casos en los que los tipos de datos de OpenSearch son totalmente diferentes de los de Neptune y, en esos casos, los registros se omiten en lugar de indexarse en OpenSearch. Por ejemplo, en Neptune, una propiedad puede tener varios valores de distintos tipos, mientras que en OpenSearch un campo debe tener el mismo tipo en todo el índice. Al habilitar los registros de depuración, puede ver qué registros se han eliminado durante la exportación de Neptune a OpenSearch. Este es un ejemplo de entrada en el registro de depuración: ``` Dropping Record : Data type not a valid Gremlin type ``` Los tipos de datos se validan de la siguiente manera: + **`text`**: todos los valores de Neptune se pueden mapear de forma segura a texto en OpenSearch. + **`long`**: las siguientes reglas para los tipos de datos de Neptune se aplican cuando el tipo de mapeo de OpenSearch es largo (en los ejemplos siguientes, se supone que `"testLong"` tiene un tipo de mapeo `long`): + `boolean`: no es válido, no se puede convertir y se elimina el registro de actualización del flujo correspondiente. Estos son algunos ejemplos de Gremlin no válidos: ``` "testLong" : true. "testLong" : false. ``` Estos son algunos ejemplos de SPARQL no válidos: ``` ":testLong" : "true"^^xsd:boolean ":testLong" : "false"^^xsd:boolean ``` + `datetime`: no es válido, no se puede convertir y se elimina el registro de actualización del flujo correspondiente. Este es un ejemplo de un valor de Gremlin no válido: ``` ":testLong" : datetime('2018-11-04T00:00:00'). ``` Este es un ejemplo de un valor de SPARQL no válido: ``` ":testLong" : "2016-01-01"^^xsd:date ``` + `float`,`double` o `decimal`: si el valor de Neptune es un número entero que puede caber en 64 bits, es válido y se almacena en OpenSearch como long, pero si tiene una parte de fracción, es un `NaN` o un `INF`, o es mayor que 9.223.372.036.854.775.807 o menor que -9.223.372.036.854.775.808, entonces no es válido y se elimina el registro de actualización de flujo correspondiente. Estos son algunos ejemplos de valores de Gremlin válidos: ``` "testLong" : 145.0. ":testLong" : 123 ":testLong" : -9223372036854775807 ``` Estos son algunos ejemplos de SPARQL válidos: ``` ":testLong" : "145.0"^^xsd:float ":testLong" : 145.0 ":testLong" : "145.0"^^xsd:double ":testLong" : "145.0"^^xsd:decimal ":testLong" : "-9223372036854775807" ``` Estos son algunos ejemplos de Gremlin no válidos: ``` "testLong" : 123.45 ":testLong" : 9223372036854775900 ``` Estos son algunos ejemplos de SPARQL no válidos: ``` ":testLong" : 123.45 ":testLong" : 9223372036854775900 ":testLong" : "123.45"^^xsd:float ":testLong" : "123.45"^^xsd:double ":testLong" : "123.45"^^xsd:decimal ``` + `string`: si el valor de Neptune es una representación en cadena de un entero que puede estar contenido en un entero de 64 bits, entonces es válido y se convierte en `long` en OpenSearch. Cualquier otro valor de cadena no es válido para un mapeo `long` de Elasticseearch y se elimina el registro de actualización del flujo correspondiente. Estos son algunos ejemplos de valores de Gremlin válidos: ``` "testLong" : "123". ":testLong" : "145.0" ":testLong" : "-9223372036854775807" ``` Estos son algunos ejemplos de SPARQL válidos: ``` ":testLong" : "145.0"^^xsd:string ":testLong" : "-9223372036854775807"^^xsd:string ``` Estos son algunos ejemplos de Gremlin no válidos: ``` "testLong" : "123.45" ":testLong" : "9223372036854775900" ":testLong" : "abc" ``` Estos son algunos ejemplos de SPARQL no válidos: ``` ":testLong" : "123.45"^^xsd:string ":testLong" : "abc" ":testLong" : "9223372036854775900"^^xsd:string ``` + **`double`**: si el tipo de mapeo de OpenSearch es `double`, se aplican las siguientes reglas (en este caso, se supone que el campo "testDouble" tiene un mapeo `double` en OpenSearch): + `boolean`: no es válido, no se puede convertir y se elimina el registro de actualización del flujo correspondiente. Estos son algunos ejemplos de Gremlin no válidos: ``` "testDouble" : true. "testDouble" : false. ``` Estos son algunos ejemplos de SPARQL no válidos: ``` ":testDouble" : "true"^^xsd:boolean ":testDouble" : "false"^^xsd:boolean ``` + `datetime`: no es válido, no se puede convertir y se elimina el registro de actualización del flujo correspondiente. Este es un ejemplo de un valor de Gremlin no válido: ``` ":testDouble" : datetime('2018-11-04T00:00:00'). ``` Este es un ejemplo de un valor de SPARQL no válido: ``` ":testDouble" : "2016-01-01"^^xsd:date ``` + `NaN` o `INF` de punto flotante: si el valor de SPARQL es un `NaN` o `INF` de punto flotante, entonces no es válido y se elimina el registro de actualización del flujo correspondiente. Estos son algunos ejemplos de SPARQL no válidos: ``` " :testDouble" : "NaN"^^xsd:float ":testDouble" : "NaN"^^double ":testDouble" : "INF"^^double ":testDouble" : "-INF"^^double ``` + number o cadena numérica: si el valor de Neptune es cualquier otro número o cadena numérica que represente un número que se pueda expresar de forma segura como `double`, entonces es válido y se convierte en `double` en OpenSearch. Cualquier otro valor de cadena no es válido para un mapeo `double` de OpenSearch y se elimina el registro de actualización del flujo correspondiente. Estos son algunos ejemplos de valores de Gremlin válidos: ``` "testDouble" : 123 ":testDouble" : "123" ":testDouble" : 145.67 ":testDouble" : "145.67" ``` Estos son algunos ejemplos de SPARQL válidos: ``` ":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 ``` Este es un ejemplo de un valor de Gremlin no válido: ``` ":testDouble" : "abc" ``` Estos son algunos ejemplos de SPARQL no válidos: ``` ":testDouble" : "abc" ``` + **`date`**: si el tipo de mapeo de OpenSearch es `date`, los valores de `date` y `dateTime` de Neptune son válidos, al igual que cualquier valor de cadena que se pueda analizar correctamente en un formato `dateTime`. Estos son algunos ejemplos de valores válidos en Gremlin o SPARQL: ``` 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" ``` Estos son ejemplos de valores no válidos: ``` 123.45 True "abc" ``` # Ejemplos de consultas de OpenSearch sin cadenas en Neptune Actualmente, Neptune no admite directamente las consultas de rango de OpenSearch. Sin embargo, puede lograr el mismo efecto con la sintaxis de Lucene y query-type="query\$1string", como puede ver en las siguientes consultas de ejemplo. ## Obtenga todos los vértices con una antigüedad superior a 30 años y un nombre que comience por "Si" En 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 . } } ``` Aquí, se usa `"\\*foaf\\*age` en lugar del URI completo por motivos de concisión. Esta expresión regular recupera todos los campos que contengan tanto `foaf` como `age` en el URI. ## Obtenga todos los nodos con una antigüedad comprendida entre 10 y 50 años y un nombre con una coincidencia parcial con "Ronka" En 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 . } } ``` ## Obtenga todos los nodos con una marca temporal que esté comprendida dentro de los últimos 25 días En 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 . } } ``` ## Obtenga todos los nodos con una marca temporal que esté dentro de un año y un mes determinados En Gremlin, usando [expresiones matemáticas de fecha](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/common-options.html#date-math) en la sintaxis de Lucene, para diciembre de 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'); ``` Una alternativa a 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]'); ```