Come utilizzare il feed delle modifiche?

Dato un singolo database orders, è possibile richiedere al database un elenco di modifiche, in tal caso, limitando la serie di risultati a cinque modifiche con ?limit=5:

GET /orders/_changes?limit=5
{
  "results": [
    {
      "seq": "1-g1AAAAB5eJzLYWBg",
      "id": "00002Sc12XI8HD0YIBJ92n9ozC0Z7TaO",
      "changes": [
        {
          "rev": "1-3ef45fdbb0a5245634dc31be69db35f7"
        }
      ]
    },
    ....
  ],
  "last_seq": "5-g1AAAAB5eJzLYWBg"
}

La chiamata API restituisce le seguenti modifiche:

results

Un array di modifiche.

last_seq

Un token che può essere fornito all'endpoint delle modifiche in una successiva chiamata API per ottenere il successivo batch di modifiche.

Vedi come recuperare il successivo batch di modifiche nel seguente esempio:

GET /orders/_changes?limit=5&since=5-g1AAAAB5eJzLYWBg
{
  "results": [ ...],
  "last_seq": "10-g1AAAACbeJzLY"
}

Il parametro since viene utilizzato per definire da dove si desidera iniziare il feed delle modifiche:

since=0

L'inizio del feed di modifiche.

since=now

La fine del feed delle modifiche.

since=<a last seq token>

Da un luogo noto nel feed delle modifiche.

Al valore nominale, seguire il feed delle modifiche sembra semplice come concatenare le chiamate API _changes . Quindi, IBM Cloudant passa la risposta last_seq da una risposta changes feed al parametro since della richiesta successiva. Ma alcune sottigliezze ai cambiamenti hanno bisogno di ulteriori discussioni.

Perché il feed delle modifiche fornisce ogni modifica almeno una volta?

Il IBM Cloudant feed delle modifiche standard promette di restituire ogni documento almeno una volta, il che non equivale a promettere di restituire ogni documento solo una volta. In altre parole, è possibile per un consumatore di changes feed vedere nuovamente la stessa modifica o una serie di modifiche ripetute.

Un utente del feed delle modifiche deve considerare le modifiche idempotently. In pratica, è necessario ricordare se una modifica è già stata gestita prima di attivare un'azione da una modifica. Un consumatore di feed di modifiche ingenue potrebbe inviare un messaggio a uno smartphone ad ogni modifica ricevuta. Ma un utente potrebbe ricevere messaggi di testo duplicati se una modifica non viene trattata idempotentemente quando si verificano modifiche ripetute.

Di solito questi "riavvolti" del feed dei cambiamenti sono brevi, ripetendo solo una manciata di cambiamenti. Ma in alcuni casi, una richiesta potrebbe vedere una risposta con migliaia di modifiche ripetute - potenzialmente tutte le modifiche dall'inizio del tempo. Il potenziale per rewinds rende changes feed non adatto per un'applicazione che prevede un comportamento simile alla coda.

Per ripetere, il feed delle modifiche di IBM Cloudantpromette di consegnare un documento almeno una volta in un feed delle modifiche e non fornisce alcuna garanzia sui valori ripetuti tra più richieste.

Il feed delle modifiche funziona in "tempo reale"?

Il feed delle modifiche non garantisce la rapidità con cui una modifica in entrata appare a un client che utilizza il feed delle modifiche. Le applicazioni non devono essere sviluppate con il presupposto che gli inserimenti, gli aggiornamenti e le eliminazioni dei dati vengano immediatamente propagati a un lettore di modifiche.

Perché tutte le modifiche ai singoli documenti non vengono visualizzate nel feed delle modifiche?

Se un documento viene aggiornato più volte tra le chiamate feed delle modifiche, il feed delle modifiche potrebbe riflettere solo le modifiche più recenti. Il client non riceve ogni modifica ad ogni documento.

Il feed delle modifiche di IBM Cloudant non è un log di transazione che contiene ogni evento che si è verificato in ordine temporale.

È possibile utilizzare un feed di modifiche filtrate per query operative?

Filtrando il feed delle modifiche, e per estensione, l'esecuzione della replica filtrata ha i suoi utilizzi:

