Più viste nello stesso documento di progettazione

Se si definiscono più viste nello stesso documento di progettazione, vengono costruite in modo efficiente nello stesso momento. Ogni documento viene letto una sola volta, e viene passato attraverso la funzione Map di ogni vista. Se si utilizza questo approccio, tenere presente che la modifica di un documento di progettazione invalida tutte le viste MapReduce esistenti definite nel documento. Questo processo invalida le viste MapReduce anche se alcune delle viste rimangono inalterate.

Se le viste MapReduce devono essere modificate indipendentemente l'una dall'altra, inserisci le loro definizioni in documenti di progettazione separati.

Questo comportamento non si applica agli indici di ricerca Lucene. Questi possono essere modificati all'interno dello stesso documento di progettazione senza invalidare altri indici non modificati nello stesso documento.

Gestione delle modifiche a un documento di progettazione

Immaginiamo che a un certo punto del futuro si decida di cambiare il design della vista. Ora, invece di restituire il risultato effettivo del timestamp, siamo interessati solo al conteggio di quanti documenti corrispondono ai criteri. Per ottenere questo conteggio, la funzione mappa rimane la stessa, ma ora si utilizza un reduce di _count.

Si veda un esempio di documento di progettazione che utilizza una funzione reduce:

{
    "_id": "_design/fetch",
    "_rev": "2-a2324c9e74a76d2a16179c56f5315dba",
    "views": {
        "by_ts": {
            "map": "function(doc) {
                if (doc.ts) {
                  emit( doc.ts, null);
                }
            }
        }",
        "reduce": "_count"
    },
    "language": "javascript"
}

Quando questo documento di progettazione viene salvato, IBM Cloudant invalida completamente il vecchio indice e inizia a costruire il nuovo indice da zero, iterando su ogni documento a turno. Come per la build originale, il tempo necessario dipende dal numero di documenti presenti nel database. La build inoltre blocca le query in entrata su tale vista fino al completamento.

Ma c'è un problema...

Se si dispone di un'applicazione che accede a questa vista in tempo reale, è possibile che si verifichi un dilemma di distribuzione:

• Versione 1 del codice, che si basava sul documento di progettazione originale, potrebbe non funzionare più perché la vecchia vista è stata invalidata.
• La versione 2 del codice utilizza il nuovo documento di progettazione. Questa versione non può essere rilasciata immediatamente perché la nuova vista non ha ancora terminato la creazione. Tenere presente che il processo di creazione impiega più tempo se il database include molti documenti.
• Un problema più sottile che influisce sul codice è che le versioni 1 e 2 prevedono dati di risultato differenti dalla vista: La versione 1 prevede un elenco di documenti corrispondenti, mentre la versione 2 prevede un numero 'ridotto' di risultati.

Coordinamento delle modifiche ai documenti di progettazione

È possibile gestire questo problema di controllo della modifica in due modi.

Move and switch utensili

Lo script della riga di comando, Node.js, couchmigrate automatizza la procedura Move and switch. Può essere installato utilizzando il seguente comando:

npm install -g couchmigrate

Per utilizzare lo script couchmigrate, definire prima l'istanza URL di CouchDB/{{site. data.keyword.cloudant_short_notm }} impostando una variabile d'ambiente chiamata COUCH_URL. Eseguire il seguente comando per definire il sito URL per l'istanza IBM Cloudant:

export COUCH_URL=https://127.0.0.1:5984

L'indirizzo URL deve iniziare con https:// e può includere le credenziali di autenticazione. Eseguire il seguente comando per definire il sito URL dell'istanza IBM Cloudant con le credenziali di autenticazione:

export COUCH_URL="https://$ACCOUNT:$PASSWORD@$HOST.cloudant.com"

Se si presume che si disponga di un documento di progetto in formato JSON, memorizzato in un file, è possibile eseguire il comando di migrazione.

In questo esempio, db specifica il nome del database da modificare, e dd specifica il percorso del file del documento di progettazione. Eseguire il comando couchmigrate:

couchmigrate --db mydb --dd /path/to/my/dd.json

Lo script coordina la procedura Move and switch, aspettando che la vista sia costruita prima di tornare. Se il documento di progettazione in entrata è uguale a quello precedente, allora lo script restituisce immediatamente il risultato.

Il codice sorgente dello script è disponibile qui: couchmigrate.

Parametro 'stale'

Se un indice è completo ma nel database vengono aggiunti nuovi record, l'indice viene programmato per l'aggiornamento in background. Lo stato del database è mostrato nel diagramma seguente:

Quando si esegue la query della vista, sono disponibili le seguenti opzioni.

• Il comportamento predefinito è quello di garantire che l'indice sia aggiornato, con gli ultimi documenti presenti nel database, prima di restituire la risposta. Quando si esegue la query della vista, IBM Cloudant prima indicizza i 250 nuovi documenti e poi restituisce la risposta.
• Un'alternativa consiste nell'aggiungere il parametro stale=ok alla chiamata API. Questo parametro significa, return me the data that is already indexed. I don't care about the latest updates. In altre parole, quando si interroga la vista con stale=ok, IBM Cloudant restituisce la risposta immediatamente, senza alcuna reindicizzazione aggiuntiva.
• Una seconda alternativa è quella di aggiungere il parametro stale=update_after alla chiamata API. Questo parametro significa, return me the data that is already indexed, and then reindex any new documents. In altre parole, quando si interroga la vista con stale=update_after, IBM Cloudant restituisce la risposta immediatamente e pianifica quindi un'attività in background per indicizzare i nuovi dati.

L'aggiunta di stale=ok o stale=update_after può essere un buon modo per ottenere risposte più rapidamente da una vista, ma a scapito della freschezza.

Il comportamento predefinito distribuisce il carico in modo uniforme tra i nodi del cluster IBM Cloudant. Se si utilizzano le opzioni alternative stale=ok o stale=update_after, queste opzioni potrebbero favorire un sottoinsieme di nodi del cluster per restituire risultati coerenti da tutto l'insieme coerente. Il parametro stale non è una soluzione perfetta per tutti i casi di utilizzo. Tuttavia, può fornire risposte tempestive su set di dati in rapida evoluzione se l'applicazione accetta risultati non aggiornati. Se la velocità di modifica dei dati è piccola, l'aggiunta di stale=ok o stale=update_after non apporta un vantaggio sulle prestazioni e potrebbe distribuire in modo non uniforme il carico su cluster più grandi.

Evitare stale=ok o stale=update_after quando possibile perché il comportamento predefinito fornisce i dati più aggiornati e distribuisce i dati all'interno del cluster. Puoi rendere un'applicazione client consapevole che è in corso un'attività di elaborazione dati di grandi dimensioni (ad esempio, durante un normale aggiornamento di massa dei dati) passando temporaneamente a stale=ok durante questi periodi. L'app può tornare al comportamento predefinito in seguito.

L'opzione stale è ancora disponibile, ma sono disponibili anche le opzioni più utili stable e update che devono essere utilizzate al suo posto. Per ulteriori informazioni, vedi Accesso a una vista obsoleta.