Criteri di indicizzazione in Cosmos DB in Microsoft Fabric

Cosmos DB è un database indipendente dallo schema che consente di scorrere l'applicazione senza dover gestire lo schema o la gestione degli indici. L'indicizzazione all'interno di Cosmos DB in Microsoft Fabric è progettata per offrire prestazioni di query veloci e flessibili, indipendentemente dal modo in cui i dati si evolvono. In Cosmos DB in Fabric ogni contenitore ha criteri di indicizzazione che determinano come indicizzare gli elementi del contenitore. I criteri di indicizzazione predefiniti per i contenitori appena creati indicizzano ogni proprietà di ogni elemento e applicano indici di intervallo per qualsiasi stringa o numero. Questa configurazione predefinita consente di ottenere prestazioni ottimali delle query senza dover considerare l'indicizzazione e la gestione degli indici in anticipo.

In alcune situazioni potrebbe essere necessario eseguire l'override di questo comportamento automatico per soddisfare al meglio le proprie esigenze. È possibile personalizzare i criteri di indicizzazione di un contenitore impostandone la modalità di indicizzazione e includendo o escludendo i percorsi delle proprietà.

Modalità di indicizzazione

Cosmos DB supporta due modalità di indicizzazione:

• Coerente: l'indice viene aggiornato in modo sincrono durante la creazione, l'aggiornamento o l'eliminazione di elementi.

• Nessuna: l'indicizzazione è disabilitata nel contenitore. Questa modalità viene comunemente usata quando un contenitore funge da archivio chiave-valore puro senza la necessità di indici secondari. Può essere utilizzata anche per migliorare le prestazioni delle operazioni massive. Al termine delle operazioni di massa, la modalità indice può essere impostata su Consistent e quindi monitorata usando la funzione IndexTransformationProgress nell'SDK fino al termine.

Dimensioni dell'indice

In Cosmos DB l'archiviazione totale utilizzata è la combinazione delle dimensioni dei dati e dell'indice. Di seguito sono riportate alcune caratteristiche delle dimensioni dell'indice:

• Le dimensioni dell'indice dipendono dai criteri di indicizzazione. Se tutte le proprietà vengono indicizzate, le dimensioni dell'indice possono essere maggiori delle dimensioni dei dati.

• Quando i dati vengono eliminati, gli indici vengono compattati quasi continuamente. Tuttavia, per le eliminazioni di dati di piccole dimensioni, è possibile che non si osservi una diminuzione immediata delle dimensioni dell'indice.

• Le dimensioni dell'indice possono aumentare temporaneamente quando le partizioni fisiche vengono suddivise. Lo spazio di indice viene rilasciato una volta terminata la suddivisione della partizione.

• Le proprietà id di sistema e _ts vengono sempre indicizzate quando la modalità di indicizzazione del contenitore è Coerente.

• Le proprietà id di sistema e _ts non sono incluse nella descrizione dei percorsi indicizzati per un criterio contenitore. Questa esclusione è per impostazione predefinita perché queste proprietà di sistema vengono sempre indicizzate per impostazione predefinita e questo comportamento non può essere disabilitato.

Inclusione ed esclusione di percorsi delle proprietà

Un criterio di indicizzazione personalizzato può specificare i percorsi delle proprietà inclusi o esclusi in modo esplicito dall'indicizzazione. Ottimizzando il numero di percorsi indicizzati, è possibile ridurre notevolmente la latenza e l'addebito di UR per le operazioni di scrittura.

Prendere in considerazione di nuovo questo elemento JSON:

{
  "locations": [
    { "country": "Germany", "city": "Berlin" },
    { "country": "France", "city": "Paris" }
  ],
  "headquarters": { "country": "Belgium", "employees": 250 },
  "exports": [
    { "city": "Moscow" },
    { "city": "Athens" }
  ]
}

Questo criterio di indicizzazione genera questi percorsi di indicizzazione:

Questi percorsi vengono definiti con le aggiunte seguenti:

• un percorso che conduce a un valore scalare (stringa o numero) termina con /?

• gli elementi di una matrice vengono indirizzati insieme tramite la /[] notazione (anziché /0, /1e così via)

• Il carattere jolly /* può essere usato per trovare le corrispondenze con qualsiasi elemento al di sotto del nodo

Un criterio di indicizzazione di base per l'elemento di esempio può includere queste ottimizzazioni:

• il percorso headquarters di employees è /headquarters/employees/?

• l percorso locations di country è /locations/[]/country/?

• il percorso di qualsiasi elemento sotto headquarters è /headquarters/*

Ad esempio, è possibile includere il percorso /headquarters/employees/?. Questo percorso garantisce l'indicizzazione della proprietà employees, ma non indicizza codice JSON annidato aggiuntivo all'interno di questa proprietà.

Strategia di inclusione/esclusione

Qualsiasi criterio di indicizzazione deve includere il percorso radice /* come percorso incluso o escluso.

• Includere il percorso radice per escludere in modo selettivo i percorsi che non devono essere indicizzati. Questo approccio è consigliato perché consente a Cosmos DB di indicizzare in modo proattivo qualsiasi nuova proprietà che potrebbe essere aggiunta al modello.

• Escludere il percorso radice per includere in modo selettivo i percorsi che devono essere indicizzati. Il percorso della proprietà della chiave di partizione non viene indicizzato per impostazione predefinita quando si utilizza la strategia esclusa e deve essere incluso in modo esplicito, se necessario.

• Per i percorsi con caratteri regolari che includono: caratteri alfanumerici e _ (carattere di sottolineatura), non è necessario eseguire l'escape della stringa di percorso accanto alle virgolette doppie (ad esempio, "/path/?"). Per i percorsi con altri caratteri speciali, è necessario eseguire l'escape della stringa di percorso accanto alle virgolette doppie (ad esempio "/"path-abc"/?"). Se nel percorso si prevedono caratteri speciali, è possibile eseguire l’escape di ogni percorso per sicurezza. Dal punto di vista funzionale, non fa differenza se si effettua l'escape di ogni percorso o solo di quelli che contengono caratteri speciali.

• La proprietà di sistema _etag viene esclusa dall'indicizzazione per impostazione predefinita, a meno che l'etag non venga aggiunto al percorso incluso per l'indicizzazione.

• Se la modalità di indicizzazione è impostata su coerente, le proprietà di sistema id e _ts vengono indicizzate automaticamente.

• Se un percorso indicizzato in modo esplicito non esiste in un elemento, viene aggiunto un valore all'indice per indicare che il percorso non è definito.

Tutti i percorsi inclusi in modo esplicito hanno valori aggiunti all'indice per ogni elemento del contenitore, anche se il percorso non è definito per un determinato elemento.

Per altre informazioni, vedere Criteri di indicizzazione di esempio.

Precedenza di inclusione/esclusione

Se i percorsi inclusi e i percorsi esclusi sono in conflitto, ha la precedenza il percorso più preciso.

Si consideri questo esempio:

• Percorso incluso: /food/ingredients/nutrition/*

• Percorso escluso: /food/ingredients/*

In questo caso, il percorso incluso ha la precedenza sul percorso escluso perché è più preciso. In base a questi percorsi, tutti i dati nel /food/ingredients percorso o annidati all'interno del percorso verrebbero esclusi dall'indice. L'eccezione è costituita dai dati all'interno del percorso incluso: /food/ingredients/nutrition/*, che verrebbe indicizzato.

Ecco alcune regole per la precedenza dei percorsi inclusi ed esclusi in Cosmos DB:

• I percorsi più lunghi sono più precisi rispetto ai percorsi più brevi. ad esempio: /a/b/? è più preciso di /a/?.

• /? è più preciso di /*. Ad esempio, /a/? è più preciso di /a/* così /a/? ha la precedenza.

• Il percorso /* deve essere un percorso incluso o un percorso escluso.

Indici di testo completo

Gli indici testo integrale consentono la ricerca a testo integrale e l'assegnazione dei punteggi in modo efficiente usando l'indice. La definizione di un percorso di testo completo in una policy di indicizzazione può essere eseguita facilmente includendo una fullTextIndexes sezione della policy di indicizzazione che contiene tutti i percorsi di testo da indicizzare. Per esempio:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        },
    ],
    "fullTextIndexes": [
        {
            "path": "/text"
        }
    ]
}

Indici vettoriali

Gli indici vettoriali aumentano l'efficienza durante l'esecuzione di ricerche vettoriali usando la funzione di sistema VECTORDISTANCE. Le ricerche vettoriali hanno una latenza inferiore, una velocità effettiva più elevata e un consumo minore di unità richiesta (UR) quando si applica un indice vettoriale. È possibile specificare i tipi seguenti di criteri di indice vettoriale:

Alcuni punti da notare:

• I flat tipi di indice e quantizedFlat usano l'indice di Cosmos DB per archiviare e leggere ogni vettore durante una ricerca vettoriale. Le ricerche vettoriali con un flat indice sono ricerche di forza bruta e forniscono 100% accuratezza o richiamo. Questa accuratezza indica che la ricerca trova sempre i vettori più simili nel set di dati. Tuttavia, un flat indice supporta vettori con dimensioni fino a 505 .

  • L'indice quantizedFlat archivia i vettori quantizzati (compressi) nell'indice. Anche le ricerche vettoriali con indice quantizedFlat sono ricerche di forza bruta, ma la loro accuratezza potrebbe essere leggermente inferiore al 100% perché i vettori vengono quantizzati prima dell'aggiunta all'indice. Tuttavia, le ricerche vettoriali con quantized flat devono avere una latenza inferiore, una velocità effettiva più elevata e un costo UR inferiore rispetto alle ricerche vettoriali su un indice flat. Questo tipo è un'opzione valida per gli scenari in cui si usano filtri di query per restringere la ricerca vettoriale a un set relativamente ridotto di vettori. In questo scenario è necessaria un'accuratezza elevata.

  • L'indice diskANN è un indice separato definito in modo specifico per i vettori che applicano DiskANN, una suite di algoritmi di indicizzazione a vettori con prestazioni elevate sviluppati da Microsoft Research. Gli indici DiskANN possono offrire una certa latenza più bassa, la velocità effettiva più elevata e le query sui costi delle UR più basse, mantenendo comunque un'accuratezza elevata. Tuttavia, poiché DiskANN è un indice vicino più prossimo approssimativo (ANN), l'accuratezza potrebbe essere inferiore a quantizedFlat o flat.

  • Gli indici diskANN e quantizedFlat possono accettare parametri di costruzione facoltativi che vengono utilizzati per bilanciare la precisione con il compromesso di latenza, applicabile a ogni indice vettoriale approssimativo Nearest Neighbors.

• quantizationByteSize: imposta le dimensioni (in byte) per la quantizzazione del prodotto. (Min=1, Default=dynamic (deciso dal sistema), Max=512). L'impostazione di questa dimensione maggiore potrebbe comportare ricerche di vettori di accuratezza più elevate a scapito di costi di UR più elevati e una latenza più elevata. Questo compromesso si applica sia ai tipi di indice quantizedFlat che DiskANN.

  • indexingSearchListSize: Imposta il numero di vettori da cercare durante la costruzione dell'indice. Min=10, Default=100, Max=500. L'impostazione di questa dimensione maggiore potrebbe comportare ricerche di vettori di accuratezza più elevate a scapito di tempi di compilazione dell'indice più lunghi e latenze di inserimento di vettori più elevati. Questa caratteristica si applica solo agli DiskANN indici.

Di seguito è riportato un esempio di criteri di indicizzazione con un indice vettoriale:

{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    {
      "path": "/*"
    }
  ],
  "excludedPaths": [
    {
      "path": "/_etag/?",
    },
    {
      "path": "/vector/*"
    }
  ],
  "vectorIndexes": [
    {
      "path": "/vector",
      "type": "diskANN"
    }
  ]
}

Indici spaziali

Quando si definisce un percorso spaziale nei criteri di indicizzazione, è necessario definire l'indice type da applicare a tale percorso.

Tra i possibili tipi di indici spaziali ci sono:

• Punto

• Poligono

• Multipoligono

• LineString

Per impostazione predefinita, Cosmos DB non crea indici spaziali. Per usare le funzioni predefinite di SQL spaziale, creare un indice spaziale nelle proprietà necessarie. Per altre informazioni, vedere Indici spaziali.

Indici di tupla

Gli indici di tupla sono utili quando si esegue il filtro su più campi all'interno di un elemento di matrice. Gli indici di tupla vengono definiti nella sezione includedPaths dei criteri di indicizzazione usando il specificatore di tupla [].

I percorsi di tupla di array vengono definiti nella sezione includedPaths usando la notazione seguente: <path prefix>/[]/{<tuple 1>, <tuple 2>, …, <tuple n>}/?

Considerare queste regole importanti per le tuple di array:

• Ogni parte della tupla è separata da una virgola.

• La prima parte, il prefisso del percorso, è il percorso comune tra le tuple. Si tratta del percorso dalla radice all'array. Nell'esempio, /events è.

• Dopo la prima parte, la tupla deve includere il specificatore di caratteri jolly della matrice []. Tutti i percorsi delle tuple di matrice devono avere un carattere jolly di matrice prima dell'identificatore di tupla {}.

• La parte successiva specifica le tuple usando il specificatore di tupla {}.

• La tupla deve usare la stessa specifica di percorso degli altri percorsi di indice con alcune eccezioni:

  • Le tuple non devono iniziare con l'elemento iniziale /.

  • Le tuple non devono avere caratteri jolly di array.

  • Le tuple non devono terminare con ? o *.

  • ? è l'ultimo segmento in un percorso di tupla e deve essere specificato immediatamente dopo il segmento dell'identificatore di tupla.

Ad esempio, questa specifica è un percorso di tupla valido: /events/[]/{name, category}/?

Ecco alcuni esempi validi in più di percorsi delle tuple di array:

[
  { "path": "/events/[]/{name/first, name/last}/?" },
  { "path": "/events/[]/{name/first, category}/?" },
  { "path": "/events/[]/{name/first, category/subcategory}/?" },
  { "path": "/events/[]/{name/[1]/first, category}/?" },
  { "path": "/events/[]/{[1], [3]}/?" },
  { "path": "/city/[1]/events/[]/{name, category}/?" }
]

Ecco alcuni esempi di percorsi di tupla di matrici non validi con spiegazioni:

Indici compositi

Le query che hanno una clausola ORDER BY con due o più proprietà richiedono un indice composto. È anche possibile definire un indice composto per migliorare le prestazioni di molte query di uguaglianza e intervallo. Per impostazione predefinita, non sono definiti indici compositi, pertanto è necessario aggiungere indici compositi in base alle esigenze.

Non è possibile usare il /* carattere jolly nei percorsi di indice compositi. Ogni percorso composito termina automaticamente con /?, quindi non è necessario aggiungerlo. I percorsi compositi devono puntare a un valore scalare, ovvero l'unico valore incluso nell'indice composito. Se un percorso di indice composito non esiste in un elemento o punta a un valore non scalabile, Cosmos DB aggiunge un valore all'indice per indicare che il percorso non è definito.

Quando si definisce un indice composito, specificare questi due componenti:

• Due o più percorsi di proprietà, definiti in un ordine specifico che influisce sulla modalità di utilizzo dell'indice composito.

• L'ordine, definito come crescente o decrescente.

Quando si aggiunge un indice composito, la query utilizza indici di intervallo esistenti fino al completamento della nuova aggiunta di un indice composito. Pertanto, quando si aggiunge un indice composto, è possibile che non si osservino immediatamente miglioramenti delle prestazioni.

Query ORDER BY su più proprietà:

Quando si usano indici compositi per le query con una ORDER BY clausola con due o più proprietà, vengono usate le considerazioni seguenti.

• Se i percorsi dell’indice composto non corrispondono alla sequenza delle proprietà nella clausola ORDER BY, l'indice composto non può supportare la query.

• Anche l'ordine dei percorsi dell’indice composto (crescente o decrescente) deve corrispondere a order nella clausola ORDER BY.

• L'indice composto supporta anche una clausola ORDER BY con l'ordine opposto in tutti i percorsi.

Si consideri l'esempio seguente in cui viene definito un indice composto in base al nome, all'età e al _ts delle proprietà:

È consigliabile personalizzare i criteri di indicizzazione in modo da poter gestire tutte le query ORDER BY necessarie.

Query con filtri su più proprietà

Se una query ha filtri su due o più proprietà, potrebbe essere utile creare un indice composto per queste proprietà.

Si consideri, ad esempio, la query seguente con un filtro di uguaglianza e di intervallo:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John" AND c.age > 18

Questa query è più efficiente e richiede meno tempo e richiede meno unità richiesta (UR), se è in grado di applicare un indice composito in (name ASC, age ASC).

Le query con più filtri di intervallo possono essere ottimizzate anche con un indice composto. Tuttavia, ogni singolo indice composto può ottimizzare solo un singolo filtro di intervallo. I filtri di intervallo includono >, <, <=, >= e !=. Il filtro di intervallo deve essere definito come ultimo nell'indice composto.

Si consideri la query seguente con un filtro di uguaglianza e due filtri di intervallo:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John" AND
  c.age > 18 AND
  c._ts > 1612212188

Questa query è più efficiente con un indice composto su (name ASC, age ASC) e (name ASC, _ts ASC). Tuttavia, la query non utilizzerebbe un indice composto su (age ASC, name ASC) perché le proprietà con filtri di uguaglianza devono essere definite come prime nell'indice composto. Sono necessari due indici composti separati anziché un singolo indice composto su (name ASC, age ASC, _ts ASC) perché ogni indice composto può ottimizzare solo un singolo filtro di intervallo.

Quando si creano indici compositi per le query con filtri su più proprietà, vengono usate le considerazioni seguenti:

• Le espressioni filtro possono usare più indici composti.

• Le proprietà nel filtro della query devono corrispondere alle proprietà nell'indice composito. Se una proprietà si trova nell'indice composito ma non è inclusa nella query come filtro, la query non usa l'indice composito.

• Quando una query filtra le proprietà non incluse in un indice composito, viene usata una combinazione di indici compositi e di intervallo per valutare la query. Questo approccio utilizza meno UR rispetto all'utilizzo esclusivo degli indici di intervallo.

• Se una proprietà ha un filtro di intervallo (>, <, <=, >= o !=), questa proprietà deve essere definita come ultima nell'indice composto. Se una query dispone di più filtri di intervallo, potrebbe trarre vantaggio da più indici composti.

• Quando si crea un indice composito per ottimizzare le query con più filtri, l'oggetto ORDER dell'indice composito non ha alcun effetto sui risultati. Questa proprietà è facoltativa.

Si considerino gli esempi seguenti in cui viene definito un indice composto in base al nome, all'età e al timestamp delle proprietà:

Query con filtro e clausola ORDER BY

Se una query filtra una o più proprietà e ha proprietà diverse nella clausola ORDER BY, potrebbe essere utile aggiungere le proprietà del filtro alla clausola ORDER BY.

Ad esempio, aggiungendo le proprietà del filtro alla clausola ORDER BY, è possibile riscrivere la query seguente per applicare un indice composto:

Eseguire una query usando l'indice di intervallo:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John"
ORDER BY
  c.timestamp

Eseguire una query usando l'indice composto:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John"
ORDER BY
  c.name,
  c.timestamp

Le stesse ottimizzazioni delle query possono essere generalizzate per qualsiasi query ORDER BY con filtri, considerando che i singoli indici compositi possono supportare al massimo un filtro di intervallo.

Eseguire una query usando l'indice di intervallo:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John" AND
  c.age = 18 AND
  c.timestamp > 1611947901
ORDER BY
  c.timestamp

Eseguire una query usando l'indice composto:

SELECT
  *
FROM
  container c
WHERE
  c.name = "John" AND
  c.age = 18 AND
  c.timestamp > 1611947901
ORDER BY
  c.name,
  c.age,
  c.timestamp

Inoltre, è possibile usare indici compositi per ottimizzare le query con funzioni di sistema e ORDER BY:

Eseguire una query usando l'indice di intervallo:

SELECT
  *
FROM
  container c
WHERE
  c.firstName = "John" AND
  CONTAINS(c.lastName, "Smith", true)
ORDER BY
  c.lastName

Eseguire una query usando l'indice composto:

SELECT
  *
FROM
  container c
WHERE
  c.firstName = "John" AND
  CONTAINS(c.lastName, "Smith", true)
ORDER BY
  c.firstName, c.lastName

Quando si creano indici composti per ottimizzare una query con un filtro e una clausola ORDER BY, si applicano le considerazioni seguenti:

• Se non si definisce un indice composito in una query con un filtro su una proprietà e una clausola separata ORDER BY usando una proprietà diversa, la query ha comunque esito positivo. Tuttavia, il costo UR della query può essere ridotto con un indice composto, in particolare se la proprietà della clausola ORDER BY ha una cardinalità elevata.

• Se la query filtra le proprietà, queste proprietà devono essere incluse per prime nella clausola ORDER BY.

• Se la query filtra più proprietà, i filtri di uguaglianza devono essere le prime proprietà della clausola ORDER BY.

• Se la query filtra più proprietà, è possibile avere un massimo di un filtro di intervallo o una funzione di sistema utilizzati per ogni indice composto. La proprietà utilizzata nel filtro di intervallo o nella funzione di sistema deve essere definita per ultima nell'indice composto.

• Tutte le considerazioni per la creazione di indici composti per le query ORDER BY con più proprietà e le query con filtri su più proprietà sono comunque valide.

Query con filtri e aggregazioni

Se una query filtra una o più proprietà e ha una funzione di sistema di aggregazione, potrebbe essere utile creare un indice composto per le proprietà nella funzione di sistema di filtro e aggregazione. Questa ottimizzazione si applica alle funzioni di sistema SUM e AVG.

Quando si creano indici composti per ottimizzare una query con una funzione di sistema di filtro e aggregazione, si applicano le considerazioni seguenti.

• Gli indici composti sono facoltativi quando si eseguono query con aggregazioni. Tuttavia, il costo UR della query spesso può essere ridotto con un indice composto.

• Se la query filtra più proprietà, i filtri di uguaglianza devono essere le prime proprietà dell'indice composto.

• È possibile avere un massimo di un filtro di intervallo per indice composto e questo deve trovarsi nella proprietà nella funzione di sistema di aggregazione.

• La proprietà della funzione di sistema di aggregazione deve essere definita per ultima nell'indice composto.

• L'oggetto order (ASC o DESC) non è importante.

Indici compositi con un carattere jolly di matrice

Ecco un esempio per un indice composito che contiene un carattere jolly in un array:

{
  "automatic": true,
  "indexingMode": "Consistent",
  "includedPaths": [
    {
      "path": "/*"
    }
  ],
  "excludedPaths": [],
  "compositeIndexes": [
    [
      {
        "path": "/familyname",
        "order": "ascending"
      },
      {
        "path": "/children/[]/age",
        "order": "descending"
      }
    ]
  ]
}

Una query di esempio che può trarre vantaggio da questo indice composito è:

SELECT VALUE
  p.id
FROM
  products p
JOIN
  t IN p.tags
WHERE
  p.category = 'apparel' AND
  p.order > 20

Modifica dei criteri di indicizzazione

Un aggiornamento dei criteri di indicizzazione attiva una trasformazione dall'indice precedente a quella nuova. Questa trasformazione viene eseguita sul posto e online. Durante l'operazione non viene utilizzato spazio di archiviazione aggiuntivo. La vecchia politica di indicizzazione viene trasformata in modo efficiente nella nuova politica senza influire sulla disponibilità di scrittura, sulla disponibilità di lettura o sul throughput fornito nel contenitore. La trasformazione dell’indice è un'operazione asincrona e il tempo necessario per il suo completamento dipende dal throughput fornito, dal numero di elementi e dalle loro dimensioni. Se è necessario apportare più aggiornamenti dei criteri di indicizzazione, eseguire tutte le modifiche in un'unica operazione. Questo approccio consente di completare più rapidamente la trasformazione dell'indice.

Non c'è alcun effetto sulla disponibilità di scrittura durante qualsiasi trasformazione dell'indice. La trasformazione dell'indice utilizza le RU provisionate, ma con una priorità inferiore rispetto alle operazioni CRUD o alle query.

Non esiste alcun effetto sulla disponibilità di lettura quando si aggiungono nuovi percorsi indicizzati. Le query usano nuovi percorsi indicizzati solo dopo il completamento della trasformazione dell'indice. In altre parole, quando si aggiunge un nuovo percorso indicizzato, le query che traggono vantaggio da tale percorso indicizzato hanno le stesse prestazioni prima e durante la trasformazione dell'indice. Al termine della trasformazione dell'indice, il motore di query inizierà a usare i nuovi percorsi indicizzati.

Quando si rimuovono i percorsi indicizzati, è necessario raggruppare tutte le modifiche in un'unica trasformazione dei criteri di indicizzazione. Se si rimuovono più indici e si esegue questa operazione in un unico criterio di indicizzazione, il motore di query fornisce risultati coerenti e completi durante la trasformazione dell'indice. Tuttavia, se si rimuovono gli indici tramite più modifiche ai criteri di indicizzazione, il motore di query non fornisce risultati coerenti o completi fino al completamento di tutte le trasformazioni dell'indice. La maggior parte degli sviluppatori non elimina gli indici e quindi tenta immediatamente di eseguire query che usano questi indici. In pratica, questa situazione è improbabile.

Quando si rilascia un percorso indicizzato, il motore di query smette immediatamente di usarlo ed esegue invece un'analisi completa. Se possibile, raggruppare sempre più rimozioni di indice in un'unica modifica dei criteri di indicizzazione.

La rimozione di un indice ha effetto immediato, mentre l'aggiunta di un nuovo indice richiede del tempo perché richiede una trasformazione di indicizzazione. Assicurarsi di aggiungere prima il nuovo indice e quindi attendere il completamento della trasformazione dell'indice prima di rimuovere l'indice precedente dai criteri di indicizzazione quando si sostituisce un indice con un altro. Ad esempio, seguire questa strategia quando si sostituisce un singolo indice di proprietà con un indice composito. In caso contrario, questo errore influisce negativamente sulla capacità di eseguire query sull'indice precedente e potrebbe interrompere eventuali carichi di lavoro attivi che fanno riferimento all'indice precedente.

Criteri di indicizzazione e TTL

L'uso della funzionalità TTL (Time-to-Live) richiede l'indicizzazione.

Questo requisito significa che:

• Non è possibile attivare TTL in un contenitore in cui la modalità di indicizzazione è impostata su none.

• Non è possibile impostare la modalità di indicizzazione su Nessuno in un contenitore in cui è attivato il TTL.

Per gli scenari in cui non è necessario indicizzare alcun percorso di proprietà, ma è richiesto il TTL, è possibile usare un criterio di indicizzazione con una modalità di indicizzazione impostata su consistent, nessun percorso incluso e /* come unico percorso escluso.

Passo successivo

• Esaminare il concetto di indicizzazione in Cosmos DB in Microsoft Fabric
• Personalizzare un criterio di indicizzazione per un contenitore in Cosmos DB in Microsoft Fabric