• Copia dei dati dall'origine alla destinazione ma ignorando i documenti eliminati.
• Copia dei dati ma senza definizioni di indice (documenti di progetto).

Questo post del blog descrive il modo in cui fornire un selector durante la replica consente il corretto funzionamento di questi casi di utilizzo.

Il feed delle modifiche con un parametro selector di accompagnamento non è il metodo per estrarre le sezioni di dati dal database su base di routine. Non deve essere utilizzato come un mezzo per eseguire query operative su un database. Le modifiche filtrate sono lente (il filtro viene applicato a ogni documento modificato a turno, senza l'aiuto di un indice). Questo processo è molto più lento della creazione di un indice secondario (come una vista MapReduce ) e della query di tale vista.

Un feed di modifiche feed=continuous continua ad essere eseguito per un periodo di tempo indefinito?

No, IBM Cloudant non garantisce la durata della connessione per un feed di modifiche continue. Potrebbe essere regolarmente disconnesso dal server per una serie di motivi, che includono errori di manutenzione, di sicurezza o di rete. Il codice che utilizza il feed di modifiche deve essere progettato per utilizzare un ID sequenza salvato di recente come valore since per effettuare una nuova richiesta di ripresa del feed di modifiche dopo un errore o una disconnessione.

Perché le modifiche non garantiscono l'ordinazione dei tempi?

Se il caso di utilizzo si basa sulla seguente istruzione, questo risultato non può essere raggiunto con il feed di modifiche IBM Cloudant .

"Fetch me every document that has changed since a known date, in the order they were written."

Il database IBM Cloudant non registra l'ora in cui è stata scritta ogni modifica del documento. Il feed delle modifiche non garantisce l'ordine delle modifiche nel feed - non è garantito che siano nell'ordine in cui sono state inviate al database.

Tuttavia, è possibile ottenere questo caso d'uso memorizzando la data di modifica nel corpo del documento:

{
  "_id": "2657",
  "type": "order",
  "customer": "bob@aol.com",
  "order_date": "2022-01-05T10:40:00",
  "status": "dispatched",
  "last_edit_date": "2022-01-14T19:17:20"
}

Ed è possibile creare una vista MapReduce con last_edit_date come chiave:

function(doc) {
  emit(doc.last_edit_date, null)
}

Questa vista può essere sottoposta a query per restituire tutti i documenti che vengono modificati in o dopo una data e ora fornite:

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"

Questa tecnica produce una serie di risultati ordinati nel tempo senza valori ripetuti in modo performante e ripetibile. Il consumatore di questi dati non ha bisogno di gestire idempotently i dati, rendendo più semplice il processo di sviluppo.

Qual è il feed delle modifiche IBM Cloudant per ora?

Il feed delle modifiche di IBM Cloudant è valido per le seguenti attività:

• Attivazione della replica IBM Cloudant , facoltativamente con un selettore per filtrare alcune modifiche.
• I client che utilizzano le modifiche vengono alimentati in batch, ma gestiscono idempotentemente ogni modifica senza preoccuparsi del criterio di ordinamento e prevedendo di visualizzare alcune modifiche più di una volta.

Il feed di modifiche IBM Cloudant non è valido per i seguenti componenti:

• Una coda messaggi. Per ulteriori informazioni, consultare IBM Messages for RabbitMQ per la gestione delle code.
• Un broker di messaggi. Per ulteriori informazioni, vedi IBM Event Streams per la gestione di flussi di eventi scalabili, ordinati nel tempo.
• Un sistema di pubblicazione e sottoscrizione in tempo reale. Per ulteriori informazioni, consultare IBM Databases for Redis per la gestione degli argomenti di pubblicazione e sottoscrizione.
• Un log di transazione. Alcuni database memorizzano ogni modifica in un log di transazione, ma la natura distribuita ed eventualmente congruente di IBM Cloudant significa che non esiste alcun log di transazione con ordine temporale definitivo.
• Un meccanismo di interrogazione. Per ulteriori informazioni, vedi MapReduce Views per la creazione di viste dei tuoi dati ordinate in base a una chiave di tua scelta.