Questo documento descrive le best practice per l'API Search. Utilizziamo le virgolette singole (") per delimitare le stringhe di query. In questo modo, una query contenente frasi di più parole racchiuse tra virgolette doppie può essere delimitata senza confusione:'field:"some text" some-value'.
Esegui in batch le chiamate Index.put() e Index.delete()
Puoi passare fino a 200 documenti alla volta quando li aggiungi o li elimini da un indice. Questo è molto più efficiente che gestirli uno alla volta.
Utilizzare il ranking dei documenti per preordinarli
Per impostazione predefinita, la ricerca restituisce i risultati in ordine decrescente. Sempre per impostazione predefinita, l'API Search imposta il ranking di ogni documento in secondi dal 1° gennaio 2011. In questo modo, i documenti più recenti vengono restituiti per primi. Tuttavia, se non è necessario ordinare i documenti 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 vogliono di più i clienti è l'ordinamento in base al prezzo. Per un'efficiente ordinamento predefinito, puoi impostare il ranking sul prezzo della casa.
Se hai bisogno di più ordini di ordinamento, ad esempio dal prezzo più basso al più alto e dal prezzo più alto al più basso, puoi creare un indice separato per ogni ordine. Un indice avrà il ranking = prezzo e l'altro ranking = MAXINT-prezzo (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à i documenti da includere nell'ordinamento. Per saperne di più, consulta le opzioni di ordinamento.
Utilizzare i campi atom per i dati booleani
L'archiviazione dei dati booleani nei campi numerici è molto inefficiente. Utilizza invece i campi atom e assegna le costanti che preferisci (True/False, yes/no, 0/1).
Trasformare i lati negativi in positivi
Supponi di avere un termine speciale per identificare i ristoranti la cui cucina non è definita. Se vuoi 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) rispetto all'avere il contrario, ovvero trovare ristoranti la cui cucina è nota. Anziché avere un campo, cucina, puoi utilizzarne due, cuisine e cuisine_known, quest'ultimo essendo un campo atomo. Per i ristoranti per cui viene definita una cucina, devi impostare il primo campo sulla cucina effettiva e il secondo su "yes". Per i ristoranti di cui non conosci la cucina, imposta cuisine su "" (una stringa vuota) e cuisine_known su "no". Ora per trovare i ristoranti di cui è nota la cucina, puoi eseguire una query 'cuisine_known:yes', che è molto più veloce della negazione.
Trasforma le disgiunzioni in congiunzioni
L'"OR" la disgiunzione è un'operazione costosa sia per le operazioni fatturabili sia per i tempi di calcolo. Supponiamo che tu voglia cercare 'cuisine:Japanese OR cuisine:Korean'. Un'alternativa è indicizzare i documenti con categorie di cucina più generali. In questo caso, la query può essere semplificata in 'cuisine:Asian'.
Elimina le tautologie dalle query
Supponiamo che tu voglia trovare tutti i ristoranti di Toronto. Supponendo che i documenti abbiano un solo campo denominato "città", se utilizzi la query 'city:toronto AND NOT city:montreal' ottieni gli stessi risultati di 'city:toronto', perché se la città è impostata su "toronto" non può essere impostata su "montreal". La seconda query viene eseguita molto più velocemente poiché riguarda un solo termine. La prima query esegue tre passaggi: innanzitutto, trova un elenco di documenti in cui la città è impostata su "Toronto", poi trova un elenco di tutte le città in cui la città non è impostata su "Montreal" e infine calcola l'intersezione dei due elenchi.
Restringi l'intervallo prima di ordinare
Supponiamo che la tua applicazione memorizzi informazioni su ristoranti di tutto il mondo e che tu 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 distance(geopoint(x, y), restaurant_loc) richiederà molto tempo. È una buona idea aggiungere filtri a una query in modo da iniziare con un insieme più rilevante di documenti selezionati da ordinare. Una soluzione è creare categorie geografiche, come paese, stato e città. Potresti dedurre la città e lo stato dalla posizione 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 ristrette per evitare o ridurre al minimo l'ordinamento
Se utilizzi il ranking per ordinare i ristoranti in base al prezzo, potresti creare un campo price_range contenente le categorie di prezzo: price_0_10, price_11_20, price_21_30, price_31_40 e price_41_lots. Puoi quindi trovare tutti i ristoranti con un prezzo compreso tra 21 e 40 $ senza alcuna organizzazione 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 gran numero di documenti prima di vagliare la ricerca con query costose come '... AND price>25 AND price<35'.
Non assegnare un punteggio alle corrispondenze, a meno che non sia necessario
Il punteggio viene utilizzato per indicare la corrispondenza di un determinato documento a una query. Tuttavia, se non intendi ordinare i risultati in base al punteggio, non richiederlo. Ne rallenterà solo la ricerca.