As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Indexação sem string do OpenSearch no Amazon Neptune A indexação do OpenSearch sem string no Amazon Neptune permite replicar valores que não sejam string para predicados no OpenSearch usando o instrumento de sondagem de fluxos. Todos os valores de predicados que podem ser convertidos com segurança em um mapeamento ou um tipo de dados correspondente do OpenSearch são então replicados no OpenSearch. Para que a indexação sem string seja habilitada em uma nova pilha, o sinalizador `Enable Non-String Indexing` no modelo CloudFormation deve ser definido como `true`. Essa é a configuração padrão. Para atualizar uma pilha existente com o objetivo de oferecer compatibilidade com a indexação sem string, veja [Atualizar uma pilha existente](full-text-search-non-string-indexing-update.md) abaixo. **nota** É melhor não habilitar a indexação sem string em versões do mecanismo anteriores a **`1.0.4.2`**. As consultas do OpenSearch que usam expressões regulares para nomes de campo correspondentes a vários campos, alguns dos quais contêm valores de string e outros que não contêm valores de string, falham com um erro. O mesmo acontecerá se as consultas de pesquisa de texto completo no Neptune forem desse tipo. Ao classificar por um campo que não seja de string, acrescente “valor” ao nome do campo para diferenciá-lo de um campo de string. **Contents** + [Atualizar uma pilha de pesquisa de texto completo existente do Neptune para oferecer compatibilidade com a indexação sem string](full-text-search-non-string-indexing-update.md) + [Filtrar quais campos são indexados na pesquisa de texto completo do Neptune](full-text-search-non-string-indexing-filters.md) + [Filtrar por nome de propriedade ou predicado](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-name) + [Filtrar por tipo de valor de propriedade ou predicado](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-datatype) + [Mapeamento dos tipos de dados SPARQL e Gremlin para o OpenSearch](full-text-search-non-string-indexing-mapping.md) + [Validação de mapeamentos de dados](full-text-search-data-validation.md) + [Exemplos de consulta do OpenSearch sem string no Neptune](full-text-search-non-string-examples.md) + [Obter todos os vértices com idade maior que 30 e nome começando com “Si”](full-text-search-non-string-examples.md#full-text-search-non-string-example-1) + [Obter todos os nós com idades entre 10 e 50 e um nome com uma combinação difusa com “Ronka”](full-text-search-non-string-examples.md#full-text-search-non-string-example-2) + [Obter todos os nós com um carimbo de data/hora que se enquadra nos últimos 25 dias](full-text-search-non-string-examples.md#full-text-search-non-string-example-3) + [Obter todos os nós com um carimbo de data/hora que se enquadre em um ano e mês específicos](full-text-search-non-string-examples.md#full-text-search-non-string-example-4) # Atualizar uma pilha de pesquisa de texto completo existente do Neptune para oferecer compatibilidade com a indexação sem string Se você já estiver usando a pesquisa de texto completo do Neptune, veja as etapas que você precisa seguir para oferecer compatibilidade com a indexação sem string: 1. **Interrompa a função do Lambda do instrumento de sondagem de fluxos.** Isso garante que nenhuma nova atualização seja copiada durante a exportação. Faça isso desabilitando a regra de evento de nuvem que invoca a função do Lambda: + No Console de gerenciamento da AWS, acesse o CloudWatch. + Selecione **Regras**. + Escolha a regra com o nome do instrumento de sondagem de fluxos do Lambda. + Selecione **desabilitar** para desabilitar temporariamente a regra. 1. **Exclua o índice atual do Neptune no OpenSearch.** Use a seguinte consulta `curl` para excluir o índice `amazon_neptune` do cluster do OpenSearch: ``` curl -X DELETE "your OpenSearch endpoint/amazon_neptune" ``` 1. **Inicie uma exportação única do Neptune para o OpenSearch.** É melhor configurar uma nova pilha do OpenSearch neste momento, para que novos artefatos sejam coletados para o instrumento de sondagem que executa a exportação. Siga as etapas listadas [aqui no GitHub]( https://github.com/awslabs/amazon-neptune-tools/blob/master/export-neptune-to-elasticsearch/readme.md) para iniciar a exportação única dos dados do Neptune para o OpenSearch. 1. **Atualize os artefatos do Lambda para o instrumento de sondagem de fluxos existente.** Depois que a exportação dos dados do Neptune para o OpenSearch for concluída com êxito, siga estas etapas: + No Console de gerenciamento da AWS, navegue até o CloudFormation. + Escolha a pilha CloudFormation principal. + Selecione a opção **Atualizar** para a pilha. + Selecione **Substituir modelo atual nas opções**. + Na origem do modelo, selecione **URL do Amazon S3**. + Para o URL do Amazon S3, insira: ``` https://aws-neptune-customer-samples.s3.amazonaws.com/neptune-stream/neptune_to_elastic_search.json ``` + Selecione **Próximo** sem alterar nenhum parâmetro CloudFormation. + Selecione **Atualizar pilha**. O CloudFormation substituirá os artefatos do código do Lambda do instrumento de sondagem de fluxos pelos artefatos mais recentes. 1. **Inicie o instrumento de sondagem de fluxos novamente.** Faça isso habilitando a regra apropriada do CloudWatch: + No Console de gerenciamento da AWS, acesse o CloudWatch. + Selecione **Regras**. + Escolha a regra com o nome do instrumento de sondagem de fluxos do Lambda. + Selecione **Habilitar**. # Filtrar quais campos são indexados na pesquisa de texto completo do Neptune Há dois campos nos detalhes do modelo do CloudFormation que permitem especificar chaves de propriedade ou predicado ou tipos de dados a serem excluídos da indexação do OpenSearch: ## Filtrar por nome de propriedade ou predicado É possível usar o parâmetro opcional do modelo do CloudFormation denominado `Properties to exclude from being inserted into Elastic Search Index` para fornecer uma lista delimitada por vírgulas de chaves de propriedade ou predicado a serem excluídas da indexação do OpenSearch. Por exemplo, digamos que você defina esse parâmetro como `bob`. ``` "Properties to exclude from being inserted into Elastic Search Index" : bob ``` Nesse caso, o registro de fluxo da seguinte consulta de atualização do Gremlin seria descartado em vez de inserido no índice: ``` g.V("1").property("bob", "test") ``` Da mesma forma, é possível definir o parâmetro como `http://my/example#bob`: ``` "Properties to exclude from being inserted into Elastic Search Index" : http://my/example#bob ``` Nesse caso, o registro de fluxo da seguinte consulta de atualização do SPARQL seria descartado em vez de inserido no índice: ``` PREFIX ex: INSERT DATA { ex:s1 ex:bob "test"}. ``` Se você não inserir nada nesse parâmetro do modelo do CloudFormation, todas as chaves de propriedade não excluídas de outra forma serão indexadas. ## Filtrar por tipo de valor de propriedade ou predicado É possível usar o parâmetro opcional do modelo do CloudFormation denominado `Datatypes to exclude from being inserted into Elastic Search Index` para fornecer uma lista delimitada por vírgulas de tipos de dados de valor de propriedade ou predicado a serem excluídos da indexação do OpenSearch. Para SPARQL, não é necessário listar o URI completo do tipo XSD. Basta listar o token do tipo de dados. Os tokens de tipos de dados válidos que você pode listar são: + `string` + `boolean` + `float` + `double` + `dateTime` + `date` + `time` + `byte` + `short` + `int` + `long` + `decimal` + `integer` + `nonNegativeInteger` + `nonPositiveInteger` + `negativeInteger` + `unsignedByte` + `unsignedShort` + `unsignedInt` + `unsignedLong` Para Gremlin, os tipos de dados válidos para listar são: + `string` + `date` + `bool` + `byte` + `short` + `int` + `long` + `float` + `double` Por exemplo, digamos que você defina esse parâmetro como `string`. ``` "Datatypes to exclude from being inserted into Elastic Search Index" : string ``` Nesse caso, o registro de fluxo da seguinte consulta de atualização do Gremlin seria descartado em vez de inserido no índice: ``` g.V("1").property("myStringval", "testvalue") ``` Da mesma forma, é possível definir o parâmetro como `int`: ``` "Datatypes to exclude from being inserted into Elastic Search Index" : int ``` Nesse caso, o registro de fluxo da seguinte consulta de atualização do SPARQL seria descartado em vez de inserido no índice: ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:s1 ex:bob "11"^^xsd:int }. ``` Se você não inserir nada nesse parâmetro do modelo do CloudFormation, todas as propriedades cujos valores podem ser convertidos com segurança em equivalentes do OpenSearch serão indexadas. Os tipos listados que não são compatíveis com a linguagem de consulta são ignorados. # Mapeamento dos tipos de dados SPARQL e Gremlin para o OpenSearch Novos mapeamentos de tipos de dados no OpenSearch são criados com base nos tipos de dados usados na propriedade ou no objeto. Como alguns campos contêm valores de tipos diferentes, o mapeamento inicial pode excluir alguns valores do campo. Os tipos de dados do Neptune são associados aos tipos de dados do OpenSearch da seguinte forma: | Tipos do SPARQL | Tipos do Gremlin | Tipos do 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 dados personalizado* | *N/D* | `text` | | *Qualquer outro tipo de dados* | *N/D* | `text` | Por exemplo, a seguinte consulta de atualização do Gremlin faz com que um novo mapeamento para “NewField” seja adicionado ao OpenSearch `{ "type" : "double" }`: ``` g.V("1").property("newField" 10.5) ``` Da mesma forma, a seguinte consulta de atualização do SPARQL faz com que um novo mapeamento para “ex:byte” seja adicionado ao OpenSearch `{ "type" : "long" }`: ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:test ex:byte "123"^^xsd:byte }. ``` **nota** Como você pode ver, um item associado do Neptune ao OpenSearch pode terminar com tipos de dados diferentes no OpenSearch e no Neptune. No entanto, há um campo de texto explícito no OpenSearch, “tipo de dados”, que registra o tipo de dados que o item tem no Neptune. # Validação de mapeamentos de dados Os dados são replicados do Neptune no OpenSearch usando este processo: + Se já houver um mapeamento para o campo em questão no OpenSearch: + Se os dados puderem ser convertidos com segurança no mapeamento existente usando regras de validação de dados, armazene o campo no OpenSearch. + Caso contrário, elimine o registro de atualização de fluxos correspondente. + Se não houver mapeamento existente para o campo em questão, encontre um tipo de dados do OpenSearch correspondente ao tipo de dados do campo no Neptune. + Se os dados do campo puderem ser convertidos com segurança no tipo de dados do OpenSearch usando regras de validação de dados, armazene o novo mapeamento e os dados do campo no OpenSearch. + Caso contrário, elimine o registro de atualização de fluxos correspondente. Os valores são validados em relação aos tipos equivalentes do OpenSearch ou aos mapeamentos existentes do OpenSearch e não aos tipos do Neptune. Por exemplo, a validação do valor `"123"` no `"123"^^xsd:int` é feita em relação ao tipo `long` e não ao tipo `int`. Embora o Neptune tente replicar todos os dados no OpenSearch, há casos em que os tipos de dados no OpenSearch são totalmente diferentes dos tipos no Neptune e, nesses casos, os registros são ignorados em vez de serem indexados no OpenSearch. Por exemplo, no Neptune, uma propriedade pode ter vários valores de tipos diferentes, enquanto no OpenSearch um campo deve ter o mesmo tipo em todo o índice. Ao habilitar os logs de depuração, é possível ver quais registros foram descartados durante a exportação do Neptune para o OpenSearch. É um exemplo de entrada de log de depuração: ``` Dropping Record : Data type not a valid Gremlin type ``` Os tipos de dados são validados da seguinte forma: + **`text`**: todos os valores no Neptune podem ser associados com segurança ao texto no OpenSearch. + **`long`**: as seguintes regras para os tipos de dados do Neptune se aplicam quando o tipo de mapeamento do OpenSearch é longo (nos exemplos abaixo, presume-se que `"testLong"` tenha um tipo de mapeamento `long`): + `boolean`: inválido, não pode ser convertido e o registro de atualização de fluxos correspondente é descartado. São exemplos de Gremlin inválidos: ``` "testLong" : true. "testLong" : false. ``` São exemplos de SPARQL inválidos: ``` ":testLong" : "true"^^xsd:boolean ":testLong" : "false"^^xsd:boolean ``` + `datetime`: inválido, não pode ser convertido e o registro de atualização de fluxos correspondente é descartado. É um exemplo de Gremlin inválido: ``` ":testLong" : datetime('2018-11-04T00:00:00'). ``` É um exemplo de SPARQL inválido: ``` ":testLong" : "2016-01-01"^^xsd:date ``` + `float`, `double` ou `decimal`: se o valor no Neptune for um número inteiro que caiba em 64 bits, ele será válido e será armazenado no OpenSearch como um valor longo, mas se tiver uma parte fracionária ou for `NaN` ou `INF`, ou for maior que 9.223.372.036.854.775.807 ou menor que -9.223.372.036.857.75.808, não será válido, e o registro de atualização de fluxos correspondente será descartado. São exemplos de Gremlin válidos: ``` "testLong" : 145.0. ":testLong" : 123 ":testLong" : -9223372036854775807 ``` São exemplos de SPARQL válidos: ``` ":testLong" : "145.0"^^xsd:float ":testLong" : 145.0 ":testLong" : "145.0"^^xsd:double ":testLong" : "145.0"^^xsd:decimal ":testLong" : "-9223372036854775807" ``` São exemplos de Gremlin inválidos: ``` "testLong" : 123.45 ":testLong" : 9223372036854775900 ``` São exemplos de SPARQL inválidos: ``` ":testLong" : 123.45 ":testLong" : 9223372036854775900 ":testLong" : "123.45"^^xsd:float ":testLong" : "123.45"^^xsd:double ":testLong" : "123.45"^^xsd:decimal ``` + `string`: se o valor no Neptune for uma representação em string de um valor inteiro que possa estar contido em um número inteiro de 64 bits, ele será válido e será convertido em um `long` no OpenSearch. Qualquer outro valor de string será inválido para um mapeamento `long` do ElasticSearch e o registro de atualização de fluxos correspondente será descartado. São exemplos de Gremlin válidos: ``` "testLong" : "123". ":testLong" : "145.0" ":testLong" : "-9223372036854775807" ``` São exemplos de SPARQL válidos: ``` ":testLong" : "145.0"^^xsd:string ":testLong" : "-9223372036854775807"^^xsd:string ``` São exemplos de Gremlin inválidos: ``` "testLong" : "123.45" ":testLong" : "9223372036854775900" ":testLong" : "abc" ``` São exemplos de SPARQL inválidos: ``` ":testLong" : "123.45"^^xsd:string ":testLong" : "abc" ":testLong" : "9223372036854775900"^^xsd:string ``` + **`double`**: se o tipo de mapeamento do OpenSearch for `double`, as seguintes regras se aplicarão (aqui, presume-se que o campo “testDouble” tenha um mapeamento `double` no OpenSearch): + `boolean`: inválido, não pode ser convertido e o registro de atualização de fluxos correspondente é descartado. São exemplos de Gremlin inválidos: ``` "testDouble" : true. "testDouble" : false. ``` São exemplos de SPARQL inválidos: ``` ":testDouble" : "true"^^xsd:boolean ":testDouble" : "false"^^xsd:boolean ``` + `datetime`: inválido, não pode ser convertido e o registro de atualização de fluxos correspondente é descartado. É um exemplo de Gremlin inválido: ``` ":testDouble" : datetime('2018-11-04T00:00:00'). ``` É um exemplo de SPARQL inválido: ``` ":testDouble" : "2016-01-01"^^xsd:date ``` + Ponto flutuante `NaN` ou `INF`: se o valor em SPARQL for um ponto flutuante `NaN` ou `INF`, ele não será válido e o registro de atualização de fluxos correspondente será descartado. São exemplos de SPARQL inválidos: ``` " :testDouble" : "NaN"^^xsd:float ":testDouble" : "NaN"^^double ":testDouble" : "INF"^^double ":testDouble" : "-INF"^^double ``` + número ou string numérica: se o valor no Neptune for qualquer outro número ou representação de string numérica de um número que possa ser expresso com segurança como `double`, ele será válido e convertido em `double` no OpenSearch. Qualquer outro valor de string será inválido para um mapeamento `double` do OpenSearch e o registro de atualização de fluxos correspondente será descartado. São exemplos de Gremlin válidos: ``` "testDouble" : 123 ":testDouble" : "123" ":testDouble" : 145.67 ":testDouble" : "145.67" ``` São exemplos 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 ``` É um exemplo de Gremlin inválido: ``` ":testDouble" : "abc" ``` É um exemplo de SPARQL inválido: ``` ":testDouble" : "abc" ``` + **`date`**: se o tipo de mapeamento do OpenSearch for `date`, os valores `date` e `dateTime` do Neptune serão válidos, assim como qualquer valor de string que possa ser analisado com êxito em um formato `dateTime`. São exemplos válidos no Gremlin ou no 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" ``` São exemplos inválidos: ``` 123.45 True "abc" ``` # Exemplos de consulta do OpenSearch sem string no Neptune No momento, o Neptune não é compatível com consultas de intervalo do OpenSearch diretamente. No entanto, é possível obter o mesmo efeito usando a sintaxe Lucene e query-type="query\$1string”, como você pode ver nos exemplos de consulta a seguir. ## Obter todos os vértices com idade maior que 30 e nome começando com “Si” No 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*'); ``` No 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 . } } ``` Para resumir, aqui, `"\\*foaf\\*age` é usado em vez do URI completo. Essa expressão regular recuperará todos os campos que tenham `foaf` e `age` no URI. ## Obter todos os nós com idades entre 10 e 50 e um nome com uma combinação difusa com “Ronka” No 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~'); ``` No 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 . } } ``` ## Obter todos os nós com um carimbo de data/hora que se enquadra nos últimos 25 dias No 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'); ``` No 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 . } } ``` ## Obter todos os nós com um carimbo de data/hora que se enquadre em um ano e mês específicos No Gremlin, usar [expressões matemáticas de data](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/common-options.html#date-math) na sintaxe Lucene, para dezembro 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'); ``` Uma alternativa ao 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]'); ```