2012-06-08 1 views
19

Finora, ho utilizzato la ricerca di testo completo di App Engine per cercare le entità esistenti nel mio archivio dati. Ciò comporta la creazione di almeno uno Document per entità e il collegamento dei due insieme in qualche modo. E ogni volta che cambio l'entità, devo cambiare il corrispondente Documents.Quando non dovrei utilizzare l'API di ricerca full-text di App Engine?

La mia domanda è: perché non archiviare tutti i miei dati in Documents e dimenticare le entità di Datastore? L'API di ricerca supporta uno query language molto più ricco che può gestire più filtri di disuguaglianza e operatori booleani, a differenza del datastore.

Mi manca qualcosa sul design dell'API di ricerca che preclude l'utilizzo per sostituire completamente il Datastore?

risposta

7

Secondo il Java docs

Tuttavia, una ricerca indice può trovare non più di 10.000 corrispondenti documenti. Il Datastore dell'App Engine può essere più appropriato per le applicazioni che devono recuperare set di risultati molto grandi.

Anche se non lo vedo come un caso di uso comune.

Più realisticamente, ottenere entità per chiave sarà molto più economico con il Datastore (presumibilmente più veloce pure). Con l'API di ricerca, puoi utilizzare Index.get() per trovare un documento per ID o duplicare l'ID memorizzandolo in un campo e cercando su quel campo.

Ecco la ripartizione dei costi:

- Index.get():  $0.10/10,000 or 0.00001 per get 
- Index.search(): $0.13/10,000 or 0.000013 per get 
- Datastore get(): $0.06/100,000 or 0.0000006 per get 

Come si può vedere, un get datastore è molto più conveniente rispetto alle opzioni di ricerca API (16x in meno rispetto Index.get()).

Se i dati sono strutturati in modo tale da utilizzare molti richiami diretti e poche ricerche complesse, il Datastore sarà un chiaro vincitore in termini di costi.

Nota: non ho incluso il costo aggiuntivo per la memorizzazione di dati duplicati con il metodo Index.search(), poiché ciò dipende dal numero di entità memorizzate.

+0

Grazie, questo è molto utile! e una buona spiegazione del motivo per cui la ricerca potrebbe non essere una sostituzione del Datastore drop-in appropriata. –

+0

@pixel dove hai visto questa limitazione di 1000 chiamate API al giorno? Da quello che ho capito, questo è solo il limite della quota libera. – AsafK

+0

@AsafK Il documento I collegato menziona "Queste chiamate sono soggette a un limite giornaliero di 1.000 operazioni al giorno". ma penso che tu abbia ragione che questo si applica solo alla quota libera e questa frase è fuorviante, dato che il prezzo è in incrementi di 10k. Ho modificato la mia risposta per rimuovere quel commento. –

3

Non ti:

  1. perdere tutti i benefici di memcache quote

  2. faccia inferiore. "ci aspettiamo che la nostra quota gratuita coprirà circa 1.000 ricerche al giorno una volta che la funzionalità si sarà perfezionata da sperimentale" Non riesco a vedere il numero di letture ottenute ma credo che sia più alto per il datastore. Ho guardato a https://developers.google.com/appengine/docs/quotas#Resources

    Inoltre, per un aggiornamento di entità, ci viene addebitato in modo diverso tramite aggiornamento o nuova put. Sembra che gli indici non siano aggiornati ma piuttosto aggiunti come un nuovo documento (è quello che sto facendo comunque). Non avendo i dettagli del listino prezzi, è difficile sapere esattamente, ma forse l'aggiornamento di uno o due valori indicizzati su un'entità sarebbe più economico rispetto alla creazione di un nuovo intero indice. Dipenderà dai tuoi dati, credo.

    Infine, la dimensione indice totale per gli indici è ora a 250 M mentre i dati sono limitati a 1 GB. Il datastore è più grande di allora e non ci sono ancora parole sui costi di pricing aggiuntivi per l'indice.

  3. necessario elaborare un piano di backup. Non so comunque ora di fare il backup o ripristinare l'indice se è stato danneggiato. Avere i dati in entità significa che l'indice di ricerca potrebbe essere ricreato. È ora possibile eseguire il backup con la console di amministrazione per il datastore.

+0

Grazie per la risposta. Le mie risposte: 1) Memcache è un sistema completamente separato non correlato al datastore o alla ricerca. 2) Le attuali quote limitate sono temporanee. È possibile aggiornare + cancellare documenti (proprio come le entità). 3) Buon punto sul backup automatico; Mi aspetterei che anch'essi supportino il backup dei documenti anche se, alla fine. –

5

Basta inserire i dati in entrambe - la memoria è a buon mercato e, a seconda di quanto scrive la vostra applicazione non potrebbe essere a buon mercato per fare gli aggiornamenti pure. Per domande semplici e ottenere singole entità per chiave - usa memcache e datastore. Per le query complesse utilizzare la ricerca API. Dovrai fare il tradeoff una volta che i prezzi saranno annunciati.

+0

Questo è ciò che stiamo facendo oggi, ma sarebbe comunque utile sapere di più sulla progettazione e l'intento dell'API di ricerca. –

4

in questo momento indicizzando un'entità nel searchdoc ogni volta che lo metto e indico anche una versione serializzata dell'entità.
è in realtà molto più più veloce ricerca di documenti sulla api di ricerca ed estrazione del campo serializzato di ottenere la stessa quantità di entità dal datastore.

+0

È interessante sapere che l'API di ricerca è molto più veloce - ci sono motivi per aspettarsi che sia più veloce? O forse perché è ancora in prova limitata e non molti utenti lo stanno ancora martellando? –

+0

Puoi precisare come stai misurando più velocemente? Chiaramente, se si deserializza l'entità e la ricerca esistente, sarà più veloce di un get datastore. Ma misurate l'aumento della latenza delle ricerche con documenti più grassi? – aloo

+2

Non ho numeri in questo momento, ma il recupero approssimativo di 1000 entità con una proprietà stringa richiede solo circa 2 secondi. cercare la stessa quantità di entità (e restituire solo il campo serializzato) e caricare il json serializzato per tutti quei documenti richiede meno di 0,5 secondi su una F1. – aschmid00

1

Oltre ai costi delle prestazioni per l'interrogazione di grandi insiemi di dati, il datastore ha anche il vantaggio di consentire dati fortemente coerenti. Dai uno sguardo a this link per ulteriori informazioni su dati coerenti coerenti e coerenti con quelli finali.

Si deve presupporre che i documenti memorizzati negli indici delle API di ricerca siano consistenti alla fine.