Amazon Neptune Engine versione 1.3.2.0 (2024-06-10)

A partire dal 10 giugno 2024, la versione del motore 1.3.2.0 viene generalmente distribuita. Tieni presente che occorrono diversi giorni prima che una nuova versione diventi disponibile in ogni regione.

Nota

La versione del motore 1.3.0.0 ha introdotto un nuovo formato per i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati. Di conseguenza, se si esegue l'aggiornamento da una versione del motore precedente alla 1.3.0.0 alla versione del motore 1.3.0.0 o successiva, è necessario creare nuovamente tutti i gruppi di parametri personalizzati e i gruppi di parametri del cluster personalizzati esistenti utilizzando la famiglia di gruppi di parametri neptune1.3. Le versioni precedenti utilizzavano la famiglia di gruppi di parametri neptune1 o neptune1.2 e tali gruppi di parametri non funzionano con la versione 1.3.0.0 e successive. Per ulteriori informazioni, consulta Gruppi di parametri di Amazon Neptune.

avvertimento

Abbiamo rilevato un problema nella cache del piano di query quando skip o viene utilizzato in una clausola interna e limit viene parametrizzato. WITH Per evitare questo problema, aggiungi il suggerimento alla query QUERY:PLANCACHE "disabled" quando invii una query che include una sottoclausola di salto e/o limite parametrizzata. In alternativa, è possibile codificare i valori nella query. Per ulteriori informazioni, consulta Attenuazione del problema relativo alla cache del piano di interrogazione.

Miglioramenti in questa versione del motore

Miglioramenti generali

• Support per la versione TLS 1.3, incluse le suite di crittografia TLS_AES_128_GCM_SHA256 e TLS_AES_256_GCM_SHA384. TLS 1.3 è un'opzione: TLS 1.2 è ancora il minimo.

Miglioramenti a Gremlin

• TinkerPop Aggiornamento 3.7.x

  • Fornisce un'ampia espansione del linguaggio Gremlin.

    • Nuovi passaggi per l'elaborazione di stringhe, elenchi e date.

    • Nuova sintassi per specificare la cardinalità all'interno del passaggio. mergeV()

    • union()ora può essere usato come fase iniziale.

    • Per ulteriori informazioni sulle modifiche nella versione 3.7.x, consulta la documentazione di TinkerPop aggiornamento.

  • Quando aggiornate i driver del linguaggio Gremlin del client per Java, tenete presente che le classi serializer hanno annullato alcune ridenominazioni. Dovrete aggiornare la denominazione dei pacchetti e delle classi nei file di configurazione e nel codice, se specificato.

• StrictTimeoutValidation(solo se abilitato tramite labmode StrictTimeoutValidation includendoStrictTimeoutValidation=enabled): quando il StrictTimeoutValidation parametro ha un valore dienabled, un valore di timeout per query specificato come opzione di richiesta o suggerimento di interrogazione non può superare il valore impostato globalmente nel gruppo di parametri. In tal caso, Nettuno lancerà un. InvalidParameterException Questa impostazione può essere confermata in una risposta sull'/statusendpoint quando il valore èdisabled, e nella versione 1.3.2.0 di Neptune il valore predefinito di questo parametro è. Disabled

Miglioramenti di openCypher

• Query a bassa latenza e miglioramento delle prestazioni di throughput: miglioramenti complessivi delle prestazioni per le query OpenCypher a bassa latenza. La nuova versione migliora anche la velocità effettiva di tali query. I miglioramenti sono più significativi quando vengono utilizzate interrogazioni con parametri.

• Support per Query Plan Cache: quando una query viene inviata a Neptune, la stringa di query viene analizzata, ottimizzata e trasformata in un piano di query, che viene quindi eseguito dal motore. Le applicazioni sono spesso supportate da modelli di query comuni istanziati con valori diversi. La cache del piano di query può ridurre la latenza complessiva memorizzando nella cache i piani di query ed evitando così l'analisi e l'ottimizzazione di tali schemi ripetuti.

• Miglioramento delle prestazioni per le query di aggregazione DISTINCT.

• Miglioramento delle prestazioni per i join che coinvolgono variabili nullable.

• Miglioramento delle prestazioni per le query che coinvolgono un predicato diverso da id (nodo/relazione).

