Come funziona il token di continuazione di Cosmos DB?
A prima vista, è chiaro cosa fa il token di continuazione in Cosmos DB: allegarlo alla query successiva fornisce il set di risultati successivo. Ma cosa significa esattamente "prossima serie di risultati"?
Significa:
- la successiva serie di risultati come se la query originale fosse stata eseguita completamente senza paging al momento della prima query (saltando il numero appropriato di documenti)?
- la prossima serie di risultati come se la query originale fosse stata eseguita ora (saltando il numero appropriato di documenti)?
- Qualcosa di completamente diverso?
La risposta 1. sembrerebbe preferibile ma improbabile dato che il server avrebbe bisogno di memorizzare quantità illimitate di stato. Ma anche la risposta 2. è problematica in quanto può causare incongruenze, ad esempio lo stesso documento può essere servito più volte tra le pagine, se i dati sottostanti sono cambiati tra le query di pagina.
Risposte
Le esecuzioni delle query di Cosmos DB sono senza stato sul lato server. Il token di continuazione viene utilizzato per ricreare lo stato dell'indice e tenere traccia dell'avanzamento dell'esecuzione.
"Set successivo di risultati" significa che la query viene eseguita nuovamente da un "segnalibro" dell'esecuzione precedente. Questo segnalibro è fornito dal token di continuazione.
- Documenti creati durante le continuazioni
Possono o non possono essere restituiti a seconda della posizione di inserimento e della query in esecuzione.
Esempio:
SELEZIONA * DA c ORDINA DA c.someValue ASC
Supponiamo che il segnalibro avesse someValue = 10, il motore di query riprende l'elaborazione utilizzando un token di continuazione dove someValue = 10.
Se dovessi inserire un nuovo documento con someValue = 5 tra le esecuzioni della query, non verrà visualizzato nel gruppo di risultati successivo.
Se il nuovo documento viene inserito in una "pagina" che è> il segnalibro, verrà visualizzato nella successiva serie di risultati
- Documenti aggiornati durante le continuazioni
La stessa logica di cui sopra si applica anche agli aggiornamenti (vedere # 4)
- Documenti cancellati durante le continuazioni
Non verranno visualizzati nella prossima serie di risultati.
- Possibilità di duplicati
In caso della query seguente,
SELEZIONA * DA c ORDINA PER c.remainingInventory ASC
Se l'inventario rimanente è stato aggiornato dopo la prima serie di risultati e ora soddisfa i criteri ORDER BY per la seconda pagina, il documento verrà visualizzato di nuovo.
Cosmos DB non fornisce l'isolamento degli snapshot tra le pagine delle query. Tuttavia, secondo il team del prodotto, questo è uno scenario incredibilmente raro perché le query sulle continuazioni sono molto rapide e nella maggior parte dei casi tutti i risultati delle query vengono restituiti nella prima pagina.
Sulla base di esperimenti preliminari, la risposta sembra essere l'opzione n. 2, o più precisamente:
- I documenti creati dopo aver pubblicato la prima pagina sono osservabili nelle pagine successive
- I documenti aggiornati dopo la pubblicazione della prima pagina sono osservabili nelle pagine successive
- I documenti eliminati dopo la pubblicazione della prima pagina vengono omessi nelle pagine successive
- I documenti non vengono mai notificati due volte
La prima affermazione di cui sopra contraddice le informazioni da MSFT ( cfr. La risposta di Kalyan). Sarebbe fantastico ottenere una risposta più qualificata dal team di Cosmos DB che specifichi con precisione la semantica del recupero delle pagine. Questo potrebbe non essere molto importante per la visualizzazione dei dati nell'interfaccia utente, ma potrebbe essere essenziale per l'elaborazione dei dati nel backend, dato che non sembra esserci alcun modo per disabilitare la paginazione durante l'esecuzione di una query ( cfr. Le query transazionali sono possibili in Cosmos DB? ).
Metodo sperimentale
Ho usato Cosmos DB Explorer di Sacha Bruttin per interrogare una raccolta con 5 documenti, perché questo strumento consente di giocare con le dimensioni della pagina e altre opzioni di richiesta.
La dimensione della pagina era impostata su 1 e le query tra partizioni erano abilitate. Sono state provate diverse query, ad esempio SELECT * FROM co SELECT * FROM c ORDER BY c.name.
Dopo aver recuperato la pagina 1, sono stati inseriti nuovi documenti e alcuni documenti esistenti (inclusi i documenti che dovrebbero apparire nelle pagine successive) sono stati aggiornati ed eliminati. Quindi tutte le pagine successive sono state recuperate in sequenza.
(Una rapida occhiata al codice sorgente dello strumento ha confermato che ResponseContinuationTokenLimitInKbnon è impostato.)