Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # OpenSearch Indexierung ohne Zeichenketten in Amazon Neptune Die OpenSearch Nicht-String-Indizierung in Amazon Neptune ermöglicht die Replikation von Nicht-String-Werten für Prädikate mithilfe des Stream-Pollers. OpenSearch Alle Prädikatwerte, die sicher in ein entsprechendes Mapping oder einen entsprechenden Datentyp konvertiert werden können, werden anschließend repliziert. OpenSearch OpenSearch Damit die Indexierung ohne Zeichenketten für einen neuen Stack aktiviert werden kann, muss das `Enable Non-String Indexing` Flag in der CloudFormation Vorlage auf gesetzt sein. `true` Dies ist die Standardeinstellung. Um einen vorhandenen Stack so zu aktualisieren, dass er die Nicht-Zeichenfolgen-Indizierung unterstützt, siehe unten unter [Aktualisieren eines vorhandenen Stacks](full-text-search-non-string-indexing-update.md). **Anmerkung** Es ist empfehlenswert, die Nicht-Zeichenfolgen-Indizierung nicht für Engine-Versionen zu aktivieren, die älter sind als **`1.0.4.2`**. OpenSearch Abfragen, die reguläre Ausdrücke für Feldnamen verwenden, die mehreren Feldern entsprechen, von denen einige Zeichenkettenwerte und andere Nichtzeichenfolgenwerte enthalten, schlagen mit einem Fehler fehl. Dies passiert auch, wenn Volltext-Suchanfragen in Neptune diesen Typ haben. Wenn Sie nach einem Nicht-Zeichenfolgenfeld sortieren, hängen Sie „.value“ an den Feldnamen an, um das Feld von einem Zeichenfolgenfeld zu unterscheiden. **Contents** + [Aktualisieren eines vorhandenen Neptune-Volltextsuchstacks zur Unterstützung der Nicht-Zeichenfolgen-Indizierung](full-text-search-non-string-indexing-update.md) + [Filtern, welche Felder in der Neptune-Volltextsuche indiziert werden](full-text-search-non-string-indexing-filters.md) + [Filtern nach Eigenschaften- oder Prädikatnamen](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-name) + [Filtern nach Eigenschaften- oder Prädikatstyp](full-text-search-non-string-indexing-filters.md#full-text-search-non-string-indexing-filters-datatype) + [Zuordnung von SPARQL- und Gremlin-Datentypen zu OpenSearch](full-text-search-non-string-indexing-mapping.md) + [Validierung von Datenzuordnungen](full-text-search-data-validation.md) + [OpenSearch Beispielabfragen ohne Zeichenfolge in Neptune](full-text-search-non-string-examples.md) + [Abrufen alle Scheitelpunkte, deren Alter über 30 liegt und deren Name mit „Si“ beginnt](full-text-search-non-string-examples.md#full-text-search-non-string-example-1) + [Abrufen aller Knoten mit einem Alter zwischen 10 und 50 und einem Namen, der unscharf mit „Ronka“ übereinstimmt](full-text-search-non-string-examples.md#full-text-search-non-string-example-2) + [Abrufen aller Knoten mit einem Zeitstempel, der in die letzten 25 Tage fällt](full-text-search-non-string-examples.md#full-text-search-non-string-example-3) + [Abrufen aller Knoten mit einem Zeitstempel, der in ein bestimmtes Jahr und einen bestimmten Monat fällt](full-text-search-non-string-examples.md#full-text-search-non-string-example-4) # Aktualisieren eines vorhandenen Neptune-Volltextsuchstacks zur Unterstützung der Nicht-Zeichenfolgen-Indizierung Wenn Sie die Neptune-Volltextsuche bereits verwenden, müssen Sie die folgenden Schritte ausführen, um die Nicht-Zeichenfolgen-Indizierung zu unterstützen: 1. **Halten Sie die Lambda-Funktion des Stream-Pollers an.** Dadurch wird sichergestellt, dass beim Export keine neuen Updates kopiert werden. Deaktivieren Sie dazu die Cloud-Ereignisregel, die die Lambda-Funktion aufruft: + Navigieren Sie im AWS-Managementkonsole zu CloudWatch. + Wählen Sie **Regeln** aus. + Wählen Sie die Regel mit dem Namen des Lambda-Stream-Pollers aus. + Wählen Sie **Deaktivieren** aus, um die Regel vorübergehend zu deaktivieren. 1. **Löscht den aktuellen Neptun-Index in. OpenSearch** Verwenden Sie die folgende `curl` Abfrage, um den `amazon_neptune` Index aus Ihrem OpenSearch Cluster zu löschen: ``` curl -X DELETE "your OpenSearch endpoint/amazon_neptune" ``` 1. **Starten Sie einen einmaligen Export von Neptune nach. OpenSearch** Es empfiehlt sich, an dieser Stelle einen neuen OpenSearch Stack einzurichten, sodass neue Artefakte für den Poller, der den Export durchführt, aufgenommen werden. Folgen Sie den [hier aufgeführten Schritten GitHub, um den einmaligen Export Ihrer Neptun-Daten in]( https://github.com/awslabs/amazon-neptune-tools/blob/master/export-neptune-to-elasticsearch/readme.md) zu starten. OpenSearch 1. **Aktualisieren Sie die Lambda-Artefakte für den vorhandenen Stream-Poller.** Nachdem der Export der Neptun-Daten nach erfolgreich abgeschlossen OpenSearch wurde, führen Sie die folgenden Schritte aus: + Navigieren Sie im AWS-Managementkonsole zu. CloudFormation + Wählen Sie den übergeordneten CloudFormation Hauptstapel aus. + Wählen Sie die Option **Aktualisieren** für diesen Stack aus. + Wählen Sie **Aktuelle Vorlage aus den Optionen ersetzen**. + Wählen Sie unter „Vorlagenquelle“ die Option **Amazon S3 URL** aus. + Geben Sie für die Amazon-S3-URL Folgendes ein: ``` https://aws-neptune-customer-samples.s3.amazonaws.com/neptune-stream/neptune_to_elastic_search.json ``` + Wählen Sie **Weiter**, ohne einen der CloudFormation Parameter zu ändern. + Wählen Sie **Stack aktualisieren** aus. CloudFormation ersetzt die Lambda-Code-Artefakte für den Stream-Poller durch die neuesten Artefakte. 1. **Starten Sie den Stream-Poller erneut.** Aktivieren Sie dazu die entsprechende CloudWatch Regel: + Navigieren Sie im AWS-Managementkonsole zu CloudWatch. + Wählen Sie **Regeln** aus. + Wählen Sie die Regel mit dem Namen des Lambda-Stream-Pollers aus. + Wählen Sie **Aktivieren**. # Filtern, welche Felder in der Neptune-Volltextsuche indiziert werden In den CloudFormation Vorlagendetails gibt es zwei Felder, in denen Sie Eigenschafts- oder Prädikatschlüssel oder Datentypen angeben können, die von der Indizierung ausgeschlossen werden sollen: OpenSearch ## Filtern nach Eigenschaften- oder Prädikatnamen Sie können den optionalen CloudFormation Vorlagenparameter named verwenden, `Properties to exclude from being inserted into Elastic Search Index` um eine durch Kommas getrennte Liste von Eigenschafts- oder Prädikatschlüsseln bereitzustellen, die von der Indizierung ausgeschlossen werden sollen. OpenSearch Angenommen, Sie haben diesen Parameter auf `bob` festgelegt: ``` "Properties to exclude from being inserted into Elastic Search Index" : bob ``` In diesem Fall würde der Stream-Datensatz der folgenden Gremlin-Aktualisierungsabfrage gelöscht, anstatt in den Index aufgenommen zu werden: ``` g.V("1").property("bob", "test") ``` In ähnlicher Weise könnten Sie den Parameter auf `http://my/example#bob` setzen: ``` "Properties to exclude from being inserted into Elastic Search Index" : http://my/example#bob ``` In diesem Fall würde der Stream-Datensatz der folgenden SPARQL-Aktualisierungsabfrage gelöscht, anstatt in den Index aufgenommen zu werden: ``` PREFIX ex: INSERT DATA { ex:s1 ex:bob "test"}. ``` Wenn Sie in diesen CloudFormation Vorlagenparameter nichts eingeben, werden alle Eigenschaftsschlüssel, die nicht anderweitig ausgeschlossen wurden, indexiert. ## Filtern nach Eigenschaften- oder Prädikatstyp Sie können den optionalen CloudFormation Vorlagenparameter named verwenden, `Datatypes to exclude from being inserted into Elastic Search Index` um eine durch Kommas getrennte Liste von Eigenschaften- oder Prädikatwert-Datentypen bereitzustellen, die von der Indizierung ausgeschlossen werden sollen. OpenSearch Für SPARQL müssen Sie nicht den vollständigen URI vom Typ XSD auflisten, Sie können einfach das Datentyp-Token auflisten. Gültige Datentyp-Token, die Sie auflisten können, sind: + `string` + `boolean` + `float` + `double` + `dateTime` + `date` + `time` + `byte` + `short` + `int` + `long` + `decimal` + `integer` + `nonNegativeInteger` + `nonPositiveInteger` + `negativeInteger` + `unsignedByte` + `unsignedShort` + `unsignedInt` + `unsignedLong` Für Gremlin sind folgende Datentypen zum Auflisten gültig: + `string` + `date` + `bool` + `byte` + `short` + `int` + `long` + `float` + `double` Angenommen, Sie haben diesen Parameter auf `string` festgelegt: ``` "Datatypes to exclude from being inserted into Elastic Search Index" : string ``` In diesem Fall würde der Stream-Datensatz der folgenden Gremlin-Aktualisierungsabfrage gelöscht, anstatt in den Index aufgenommen zu werden: ``` g.V("1").property("myStringval", "testvalue") ``` In ähnlicher Weise könnten Sie den Parameter auf `int` setzen: ``` "Datatypes to exclude from being inserted into Elastic Search Index" : int ``` In diesem Fall würde der Stream-Datensatz der folgenden SPARQL-Aktualisierungsabfrage gelöscht, anstatt in den Index aufgenommen zu werden: ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:s1 ex:bob "11"^^xsd:int }. ``` Wenn Sie in diesen CloudFormation Vorlagenparameter nichts eingeben, werden alle Eigenschaften indexiert, deren Werte sicher in Äquivalente konvertiert werden können. OpenSearch Aufgelistete Typen, die von der Abfragesprache nicht unterstützt werden, werden ignoriert. # Zuordnung von SPARQL- und Gremlin-Datentypen zu OpenSearch Neue Datentypzuordnungen in OpenSearch werden auf der Grundlage des Datentyps erstellt, der in der Eigenschaft oder dem Objekt verwendet wird. Da einige Felder Werte unterschiedlichen Typs enthalten, kann es sein, dass bei der ersten Zuordnung einige Werte des Felds ausgeschlossen werden. Neptun-Datentypen werden Datentypen wie folgt zugeordnet OpenSearch : | SPARQL-Typen | Gremlin-Typen | OpenSearch Typen | | --- | --- | --- | | `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` | | *Benutzerdefinierter Datentyp* | *N/A* | `text` | | *Jeder andere Datentyp* | *N/A* | `text` | Die folgende Gremlin-Aktualisierungsabfrage bewirkt beispielsweise, dass ein neues Mapping für „NewField“ hinzugefügt wird, und zwar: OpenSearch `{ "type" : "double" }` ``` g.V("1").property("newField" 10.5) ``` In ähnlicher Weise bewirkt die folgende SPARQL-Aktualisierungsabfrage, dass ein neues Mapping für „ex:byte“ hinzugefügt wird, und zwar: OpenSearch `{ "type" : "long" }` ``` PREFIX ex: PREFIX xsd: INSERT DATA { ex:test ex:byte "123"^^xsd:byte }. ``` **Anmerkung** Wie Sie sehen können, OpenSearch kann ein Objekt, das von Neptune auf zugeordnet wurde, am Ende einen anderen Datentyp haben OpenSearch als in Neptune. Es gibt jedoch ein explizites Textfeld in „datatype“ OpenSearch, das den Datentyp aufzeichnet, den das Element in Neptune hat. # Validierung von Datenzuordnungen Daten werden mit diesem Verfahren OpenSearch von Neptune aus repliziert: + Wenn eine Zuordnung für das fragliche Feld bereits vorhanden ist in: OpenSearch + Wenn die Daten mithilfe von Datenvalidierungsregeln sicher in die vorhandene Zuordnung konvertiert werden können, speichern Sie das Feld in OpenSearch. + Andernfalls löschen Sie den entsprechenden Stream-Update-Datensatz. + Wenn für das fragliche Feld keine Zuordnung vorhanden ist, suchen Sie einen OpenSearch Datentyp, der dem Datentyp des Felds in Neptune entspricht. + Wenn die Felddaten mithilfe von Datenvalidierungsregeln sicher in den OpenSearch Datentyp konvertiert werden können, speichern Sie die neue Zuordnung und die Felddaten in. OpenSearch + Andernfalls löschen Sie den entsprechenden Stream-Update-Datensatz. Die Werte werden anhand äquivalenter OpenSearch Typen oder vorhandener OpenSearch Zuordnungen und nicht anhand der Neptuntypen validiert. Beispielsweise erfolgt die Validierung des Werts `"123"` in `"123"^^xsd:int` anhand des `long`-Typs und nicht anhand des `int`-Typs. Obwohl Neptune versucht, alle Daten zu replizieren OpenSearch, gibt es Fälle, in denen sich die Datentypen in völlig von denen in Neptune unterscheiden, und in solchen Fällen OpenSearch werden Datensätze übersprungen, anstatt indexiert zu werden. OpenSearch In Neptune kann eine Eigenschaft beispielsweise mehrere Werte unterschiedlichen Typs haben, wohingegen in OpenSearch einem Feld im gesamten Index denselben Typ haben muss. Wenn Sie Debug-Logs aktivieren, können Sie sehen, welche Datensätze beim Export von Neptune nach gelöscht wurden. OpenSearch Ein Beispiel für einen Debug-Protokolleintrag ist: ``` Dropping Record : Data type not a valid Gremlin type ``` Datentypen werden wie folgt validiert: + **`text`**— Alle Werte in Neptune können sicher dem Text in zugeordnet werden. OpenSearch + **`long`**— Die folgenden Regeln für Neptun-Datentypen gelten, wenn der OpenSearch Mapping-Typ lang ist (in den folgenden Beispielen wird davon ausgegangen, dass er einen `long` Mapping-Typ `"testLong"` hat): + `boolean` – Ungültig, kann nicht konvertiert werden und der entsprechende Datensatz zum Stream-Update wird gelöscht. Ungültige Gremlin-Beispiele sind: ``` "testLong" : true. "testLong" : false. ``` Ungültige SPARQL-Beispiele sind: ``` ":testLong" : "true"^^xsd:boolean ":testLong" : "false"^^xsd:boolean ``` + `datetime` – Ungültig, kann nicht konvertiert werden und der entsprechende Datensatz zum Stream-Update wird gelöscht. Ein ungültiges Gremlin-Beispiel ist: ``` ":testLong" : datetime('2018-11-04T00:00:00'). ``` Ein ungültiges SPARQL-Beispiel ist: ``` ":testLong" : "2016-01-01"^^xsd:date ``` + `float`,`double`, oder `decimal` — Wenn der Wert in Neptune eine Ganzzahl ist, die in 64 Bit passen kann, ist er gültig und wird als Long gespeichert, aber wenn er einen Bruchteil hat oder a oder an ist oder größer OpenSearch als 9.223.372.036.854.775.807 oder kleiner als -9.223.372.036.854.775.808 ist`INF`, dann ist er nicht gültig und der entsprechende Stream Der Aktualisierungsdatensatz wurde gelöscht. `NaN` Gültige Gremlin-Beispiele sind: ``` "testLong" : 145.0. ":testLong" : 123 ":testLong" : -9223372036854775807 ``` Gültige SPARQL-Beispiele sind: ``` ":testLong" : "145.0"^^xsd:float ":testLong" : 145.0 ":testLong" : "145.0"^^xsd:double ":testLong" : "145.0"^^xsd:decimal ":testLong" : "-9223372036854775807" ``` Ungültige Gremlin-Beispiele sind: ``` "testLong" : 123.45 ":testLong" : 9223372036854775900 ``` Ungültige SPARQL-Beispiele sind: ``` ":testLong" : 123.45 ":testLong" : 9223372036854775900 ":testLong" : "123.45"^^xsd:float ":testLong" : "123.45"^^xsd:double ":testLong" : "123.45"^^xsd:decimal ``` + `string`— Wenn der Wert in Neptune eine Zeichenkettendarstellung einer Ganzzahl ist, die in einer 64-Bit-Ganzzahl enthalten sein kann, dann ist er gültig und wird in ein `long` In umgewandelt. OpenSearch Jeder andere Zeichenfolgenwert ist für eine Elasticsearch-`long`-Zuordnung ungültig und der entsprechende Stream-Update-Datensatz wird gelöscht. Gültige Gremlin-Beispiele sind: ``` "testLong" : "123". ":testLong" : "145.0" ":testLong" : "-9223372036854775807" ``` Gültige SPARQL-Beispiele sind: ``` ":testLong" : "145.0"^^xsd:string ":testLong" : "-9223372036854775807"^^xsd:string ``` Ungültige Gremlin-Beispiele sind: ``` "testLong" : "123.45" ":testLong" : "9223372036854775900" ":testLong" : "abc" ``` Ungültige SPARQL-Beispiele sind: ``` ":testLong" : "123.45"^^xsd:string ":testLong" : "abc" ":testLong" : "9223372036854775900"^^xsd:string ``` + **`double`**— Wenn der OpenSearch Mapping-Typ ist`double`, gelten die folgenden Regeln (hier wird davon ausgegangen, dass das Feld „TestDouble“ ein `double` Mapping enthält): OpenSearch + `boolean` – Ungültig, kann nicht konvertiert werden und der entsprechende Datensatz zum Stream-Update wird gelöscht. Ungültige Gremlin-Beispiele sind: ``` "testDouble" : true. "testDouble" : false. ``` Ungültige SPARQL-Beispiele sind: ``` ":testDouble" : "true"^^xsd:boolean ":testDouble" : "false"^^xsd:boolean ``` + `datetime` – Ungültig, kann nicht konvertiert werden und der entsprechende Datensatz zum Stream-Update wird gelöscht. Ein ungültiges Gremlin-Beispiel ist: ``` ":testDouble" : datetime('2018-11-04T00:00:00'). ``` Ein ungültiges SPARQL-Beispiel ist: ``` ":testDouble" : "2016-01-01"^^xsd:date ``` + Gleitkomma-`NaN` oder -`INF` – Wenn der Wert in SPARQL ein Gleitkomma-`NaN` oder -`INF` ist, dann ist er nicht gültig und der entsprechende Stream-Update-Datensatz wird gelöscht. Ungültige SPARQL-Beispiele sind: ``` " :testDouble" : "NaN"^^xsd:float ":testDouble" : "NaN"^^double ":testDouble" : "INF"^^double ":testDouble" : "-INF"^^double ``` + Zahl oder numerische Zeichenfolge — Wenn der Wert in Neptune eine andere Zahl oder numerische Zeichenkettendarstellung einer Zahl ist, die sicher als a ausgedrückt werden kann`double`, dann ist er gültig und wird in ein In umgewandelt. `double` OpenSearch Jeder andere Zeichenkettenwert ist für eine OpenSearch `double` Zuordnung ungültig und der entsprechende Datensatz zur Stream-Aktualisierung wird gelöscht. Gültige Gremlin-Beispiele sind: ``` "testDouble" : 123 ":testDouble" : "123" ":testDouble" : 145.67 ":testDouble" : "145.67" ``` Gültige SPARQL-Beispiele sind: ``` ":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 ``` Ein ungültiges Gremlin-Beispiel ist: ``` ":testDouble" : "abc" ``` Ein ungültiges SPARQL-Beispiel ist: ``` ":testDouble" : "abc" ``` + **`date`**— Wenn der OpenSearch Mapping-Typ ist`date`, sind Neptune `date` und der `dateTime` Wert gültig, ebenso wie jeder Zeichenkettenwert, der erfolgreich in ein Format geparst werden kann. `dateTime` Gültige Beispiele in Gremlin oder SPARQL sind: ``` 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" ``` Ungültige Beispiele sind: ``` 123.45 True "abc" ``` # OpenSearch Beispielabfragen ohne Zeichenfolge in Neptune Neptune unterstützt derzeit keine direkten OpenSearch Bereichsabfragen. Sie können jedoch den gleichen Effekt mit der Lucene-Syntax und query-type="query\$1string“ erzielen, wie Sie in den folgenden Beispielabfragen sehen können. ## Abrufen alle Scheitelpunkte, deren Alter über 30 liegt und deren Name mit „Si“ beginnt In 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*'); ``` In 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 . } } ``` Hier wird der Kürze halber `"\\*foaf\\*age` anstelle des vollständigen URI verwendet. Dieser reguläre Ausdruck ruft alle Felder ab, die `foaf` und `age` im URI enthalten. ## Abrufen aller Knoten mit einem Alter zwischen 10 und 50 und einem Namen, der unscharf mit „Ronka“ übereinstimmt In 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~'); ``` In 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 . } } ``` ## Abrufen aller Knoten mit einem Zeitstempel, der in die letzten 25 Tage fällt In 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'); ``` In 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 . } } ``` ## Abrufen aller Knoten mit einem Zeitstempel, der in ein bestimmtes Jahr und einen bestimmten Monat fällt In Gremlin unter Verwendung von [mathematischen Datumsausdrücken](https://www.elastic.co/guide/en/elasticsearch/reference/7.x/common-options.html#date-math) in der Lucene-Syntax für Dezember 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'); ``` Eine Gremlin-Alternative: ``` 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]'); ```