Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Come vengono elaborate le query Gremlin in Neptune

In Amazon Neptune, attraversamenti più complessi possono essere rappresentati da una serie di modelli che creano una relazione basata sulla definizione di variabili denominate che possono essere condivise tra modelli per creare join. Questo viene mostrato nell'esempio seguente.

Domanda: cos'è il quartiere a due hop del vertice v1?

  Gremlin code:      g.V(‘v1’).out('knows').out('knows').path()
  Pattern:           (?1=<v1>, <knows>, ?2, ?) X Pattern(?2, <knows>, ?3, ?)

  The pattern produces a three-column relation (?1, ?2, ?3) like this:
                     ?1     ?2     ?3
                     ================
                     v1     v2     v3
                     v1     v2     v4
                     v1     v5     v6

Condividendo la variabile ?2 tra i due modelli (nella posizione O del primo modello e nella posizione S del secondo modello), si crea un join dai primi quartieri hop ai secondi quartieri hop. Ogni soluzione Neptune ha associazioni per le tre variabili denominate, che possono essere utilizzate per ricreare TinkerPopun Traverser (incluse le informazioni sul percorso).

Il primo passo nell'elaborazione delle query di Gremlin consiste nell'analizzare la query in un oggetto Traversal, composto da una TinkerPop serie di passaggi. TinkerPop Questi passaggi, che fanno parte del TinkerPop progetto open source Apache, sono sia gli operatori logici che fisici che compongono un attraversamento Gremlin nell'implementazione di riferimento. Entrambi vengono utilizzati per rappresentare il modello della query. Si tratta di operatori eseguibili che possono generare soluzioni in base alla semantica dell'operatore che rappresentano. Ad esempio, .V() è sia rappresentato che eseguito da. TinkerPop GraphStep

Poiché questi off-the-shelf TinkerPop passaggi sono eseguibili, un TinkerPop Traversal di questo tipo può eseguire qualsiasi interrogazione Gremlin e produrre la risposta corretta. Tuttavia, se eseguiti su un grafico di grandi dimensioni, TinkerPop i passaggi a volte possono essere molto inefficienti e lenti. Anziché usarle, Neptune cerca di convertire l'attraversamento in un formato dichiarativo composto da gruppi di modelli, come descritto in precedenza.

Neptune non supporta attualmente tutti gli operatori Gremlin (passaggi) nel motore di query nativo. Pertanto, tenta di comprimere il maggior numero di fasi possibili in una singola NeptuneGraphQueryStep, che contiene il piano di query logico dichiarativo per tutte le fasi che sono state convertite. Idealmente, tutte le fasi vengono convertite. Ma quando viene rilevato un passaggio che non può essere convertito, Neptune interrompe l'esecuzione nativa e rinvia tutta l'esecuzione delle query da quel momento in avanti ai passaggi. TinkerPop Non tenta di intrufolarsi nell'esecuzione nativa.

Dopo che i passaggi vengono tradotte in un piano di query logico, Neptune esegue una serie di ottimizzatori di query che riscrivono il piano di query in base all'analisi statica e alle cardinalità stimate. Questi ottimizzatori eseguono operazioni come riordinare operatori in base a conteggi di intervalli, eliminare operatori superflui o ridondanti, riordinare i filtri, eseguire il push di operatori in gruppi diversi e così via.

Dopo aver prodotto un piano di query ottimizzato, Neptune crea una pipeline di operatori fisici che eseguono il lavoro di esecuzione della query. Ciò include la lettura dei dati dagli indici di dichiarazione, l'esecuzione di join di vari tipi, il filtraggio, l'ordinamento e così via. La pipeline produce un flusso di soluzioni che viene poi riconvertito in un flusso di oggetti Traverser. TinkerPop

Serializzazione dei risultati delle query

Amazon Neptune attualmente si affida ai serializzatori TinkerPop dei messaggi di risposta per convertire i risultati delle query TinkerPop (Traversers) in dati serializzati da inviare via cavo al client. Questi formati di serializzazione tendono a essere piuttosto dettagliati.

Ad esempio, per serializzare il risultato di una query del vertice quale g.V().limit(1), il motore di query Neptune deve eseguire una singola ricerca per produrre il risultato della query. Tuttavia, il serializzatore GraphSON eseguirà un numero elevato di ricerche aggiuntive per creare un pacchetto del vertice nel formato di serializzazione. Deve eseguire una ricerca per ottenere l'etichetta, una per ottenere le chiavi di proprietà e una ricerca per chiave di proprietà per il vertice per ottenere tutti i valori per ogni chiave.

Alcuni dei formati di serializzazione sono più efficienti, ma tutti richiedono ricerche aggiuntive. Inoltre, i TinkerPop serializzatori non cercano di evitare ricerche duplicate, spesso con il risultato che molte ricerche vengono ripetute inutilmente.

Questo rende molto importante scrivere le query in modo da richiedere specificamente solo le informazioni necessarie. Ad esempio, g.V().limit(1).id() restituisce solo l'ID del vertice ed elimina tutte le ricerche di serializzatore aggiuntive. Gremlin profile API in Neptune consente di vedere quante chiamate di ricerca vengono effettuate durante l'esecuzione della query e durante la serializzazione.