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à.
OpenCypher segue un paradigma in cui le corrispondenze di tipi di dati numerici (ad esempio int, byte, short, long, ecc.) vengono eseguite secondo la semantica di promozione dei tipi. Ad esempio, quando si cercano tutte le proprietà con un valore di input 10 con tipo breve, nella semantica di promozione dei tipi, si troveranno anche le proprietà che hanno 10 come valore lungo. In alcuni casi, il type casting può comportare un sovraccarico e portare a piani di interrogazione meno efficienti di quanto potrebbero essere se non fosse stata eseguita alcuna conversione di tipi. In particolare, nei casi in cui i tipi di dati vengono utilizzati in modo coerente nei dati (ad esempio, se l'età di tutte le persone viene memorizzata come valore lungo), l'esecuzione di promozioni di tipo causa un sovraccarico senza influire sul risultato della query.
Per consentire l'ottimizzazione nei casi in cui è noto che i valori dei dati delle proprietà numeriche memorizzati nel database sono di tipo coerente, è possibile utilizzare un suggerimento di interrogazione chiamato assumeConsistentDataTypes
(con valoretrue/false
, per impostazione predefinita). false
Quando questo suggerimento di interrogazione viene fornito con un valore ditrue
, il motore presuppone che gli unici valori delle proprietà siano sempre lunghi o doppi e ignorerà la semantica di promozione dei tipi. I valori numerici specificati nella query sono considerati valori lunghi (per valori non a virgola mobile) e doppi (per valori a virgola mobile).
Se i dati utilizzano costantemente un unico tipo di dati (ad esempio tutte le età sono memorizzate comelong
), l'utilizzo del assumeConsistentDataTypes
hint può ottimizzare la query saltando i controlli di uguaglianza non necessari per diversi tipi numerici. Tuttavia, se i dati hanno tipi di dati non coerenti per la stessa proprietà, l'utilizzo del hint può causare la perdita di alcuni risultati, poiché la query corrisponderà solo al singolo tipo di dati assunto dal suggerimento.
# Database loaded with following openCypher CSV's # File 1 :ID,age:Int n1,20 n2,25 # File 2 :ID,age:Long n3,25 # Example (no hint) MATCH (n:Person) WHERE n.age >= 25 RETURN n # Result n2 n3 Returns all person whose age is >= 25 and the values >= 25 can be with any of these datatypes i.e. byte, short, int, long, double or float ----------------------------------------------------------------------------------- # Example (with hint present) USING QUERY:assumeConsistentDataTypes "true" MATCH (n:Person) WHERE n.age >= 25 RETURN n # Result n3 Returns only "n3" and not "n2". The reason is that even though the numerical value matches (25), the datatype is "int" and is considered a non-match.
La differenza può essere convalidata anche tramite la spiegazione.
Senza la spiegazione:
# Query MATCH (n) WHERE n.age = 20 RETURN n # Explain Snippet ╔═════╤══════════╤══════════╤══════════════════════════════╤═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╤════════╤════════════╤══════════════╤═════════╤══════════════╗ ║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║ ╠═════╪══════════╪══════════╪══════════════════════════════╪═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╪════════╪════════════╪══════════════╪═════════╪══════════════╣ ║ 0 │ 1 │ - │ DFEPipelineScan (DFX) │ pattern=Node(?n) with property 'age' as ?n_age2 and label 'ALL' │ - │ 0 │ 1 │ 0.00 │ 0.10 ║ ║ │ │ │ │ inlineFilters=[(?n_age2 IN ["20"^^xsd:byte, "20"^^xsd:int, "20"^^xsd:long, "20"^^xsd:short, "20.0"^^xsd:double, "20.0"^^xsd:float])] │ │ │ │ │ ║ ║ │ │ │ │ patternEstimate=1 │ │ │ │ │ ║ ╟─────┼──────────┼──────────┼──────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼────────────┼──────────────┼─────────┼──────────────╢ # The inFilters field contains all numeric types
Con il suggerimento:
# Query MATCH (n) WHERE n.age = 20 RETURN n # Explain Snippet ╔═════╤══════════╤══════════╤══════════════════════════════╤═════════════════════════════════════════════════════════════════════════════════╤════════╤════════════╤══════════════╤═════════╤══════════════╗ ║ ID │ Out #1 │ Out #2 │ Name │ Arguments │ Mode │ Units In │ Units Out │ Ratio │ Time (ms) ║ ╠═════╪══════════╪══════════╪══════════════════════════════╪═════════════════════════════════════════════════════════════════════════════════╪════════╪════════════╪══════════════╪═════════╪══════════════╣ ║ 0 │ 1 │ - │ DFEPipelineScan (DFX) │ pattern=Node(?n) with property 'age' as ?n_age2 and label 'ALL' │ - │ 0 │ 1 │ 0.00 │ 0.07 ║ ║ │ │ │ │ inlineFilters=[(?n_age2 IN ["20"^^xsd:long])] │ │ │ │ │ ║ ║ │ │ │ │ patternEstimate=1 │ │ │ │ │ ║ ╟─────┼──────────┼──────────┼──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────┼────────┼────────────┼──────────────┼─────────┼──────────────╢ # The inFilters field only contains long datatype