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 base al ranking decrescente. Inoltre, per impostazione predefinita, l'API Search imposta il ranking di ogni documento su secondi dal 1° gennaio 2011. Di conseguenza, 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. La funzionalità più richiesta dai clienti è l'ordinamento per 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 scoprire di più, consulta le opzioni di ordinamento.
Utilizzare i campi atom per i dati booleani
L'archiviazione di 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 lati positivi
Supponiamo 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, questa operazione è più costosa da valutare (sia in termini di operazioni fatturabili che di tempo di calcolo) rispetto all'approccio opposto, 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 i quali è definita la cucina, imposta 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
La disgiunzione "OR" è un'operazione costosa sia per le operazioni fatturabili sia per il tempo 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 tuoi 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 perché coinvolge 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 dell'ordinamento
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. È buona norma 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 dovrai più 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, puoi 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. 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 numero elevato di documenti prima di restringere 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 il grado di corrispondenza di un determinato documento a una query. Tuttavia, se non intendi ordinare i risultati in base al punteggio, non richiederlo. Ne rallenta solo la ricerca.