Inclusione dei documenti nell'emit rispetto a include_docs = true in CouchDB

Question

Ho ricevuto una menzione da qualche parte che facendo un emit(key, doc) aumenterà la quantità di tempo che un indice impiega per costruire (o qualcosa in tal senso).

C'è qualche merito, e c'è qualche ragione per non fare sempre solo emit(key, null) e poi include_docs = true?

Answer 1

Sì, aumenterà la dimensione dell'indice, perché CouchDB copia effettivamente l'intero documento in questi casi. Per i casi in cui è possibile, utilizzare include_docs=true.

Esiste comunque una condizione di competizione da tenere presente quando si usa ciò che è menzionato nel wiki. È possibile, durante il tempo che intercorre tra la lettura dei dati della vista e il recupero del documento, che tale documento sia cambiato (o che sia stato cancellato, nel qual caso _deleted sarà true). Questo è documentato here in "Opzioni di interrogazione".

Answer 2

Questo è un classico compromesso tempo/spazio.

L'emissione di dati di documento nel proprio indice aumenterà le dimensioni del file di indice sul disco perché CouchDB include i dati emessi direttamente nel file di indice. Tuttavia, ciò significa che, quando si interrogano i dati, CouchDB può semplicemente trasmettere il contenuto direttamente dal file indice sul disco. Questo è ovviamente abbastanza veloce.

Affidarsi invece a include_docs=true diminuirà la dimensione dell'indice su disco, è vero. Tuttavia, durante l'interrogazione, CouchDB deve eseguire un documento letto per ogni riga restituita. Ciò comporta essenzialmente ricerche di documenti casuali dal file di dati principale, il che significa che il costo e il tempo di restituzione dei dati aumentano in modo significativo.

Mentre la differenza temporale di query per piccoli numeri di documenti è lenta, si sommerà su ogni chiamata effettuata dall'applicazione. Per me, quindi, l'emissione di campi necessari da un documento nell'indice è di solito la chiamata giusta - il disco è economico, l'attenzione dell'utente si estende meno. Questo è in generale simile all'utilizzo di indici di copertura in un database relazionale, un altro consiglio ampiamente diffuso.

Ho fatto un test on this totalmente non scientifico per avere un'idea di quale sia la differenza. Ho riscontrato un aumento di 8 volte del tempo di risposta e un aumento del 50% della CPU quando si utilizza include_docs=true per leggere 100.000 documenti da una vista rispetto a una vista in cui i documenti venivano emessi direttamente nell'indice stesso.