Confusioni sulla struttura di query jems dsl di Elasticsearch

Question

In molti punti della documentazione di grammatica delle query dlsl elasticsearch, le query di wrapper json vengono ignorate nelle spiegazioni probabilmente per ridurre la dimensione della documentazione. Ma è stato confuso mentre navigavo nella documentazione. Quali sono ufficialmente le regole per cosa può o dovrebbe andare dove in una query JSON?In altre parole, sto cercando di trovare lo standard o il pattern comune tra tutte le query elastiche perché ho bisogno di creare una API interna per interrogare l'elasticità. Esiste un modello che contiene tutti i componenti grammaticali "query': {} all'interno di uno "bool":{} o uno filter ecc. In cui posso semplicemente compilare le parti pertinenti e continua a funzionare?

Answer 1

Trovo anche la struttura DSL di Elastic che confonde, ma dopo aver eseguito centinaia di query ci si abitua.

Ecco alcuni esempi (completi) di diversi tipi di query, si spera che questo chiarisca alcune domande, si senta libero di aggiungere scenari in un commento e aggiungerò altri esempi.

Questo è come un query standard assomiglia:

{ 
    "query": { 
     "bool": { 
      "must": { 
       "match": { 
        "message": "abcd" 
       } 
      } 
     } 
    } 
} 

Tuttavia, questo è come una query filtrata sembra, si noterà un cambiamento nella struttura durante il filtraggio elasticsearch:

{ 
    "query": { 
     "filtered": { 
      "filter": { 
       "term": { 
        "message": "abcd" 
       } 
      } 
     } 
    } 
} 

(Read more about the difference between Filters and Queries)

Ecco come appare una query con filtri e query:

{ 
    "query": { 
     "filtered": { 
      "filter": { 
       "term": { 
        "message": "abcd" 
       } 
      }, 
      "query": { 
       "bool": { 
        "must": { 
         "match": { 
          "message2": "bbbb" 
         } 
        } 
       } 
      } 
     } 
    } 
} 

Ecco come si esegue un filtro con più condizioni:

{ 
    "query": { 
     "filtered": { 
      "filter": { 
       "and": [ 
        { 
         "term": { 
          "message": "abcd" 
         } 
        }, 
        { 
         "term": { 
          "message2": "abcdd" 
         } 
        } 
       ] 
      } 
     } 
    } 
} 

E un filtro più complesso:

{ 
    "query": { 
     "filtered": { 
      "filter": { 
       "and": [ 
        { 
         "term": { 
          "message": "abcd" 
         } 
        }, 
        { 
         "term": { 
          "message2": "abcdd" 
         } 
        }, 
        { 
         "or": [ 
          { 
           "term": { 
            "message3": "abcddx" 
           } 
          }, 
          { 
           "term": { 
            "message4": "abcdd2" 
           } 
          } 
         ] 
        } 
       ] 
      } 
     } 
    } 
} 

domanda semplice con aggregazioni:

{ 
    "query": { 
     "filtered": { 
      "filter": { 
       "term": { 
        "message": "abcd" 
       } 
      } 
     } 
    }, 
    "aggs": { 
     "any_name_will_work_here": { 
      "max": { 
       "field": "metric1" 
      } 
     } 
    } 
} 

A query_string interrogazione :

{ 
    "query": { 
     "query_string": { 
      "default_field": "message", 
      "query": "this AND that" 
     } 
    } 
} 

Alcune altre cose da considerare quando si utilizza la DSL:

1. È possibile aggiungere un parametro size al livello superiore (sopra la query) che determinerà la quantità di risultati da restituire. Se vuoi contare JUST con i documenti, puoi usare "size": 0 che non otterrà alcun risultato, solo i metadati.
2. Tuttavia, quando si utilizza aggs il parametro di dimensione ha una torsione, impostando "size": 0 all'interno del campo aggs dirà ES per ottenere TUTTI secchi aggregazione
3. La struttura DSL ha le sue eccezioni, nei miei esempi che ho di solito utilizzati terms, ma range per esempio ha un po 'di una struttura diversa.