Questo documento descrive le best practice per l'API Search. Utilizziamo virgolette singole ('') per delimitare le stringhe di query. In questo modo una query che contiene
frasi composte da più parole racchiuse tra virgolette doppie può essere delimitata senza confusione:
'field:"some text" some-value'
.
Chiamate in batch Index.put() e Index.delete()
Puoi passare fino a 200 documenti alla volta quando li aggiungi o li elimini da un indice. È molto più efficiente che gestirle una alla volta.
Utilizza il ranking dei documenti per preordinare i documenti
Per impostazione predefinita, la ricerca restituisce i risultati in base al ranking decrescente. Sempre per impostazione predefinita, l'API di ricerca imposta la posizione di ciascun documento in secondi dal 1° gennaio 2011. In questo modo vengono restituiti per primi i documenti più recenti. Tuttavia, se non hai bisogno che i documenti vengano ordinati in base al momento in cui sono stati aggiunti, puoi utilizzare il ranking per altri scopi. Supponiamo che tu abbia un'applicazione immobiliare. Ciò che i clienti cercano di più è l'ordinamento per prezzo. Per un ordinamento predefinito efficiente, potresti impostare il ranking sul prezzo autopromozionale.
Se hai bisogno di più ordinamenti, ad esempio con prezzo dal più basso al più alto e prezzo dal più basso al più basso, puoi creare un indice separato per ciascun ordine. Un indice avrebbe un ranking = prezzo e l'altro = prezzo MAXINT (poiché il ranking deve essere positivo).
L'utilizzo del ranking come chiave di ordinamento migliorerà il rendimento della ricerca. Per specificare altre chiavi di ordinamento, devi utilizzare le opzioni di ordinamento, che limitano il numero di risultati di ricerca a 10.000 documenti. In questo caso, l'ordinamento determinato dal ranking determinerà quali documenti saranno inclusi nell'ordinamento. Per saperne di più, consulta le opzioni di ordinamento.
Utilizzare i campi Atom per i dati booleani
L'archiviazione di dati booleani in campi numerici è molto inefficiente. Usa i campi Atom e assegna le tue costanti preferite (Vero/Falso, sì/no, 0/1).
Trasforma le parole chiave escluse in positive
Supponiamo che tu utilizzi un termine speciale per identificare i ristoranti la cui cucina non è definita. Per escludere questi ristoranti, puoi utilizzare 'NOT cuisine:undefined'
come query. Tuttavia, la valutazione è più costosa (sia per le operazioni fatturabili che per i tempi di calcolo) che avere il contrario, trovare ristoranti di cui si conoscono la cucina. Invece di avere un solo campo, la cucina, puoi utilizzarne due, cuisine
e cuisine_known
, il secondo è un campo di atomi. Per i ristoranti per cui è definita la cucina, imposti il primo campo sulla cucina effettiva e il secondo su "yes"
. Per i ristoranti di cui non conosci la cucina, puoi impostare la cucina su ""
(una stringa vuota) e cuisine_known
su "no"
. Ora, per trovare ristoranti di cui è nota la cucina, esegui una query 'cuisine_known:yes'
, che è molto più veloce della negazione.
Trasformare le disgiunzioni in congiunzioni
La disgiunzione "OR" è un'operazione costosa sia per le operazioni fatturabili che per i tempi di calcolo. Supponiamo che tu voglia cercare 'cuisine:Japanese OR cuisine:Korean'
. Un'alternativa è indicizzare i documenti con categorie più generali di tipi di cucina. In questo caso, la query può essere semplificata in 'cuisine:Asian'
.
Elimina le tautologie dalle query
Supponiamo che tu voglia trovare tutti i ristoranti a Toronto. Supponendo che i tuoi documenti abbiano un solo campo denominato "city", se utilizzi la query 'city:toronto AND NOT city:montreal'
ottieni gli stessi risultati di 'city:toronto'
; infatti, se la città è impostata su "toronto"
, non può essere impostata su "montreal"
. La seconda query viene eseguita molto più velocemente poiché interessa un solo termine. La prima query esegue tre passaggi: in primo luogo, trova un elenco di documenti in cui la città è impostata su "toronto", poi trova un elenco di tutte le città in cui questa non è impostata su "montreal" e infine calcola l'intersezione dei due elenchi.
Restringi l'intervallo prima di ordinare
Supponiamo che la tua applicazione archivi informazioni sui ristoranti di tutto il mondo e voglia mostrare i ristoranti più vicini all'utente corrente. Un modo per farlo è ordinare i documenti corrispondenti in base alla distanza dalla posizione dell'utente. Tuttavia, se hai 1.000.000 di ristoranti, l'esecuzione di una query come 'cuisine:japanese'
con l'espressione di ordinamento distanza(geopoint(x, y), ristorante_loc) richiederà molto tempo. È consigliabile aggiungere filtri a una query in modo da iniziare con un insieme più rilevante di documenti selezionati da ordinare. Una soluzione consiste nel creare categorie geografiche, ad esempio paese, provincia e città, che puoi dedurre dalla località dell'utente. La query diventa 'cuisine:japanese AND city:<user-city>'
. È molto probabile che non avrai più bisogno di ordinare 1.000.000 di documenti.
Utilizza categorie limitate per evitare o ridurre al minimo l'ordinamento
Se utilizzi il ranking per ordinare i ristoranti per prezzo, potresti creare un campo price_range
contenente le categorie di prezzo: price_0_10
, price_11_20
, price_21_30
, price_31_40
, price_41_lots
. Successivamente, potresti trovare tutti i ristoranti che costano tra i 21 $e i 40 $senza ordinamento utilizzando la query 'price_range:price_21_30 OR price_range:price_31_40'
. In molti casi le categorie appropriate non sono così chiare, ma con questa tecnica puoi rifiutare un numero elevato di documenti prima di limitare la ricerca con query costose come '... AND price>25 AND price<35'
.
Non segnare partite a meno che non sia necessario
Il punteggio viene utilizzato per indicare il livello di corrispondenza di un determinato documento con una query. Tuttavia, a meno che tu non intenda ordinare i dati per punteggio, non richiedere il punteggio. Rallenerà solo la tua ricerca.