2014-05-25 18 views
5

Sto eseguendo un proof of concept utilizzando App Engine e l'API di ricerca integrata. Stiamo testando l'API di ricerca supponendo che fornisca il ridimensionamento lineare come nel caso di altri prodotti e servizi che sono associati a App Engine.API di ricerca su Google App Engine

  • Specifiche: ca. 8 milioni di documenti in un unico indice
  • Tipo di query: Query complesse, abbiamo bisogno di query spaziali basate su aree quadrate, non distanza (!). Tutte le query includono 2 intervalli basati sulla latitudine e sulla longitudine .
  • Dimensioni pagina: tra 16 e 250.
  • Precisione (conteggio dei risultati) impostato su 100 in tutti i casi di test.

La nostra prestazione target (latenza) è nell'intervallo dei 100 di millisecondi.

Stiamo testando le prestazioni dell'API di ricerca che eseguono diverse richieste simultanee. I risultati dei test sono ora misurati a circa 25 richieste simultanee, ma questo numero dovrebbe aumentare significativamente. Tuttavia, se l'API di ricerca è correttamente scalabile, questo dovrebbe essere privo di significato.

Sto misurando il tempo necessario all'API di ricerca per elaborare una chiamata a Index.search (Query). Quello che sto misurando è il seguente:

  1. Il tempo medio di risposta del metodo di ricerca è di circa 8000 ms. Non ci sono casi in cui il metodo ritorna significativamente più veloce o più lento di quello. Tuttavia, l'uso di un indice con 10 documenti comporta misurazioni della latenza di circa 300 ms (!!!). Questa potrebbe essere un'indicazione che l'API di ricerca non è affatto scalabile.
  2. Le dimensioni della pagina non sembrano presentare differenze significative. Forse a dimensioni di pagina di 10.000 o superiore lo farà, ma questo non fa parte dei nostri test.
  3. L'aggiunta di un criterio (uguaglianza) sembra velocizzare la ricerca in modo significativo. Fino a circa il 40% di miglioramento. Questo sembra un bel miglioramento, ma 4 secondi sono ancora un'eternità.

Domande:

  1. Qual è la latenza atteso (miglior scenario possibile/configurazione) che l'API di ricerca in grado di fornire?
  2. Quali parametri influenzano la latenza inclusa la configurazione del motore dell'app.
  3. Il numero di documenti in un indice influenza la latenza?
  4. È una ricerca basata su query di intervallo 2 più lenta di una ricerca basata solo sui filtri di uguaglianza? (perché potremmo pre-elaborare i dati e aggiungere i dati "indice" a ciascun documento).
  5. L'API di ricerca è davvero scalabile?
+0

la domanda è ancora aperta? – pankajanand18

+0

@ pankajanand18 No, vedi risposta sotto. Grazie! – moin

risposta

2

La nostra applicazione per questo era di tracciare un numero di marcatori su una mappa utilizzando un server di tessere. Tuttavia, il server tile esegue molte query (ad esempio "tile") in parallelo, quasi 30 per utente/vista. Per rendere le cose difficili, non siamo stati in grado di risolvere questo problema utilizzando mappe pre-aggregate perché abbiamo troppi parametri/dimensioni di cui occuparci (se questo è il tuo caso, prova con Google Maps Engine).

Quindi, ci siamo ritrovati con un'istanza CloudSQL impostata sul livello più alto per max. prestazione. Un altro motivo per utilizzare un database relazionale è che le prestazioni dell'indice sono più sintonizzabili rispetto all'API di ricerca o al BigQuery.

per rispondere alle domande, questo è ciò che abbiamo trovato:

  1. La latenza dipende dalla dimensione dell'indice. A volumi inferiori per indice, la latenza sembra ragionevole. A volumi molto più alti questo può diventare un problema. Ma per la ricerca di testo questo è probabilmente ok nella maggior parte dei casi.
  2. Non abbiamo testato a volumi inferiori ma a circa 8 milioni di documenti, la latenza si trova tra 5000 - 8000 ms. per query. Non abbiamo trovato alcun parametro che diminuisse la latenza, abbiamo trovato parametri che aumentavano la latenza.
  3. Sì.
  4. Non abbiamo provato questo.
  5. Sì.
+0

Scrivere interessante. Quindi stai dicendo che più documenti hai nell'API di ricerca, maggiore sarà la latenza se la tua query rimane invariata? per esempio. interrogando gli ultimi 100 documenti. Se è così, questo non sembra per nulla scalabile .. Dal momento che i tuoi documenti crescono, anche la latenza cresce e cresce. Correggimi se ho frainteso. – Micro

+0

Non sono sicuro che questi risultati del test siano ancora validi. Google sembra migliorare i propri servizi ... detto questo, a quei tempi il servizio sembrava funzionare bene fino a un numero ragionevolmente elevato di documenti. Tuttavia, QPS non sembra influenzare i tempi di risposta, quindi sarebbe ancora scalabile in tal senso. – moin