• Supporto esteso per la funzionalità datetime (abilitato solo tramite la modalità lab includendo. DatetimeMillisecond DatetimeMillisecond=enabled Per ulteriori informazioni, consulta Supporto temporale nell'implementazione di Neptune OpenCypher (Neptune Analytics e Neptune Database 1.3.2.0 e versioni successive).

Difetti corretti in questa versione del motore

Miglioramenti generali

• Aggiornato il messaggio di errore NeptuneML durante la convalida dell'accesso ai bucket Graphlytics.

Correzioni Gremlin

• È stato corretto il problema delle informazioni sulle etichette mancanti nella traduzione delle interrogazioni DFE, per gli scenari in cui i passaggi che non contribuiscono al percorso contengono etichette. Per esempio:

  g.withSideEffect('Neptune#useDFE', true).
    V().
    has('name', 'marko').
    has("name", TextP.regex("mark.*")).as("p1").
    not(out().has("name", P.within("peter"))).
    out().as('p2').
    dedup('p1', 'p2')

• È stato corretto un NullPointerException bug nella traduzione delle interrogazioni DFE, che si verifica quando un'interrogazione viene eseguita in due frammenti DFE e il primo frammento è ottimizzato su un nodo insoddisfacente. Per esempio:

  g.withSideEffect('Neptune#useDFE', true).
    V().
    has('name', 'doesNotExists').
    has("name", TextP.regex("mark.*")).
    inject(1).
    V().
    out().
    has('name', 'vadas')

• Risolto un bug per cui Neptune poteva lanciare InternalFailureException un messaggio quando una query ValueTraversal conteneva il modulatore by () e il suo input era Map. Per esempio:

  g.V().
    hasLabel("person").
    project("age", "name").by("age").by("name").
    order().by("age")

Correzioni apportate a openCypher

• Operazioni UNWIND migliorate (ad esempio espansione di un elenco di valori in singoli valori) per aiutare a prevenire situazioni di esaurimento della memoria (OOM). Per esempio:

  MATCH (n)-->(m)
  WITH collect(m) AS list
  UNWIND list AS m
  RETURN m, list

• È stata corretta l'ottimizzazione degli ID personalizzati in caso di più operazioni MERGE in cui l'id viene iniettato tramite UNWIND. Per esempio:

  UNWIND [{nid: 'nid1', mid: 'mid1'}, {nid: 'nid2', mid: 'mid2'}] as ids
  MERGE (n:N {`~id`: ids.nid})
  MERGE (m:M {`~id`: ids.mid})

• Risolto il problema dell'esplosione della memoria durante la pianificazione di interrogazioni complesse con accesso alle proprietà e hop multipli con relazioni bidirezionali. Per esempio:

  MATCH (person1:person)-[:likes]->(res)-[:partOf]->(group)-[:knows]-(:entity {name: 'foo'}), 
         (person1)-[:knows]->(person2)-[:likes]-(res2), (comment)-[:presentIn]->(:Group {name: 'barGroup'}), 
         (person1)-[:commented]->(comment2:comment)-[:partOf]->(post:Post), (comment2)-[:presentIn]->(:Group {name: 'fooGroup'}), 
         (comment)-[:contains]->(info:Details)-[:CommentType]->(:CommentType {name: 'Positive'}),
         (comment2)-[:contains]->(info2:Details)-[:CommentType]->(:CommentType {name: 'Positive'}) 
  WHERE datetime('2020-01-01T00:00') <= person1.addedAfter <= datetime('2023-01-01T23:59') AND comment.approvedBy = comment2.approvedBy 
  MATCH (comment)-[:contains]->(info3:Details)-[:CommentType]->(:CommentType {name: 'Neutral'})
  RETURN person1, group.name, info1.value,  post.ranking, info3.value

• Query di aggregazione fisse con null come variabile group by. Per esempio:

  MATCH (n)
  RETURN null AS group, sum(n.num) AS result

Correzioni apportate a SPARQL

• È stato corretto il parser SPARQL per migliorare i tempi di analisi per query di grandi dimensioni come INSERT DATA contenenti molte triple e token di grandi dimensioni.

Attenuazione del problema relativo alla cache del piano di interrogazione

Per la versione 1.3.2.0, abbiamo rilevato un problema nella cache del piano di query quando skip o limit viene utilizzato in una WITH clausola interna e sono parametrizzati. Per esempio:

MATCH (n:Person)
WHERE n.age > $age
WITH n skip $skip LIMIT $limit 
RETURN n.name, n.age

parameters={"age": 21, "skip": 2, "limit": 3}

In questo caso, i valori dei parametri skip e limit del primo piano verranno applicati anche alle query successive, con risultati imprevisti.

Mitigazione

Per evitare questo problema, aggiungete il suggerimento alla query QUERY:PLANCACHE "disabled" quando inviate una query che include una sottoclausola parametrizzata di salto e/o limite. In alternativa, è possibile codificare i valori nella query.

Opzione 1: utilizzo del Query Hint per disabilitare la cache del piano:

Using QUERY:PLANCACHE "disabled"
MATCH (n:Person) WHERE n.age > $age
WITH n skip $skip LIMIT $limit
RETURN n.name, n.age

parameters={"age": 21, "skip": 2, "limit": 3}

Opzione 2: utilizzo di valori codificati per skip e limit:

MATCH (n:Person)
WHERE n.age > $age
WITH n skip 2 LIMIT 3
RETURN n.name, n.age

parameters={"age": 21}

Versioni di linguaggio di query supportate in questo rilascio

Prima di aggiornare un cluster DB alla versione 1.3.2.0, assicurati che il tuo progetto sia compatibile con queste versioni in linguaggio di query:

• Versione meno recente di Gremlin supportata: 3.6.2

• Versione più recente di Gremlin supportata: 3.7.1

• Versione openCypher: Neptune-9.0.20190305-1.0

• Versione di SPARQL: 1.1

Percorsi di aggiornamento alla versione 1.3.2.0 del motore

Puoi eseguire l'aggiornamento a questo rilascio dal rilascio del motore 1.2.0.0 o successivi.

Aggiornamento a questo rilascio

Se un cluster database utilizza una versione del motore dalla quale esiste un percorso di aggiornamento a questo rilascio, ora è idoneo all'aggiornamento. È possibile aggiornare qualsiasi cluster idoneo utilizzando le operazioni del cluster database sulla console o utilizzando SDK. Il seguente comando CLI aggiornerà immediatamente un cluster idoneo:

Per Linux, OS X o Unix:

aws neptune modify-db-cluster \
    --db-cluster-identifier (your-neptune-cluster) \
    --engine-version 1.3.2.0 \
    --allow-major-version-upgrade \
    --apply-immediately

Per Windows:

aws neptune modify-db-cluster ^
    --db-cluster-identifier (your-neptune-cluster) ^
    --engine-version 1.3.2.0 ^
    --allow-major-version-upgrade ^
    --apply-immediately

Invece di --apply-immediately, puoi specificare --no-apply-immediately. Per eseguire un aggiornamento della versione principale, il allow-major-version-upgrade parametro è obbligatorio. Assicurati inoltre di includere la versione del motore onde evitare che il tuo motore venga aggiornato a una versione diversa.

Se il cluster utilizza un gruppo di parametri del cluster personalizzato, assicurati di includere questo parametro per specificarlo:

    --db-cluster-parameter-group-name (name of the custom DB cluster parameter group)

Analogamente, se alcune istanze del cluster utilizzano un gruppo di parametri del database personalizzato, assicurati di includere questo parametro per specificarlo:

    --db-instance-parameter-group-name (name of the custom instance parameter group)

Eseguire sempre un test prima dell'aggiornamento

Quando viene rilasciata una nuova versione principale o secondaria del motore Neptune, testa sempre le applicazioni Neptune su di essa prima di procedere all'aggiornamento. Anche un aggiornamento secondario potrebbe introdurre nuove funzionalità o comportamenti che possono influire sul codice.

Inizia confrontando le pagine delle note di rilascio della versione corrente con quelle della versione di destinazione per valutare se verranno modificate le versioni del linguaggio di query o verranno introdotte altre modifiche che causano interruzioni.

Il modo migliore per testare una nuova versione prima di aggiornare il cluster database di produzione è clonare il cluster di produzione affinché il clone esegua la nuova versione del motore. È quindi possibile eseguire query sul clone senza influire sul cluster database di produzione.

Creare sempre uno snapshot manuale prima dell'aggiornamento

Prima di procedere a un aggiornamento, è consigliabile creare sempre uno snapshot manuale del cluster database. Uno snapshot automatico offre solo una protezione a breve termine, mentre uno snapshot manuale rimane disponibile fino a quando non lo elimini esplicitamente.

In alcuni casi Neptune crea automaticamente uno snapshot manuale come parte del processo di aggiornamento, ma non è consigliabile farvi affidamento ed è comunque opportuno creare sempre il proprio snapshot manuale.

Quando hai la certezza che non sarà necessario ripristinare lo stato precedente all'aggiornamento del cluster di database, puoi eliminare in modo esplicito lo snapshot manuale che hai creato, così come lo snapshot manuale eventualmente creato da Neptune. Se Neptune crea uno snapshot manuale, questo avrà un nome che inizia con preupgrade, seguito dal nome del cluster database, dalla versione del motore di origine, dalla versione del motore di destinazione e dalla data.

Nota

Se stai tentando di eseguire l'aggiornamento mentre è in corso un'azione in sospeso, potrebbe verificarsi un errore come il seguente:

   We're sorry, your request to modify DB cluster (cluster identifier) has failed.
   Cannot modify engine version because instance (instance identifier) is
   running on an old configuration. Apply any pending maintenance actions on the instance before
   proceeding with the upgrade.

Se riscontri questo errore, attendi il completamento dell'azione in sospeso o attiva immediatamente una finestra di manutenzione per completare l'aggiornamento precedente.

Per ulteriori informazioni sull'aggiornamento della versione del motore, consulta Gestione del cluster di database Amazon Neptune. In caso di domande o dubbi, il team di AWS supporto è disponibile nei forum della community e tramite AWS Premium Support.