Indekseringspolitikker i Cosmos DB i Microsoft Fabric

Cosmos DB er en skemaagnostisk database, der giver dig mulighed for at gentage i dit program uden at skulle håndtere skema- eller indeksstyring. Indeksering i Cosmos DB i Microsoft Fabric er designet til at levere hurtig og fleksibel forespørgselsydeevne, uanset hvordan dine data udvikler sig. I Cosmos DB i Fabric har alle objektbeholdere en indekseringspolitik, der bestemmer, hvordan objektbeholderens elementer skal indekseres. Standardindekseringspolitikken for nyoprettede objektbeholdere indekserer hver egenskab for hvert element og gennemtvinger områdeindeks for alle strenge eller tal. Denne standardkonfiguration giver dig mulighed for at få en god forespørgselsydeevne uden at skulle tænke på indeksering og administration af indeks på forhånd.

I nogle situationer kan det være en god idé at tilsidesætte denne automatiske funktionsmåde, så den passer bedre til dine krav. Du kan tilpasse en containers indekseringspolitik ved at indstille dens indekseringstilstand og inkludere eller udelukke egenskabsstier.

Indekseringstilstand

Cosmos DB understøtter to indekseringstilstande:

• Konsistent: Indekset opdateres synkront, mens du opretter, opdaterer eller sletter elementer.

• Ingen: Indeksering er deaktiveret på containeren. Denne tilstand bruges ofte, når en objektbeholder bruges som et rent nøgleværdilager uden behov for sekundære indeks. Det kan også bruges til at forbedre ydeevnen af massehandlinger. Når massehandlinger er fuldført, kan indekstilstanden angives til Consistent og derefter overvåges ved hjælp af IndexTransformationProgress funktionen i SDK'et, indtil den er fuldført.

Indeksstørrelse

I Cosmos DB er det samlede forbrugte lager kombinationen af både Datastørrelse og Indeksstørrelse. Følgende er nogle funktioner med indeksstørrelse:

• Indeksstørrelsen afhænger af indekseringspolitikken. Hvis alle egenskaberne indekseres, kan indeksstørrelsen være større end datastørrelsen.

• Når data slettes, komprimeres indekserne næsten fortløbende. Men i forbindelse med sletning af små data kan du muligvis ikke straks se et fald i indeksstørrelsen.

• Indeksstørrelsen kan blive midlertidigt større, når fysiske partitioner opdeles. Indeksområdet frigives, når partitionsopdelingen er fuldført.

• Systemegenskaberne id og _ts indekseres altid, når objektbeholderens indekseringstilstand er konsistent.

• Systemegenskaberne id og _ts er ikke inkluderet i beskrivelsen af de indekserede stier for en objektbeholderpolitik. Denne udeladelse er tilsigtet, fordi disse systemegenskaber altid er indekseret som standard, og denne funktionsmåde kan ikke deaktiveres.

Medtager og udelader egenskabsstier

En brugerdefineret indekseringspolitik kan angive egenskabsstier, der eksplicit er inkluderet eller udelukket fra indeksering. Ved at optimere antallet af stier, der indekseres, kan du reducere ventetiden og ru chargen for skrivehandlinger betydeligt.

Overvej dette JSON-element igen:

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

Denne indekseringspolitik resulterer i disse indekseringsstier:

Disse stier er defineret med følgende tilføjelser:

• en sti, der fører til en skalarværdi (streng eller tal), slutter med /?

• elementer fra en matrix håndteres sammen via notationen /[] (i stedet for /0, /1osv.)

• /* jokertegnet kan bruges til at matche alle elementer under noden

En basislinjeindekseringspolitik for eksempelelementet kunne inkludere følgende optimeringer:

• ' headquarterss employees sti er /headquarters/employees/?

• ' locationscountry stien er/locations/[]/country/?

• stien til noget under headquarters er /headquarters/*

Vi kan f.eks. inkludere stien /headquarters/employees/? . Denne sti sikrer, at vi indekserer employees egenskaben, men ikke indekserer ekstra indlejrede JSON i denne egenskab.

Inkluder/udeluk-strategi

Alle indekseringspolitik skal inkludere rodstien /* som enten en inkluderet eller udeladt sti.

• Medtag rodstien for selektivt at udelade stier, der ikke behøver at blive indekseret. Denne fremgangsmåde anbefales, da Cosmos DB proaktivt kan indeksere alle nye egenskaber, der kan føjes til din model.

• Udelad rodstien for selektivt at inkludere stier, der skal indekseres. Egenskabsstien for partitionsnøgle er ikke indekseret som standard med den udeladte strategi og bør udtrykkeligt medtages, hvis det er nødvendigt.

• For stier med almindelige tegn, der omfatter: alfanumeriske tegn og _ (understregningstegn), behøver du ikke at undslippe stistrengen omkring dobbelte anførselstegn (f.eks. "/sti/?"). I forbindelse med stier med andre specialtegn skal du undgå stistrengen omkring dobbelte anførselstegn (f.eks. "/"path-abc"/?"). Hvis du forventer specialtegn i din sti, kan du undslippe alle stier for sikkerhed. Funktionelt gør det ingen forskel, hvis du undslipper alle stier eller kun dem, der har specialtegn.

• Systemegenskaben _etag er som standard udelukket fra indeksering, medmindre etag føjes til den inkluderede sti til indeksering.

• Hvis indekseringstilstanden er sat til konsistent, indekseres systemegenskaberne id og _ts automatisk.

• Hvis der ikke findes en eksplicit indekseret sti i et element, føjes der en værdi til indekset for at angive, at stien ikke er defineret.

Alle eksplicit inkluderede stier har værdier, der er føjet til indekset for hvert element i objektbeholderen, også selvom stien ikke er defineret for et bestemt element.

Du kan få flere oplysninger under Eksempelindekseringspolitikker.

Inkluder/udeluk forrang

Hvis dine inkluderede stier og udeladte stier har en konflikt, har den mere præcise sti forrang.

Overvej dette eksempel:

• Inkluderet sti: /food/ingredients/nutrition/*

• Udelukket sti: /food/ingredients/*

I dette tilfælde har den inkluderede sti forrang frem for den udeladte sti, fordi den er mere præcis. På baggrund af disse stier udelades alle data i /food/ingredients stien eller indlejret i stien fra indekset. Undtagelsen er data i den inkluderede sti: /food/ingredients/nutrition/*, som indekseres.

Her er nogle regler for rangplacering af inkluderede og udeladte stier i Cosmos DB:

• Dybere stier er mere præcise end smallere stier. for eksempel: /a/b/? er mere præcis end /a/?.

• /? er mere præcis end /*. Er f.eks. mere præcis, /a/? end /a/* det /a/? er tilfældet.

• Stien /* skal enten være en inkluderet sti eller en udeladt sti.

Fuldtekstindekser

Fuldtekstindekser muliggør fuldtekstsøgning og bedømmelse effektivt ved hjælp af indekset. Du kan nemt definere en fuldtekststi i en indekseringspolitik ved at inkludere en fullTextIndexes sektion i indekseringspolitikken, der indeholder alle de tekststier, der skal indekseres. For eksempel:

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

Vektorindekser

Vektorindekser øger effektiviteten, når du udfører vektorsøgninger ved hjælp af systemfunktionen VECTORDISTANCE . Vektorsøgninger har lavere ventetid, højere gennemløb og mindre forbrug af anmodningsenhed ved anvendelse af et vektorindeks. Du kan angive følgende typer vektorindekspolitikker:

Der er et par punkter, du skal være opmærksom på:

• Indekstyperne flat og quantizedFlat bruger Cosmos DB's indeks til at gemme og læse hver vektor under en vektorsøgning. Vektorsøgninger med et flat indeks er brutale søgninger og giver 100% nøjagtighed eller genkaldelse. Denne nøjagtighed betyder, at søgningen altid finder de mest lignende vektorer i datasættet. Et indeks understøtter dog flat vektorer med op til 505 dimensioner.

  • Indekset quantizedFlat gemmer de kvantiserede (komprimerede) vektorer i indekset. Vektorsøgninger med quantizedFlat indeks er også brutale søgninger, men deres nøjagtighed kan være lidt mindre end 100% da vektorerne kvantiseres, før de føjes til indekset. Vektorsøgninger med quantized flat skal dog have lavere ventetid, højere gennemløb og lavere omkostninger for jernbanevirksomhed end vektorsøgninger på et flat indeks. Denne type er en god mulighed for scenarier, hvor du bruger forespørgselsfiltre til at indsnævre vektorsøgningen til et relativt lille sæt vektorer. I dette scenarie kræves der høj nøjagtighed.

  • Indekset diskANN er et separat indeks defineret specifikt for vektorer, der anvender DiskANN, en suite af højtydende vektorindekseringsalgoritmer udviklet af Microsoft Research. DiskANN-indekser kan tilbyde nogle af de laveste ventetider, højeste gennemløb og de laveste forespørgsler om RU-omkostninger, samtidig med at den høje nøjagtighed bevares. Men da DiskANN er et omtrentligt nærmeste naboindeks (ANN), kan nøjagtigheden være lavere end quantizedFlat eller flat.

  • Indekserne diskANN og quantizedFlat kan tage valgfri parametre for indeksopbygning, der kan bruges til at justere nøjagtigheden i forhold til ventetidskonteringen, der gælder for hvert omtrentlige vektorindeks for nærmeste naboer.

• quantizationByteSize: Angiver størrelsen (i byte) for produktantal. (Min=1, Default=dynamic (systemet beslutter), Max=512). Hvis du angiver denne størrelse større, kan det resultere i højere nøjagtighedsvektorsøgninger på bekostning af højere omkostninger for jernbanevirksomheden og højere ventetid. Denne afvejing gælder for både quantizedFlat og DiskANN indekstyper.

  • indexingSearchListSize: Angiver, hvor mange vektorer der skal søges i under oprettelse af indeksopbygning. Min.=10, Standard=100, Maks. =500. Hvis du angiver denne størrelse større, kan det resultere i vektorsøgninger med højere nøjagtighed på bekostning af længere indeksopbygningstider og højere ventetider for vektorindfødning. Denne egenskab gælder kun for DiskANN indekser.

Her er et eksempel på en indekseringspolitik med et vektorindeks:

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

Rumlige indekser

Når du definerer en afstandssti i indekseringspolitikken, skal du definere, hvilket indeks type der skal anvendes på den pågældende sti.

Mulige typer for rumlige indekser omfatter:

• Point

• Polygon

• MultiPolygon

• LineString

Cosmos DB opretter som standard ingen rumlige indeks. Hvis du vil bruge indbyggede funktioner til spatial SQL, skal du oprette et rumligt indeks for de påkrævede egenskaber. For mere information, se rumlige indeks.

Tupleindekser

Tupelindeks er nyttige, når du udfører filtrering på flere felter i et matrixelement. Tupelindekser er defineret i afsnittet includedPaths i indekseringspolitikken ved hjælp af tupelangivelsen [].

Matrix tuplestier defineres i includedPaths sektionen ved hjælp af følgende notation: <path prefix>/[]/{<tuple 1>, <tuple 2>, …, <tuple n>}/?

Overvej disse vigtige regler for matrixtupler:

• Hver del af tupelen er adskilt af et komma.

• Den første del, stipræfikset, er den sti, der er fælles mellem tuplerne. Det er stien fra rod til matrix. I vores eksempel er /eventsdet .

• Efter den første del skal tupelen indeholde matrix jokertegnangivelsen []. Alle matrix tuplestier skal have en matrix jokertegnangivelse før tupleangivelsen {}.

• Den næste del specificerer tupler ved hjælp af tuplespecifieren {}.

• Tuple skal bruge den samme stispecifikation som andre indeksstier med nogle få undtagelser:

  • Tuples bør ikke starte med foranstillet /.

  • Tuples må ikke have matrix jokertegn.

  • Tuples må ikke slutte med ? eller *.

  • ? er det sidste segment i en tupelsti og skal angives umiddelbart efter tupelangivelsessegmentet.

Denne specifikation er f.eks. en gyldig tupelsti: /events/[]/{name, category}/?

Her er et par mere gyldige eksempler på matrix tuplestier:

[
  { "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}/?" }
]

Her er nogle eksempler på ugyldige array-tuplestier med forklaringer:

Sammensatte indekser

Forespørgsler, der har en ORDER BY delsætning med to eller flere egenskaber, kræver et sammensat indeks. Du kan også definere et sammensat indeks for at forbedre ydeevnen for mange ligheds- og områdeforespørgsler. Der er som standard ikke defineret sammensatte indeks, så du skal tilføje sammensatte indeks efter behov.

Du kan ikke bruge /* jokertegnet i sammensatte indeksstier. Hver sammensat sti slutter automatisk med /?, så du ikke behøver at tilføje den. Sammensatte stier skal pege på en skalarværdi, som er den eneste værdi, der er inkluderet i det sammensatte indeks. Hvis der ikke findes en sammensat indekssti i et element eller peger på en ikke-calar værdi, føjer Cosmos DB en værdi til indekset for at vise, at stien ikke er defineret.

Når du definerer et sammensat indeks, skal du angive disse to komponenter:

• To eller flere egenskabsstier, der er defineret i en bestemt rækkefølge, som påvirker den måde, det sammensatte indeks bruges på.

• Ordenen defineres som enten stigende eller faldende.

Når du tilføjer et sammensat indeks, bruger forespørgslen eksisterende områdeindeks, indtil den nye sammensatte indekstilføjelse er fuldført. Når du tilføjer et sammensat indeks, kan du derfor muligvis ikke straks se forbedringer af ydeevnen.

ORDER BY forespørgsler om flere egenskaber:

Følgende overvejelser bruges, når du bruger sammensatte indeks til forespørgsler med en ORDER BY delsætning med to eller flere egenskaber.

• Hvis de sammensatte indeksstier ikke svarer til sekvensen af egenskaberne i delsætningen ORDER BY , kan det sammensatte indeks ikke understøtte forespørgslen.

• Rækkefølgen af sammensatte indeksstier (stigende eller faldende) skal også svare til order i -delsætningen ORDER BY .

• Det sammensatte indeks understøtter også en ORDER BY delsætning med den modsatte rækkefølge på alle stier.

Overvej følgende eksempel, hvor et sammensat indeks er defineret for egenskabers navn, alder og _ts:

Du bør tilpasse indekseringspolitikken, så du kan håndtere alle nødvendige ORDER BY forespørgsler.

Forespørgsler med filtre på flere egenskaber

Hvis en forespørgsel har filtre på to eller flere egenskaber, kan det være nyttigt at oprette et sammensat indeks for disse egenskaber.

Overvej f.eks. følgende forespørgsel, der både har et ligheds- og områdefilter:

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

Denne forespørgsel er mere effektiv og tager mindre tid og bruger færre anmodningsenheder , hvis den kan anvende et sammensat indeks på (name ASC, age ASC).

Forespørgsler med flere områdefiltre kan også optimeres med et sammensat indeks. Hvert enkelt sammensatte indeks kan dog kun optimere et enkelt områdefilter. Områdefiltre omfatter >, <, <=, >=og !=. Områdefilteret skal defineres sidst i det sammensatte indeks.

Overvej følgende forespørgsel med et lighedsfilter og to områdefiltre:

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

Denne forespørgsel er mere effektiv, når et sammensat indeks er slået til (name ASC, age ASC) og (name ASC, _ts ASC). Forespørgslen ville dog ikke bruge et sammensat indeks på (age ASC, name ASC) , fordi egenskaberne med lighedsfiltre først skal defineres i det sammensatte indeks. Der kræves to separate sammensatte indeks i stedet for et enkelt sammensat indeks, (name ASC, age ASC, _ts ASC) da hvert sammensatte indeks kun kan optimere et enkelt områdefilter.

Følgende overvejelser bruges, når du opretter sammensatte indeks for forespørgsler med filtre på flere egenskaber:

• Filterudtryk kan bruge flere sammensatte indeks.

• Egenskaberne i forespørgslens filter skal stemme overens med egenskaberne i det sammensatte indeks. Hvis en egenskab er i det sammensatte indeks, men ikke er inkluderet i forespørgslen som et filter, bruger forespørgslen ikke det sammensatte indeks.

• Når en forespørgsel filtrerer efter egenskaber, der ikke er inkluderet i et sammensat indeks, bruges en kombination af sammensatte indeks og områdeindeks til at evaluere forespørgslen. Denne fremgangsmåde bruger færre RU'er end udelukkende at være afhængig af områdeindekser.

• Hvis en egenskab har et områdefilter (>, <, <=>=, eller !=), skal denne egenskab defineres sidst i det sammensatte indeks. Hvis en forespørgsel har mere end ét områdefilter, kan den drage fordel af flere sammensatte indeks.

• Når du opretter et sammensat indeks for at optimere forespørgsler med flere filtre, ORDER har det sammensatte indeks ingen indvirkning på resultaterne. Denne egenskab er valgfri.

Overvej følgende eksempler, hvor et sammensat indeks er defineret for egenskabers navn, alder og tidsstempel:

Forespørgsler med et filter og ORDER BY

Hvis en forespørgsel filtrerer efter en eller flere egenskaber og har forskellige egenskaber i ORDER BY-delsætningen, kan det være nyttigt at føje egenskaberne i filteret til delsætningen ORDER BY .

Hvis du f.eks. føjer egenskaberne i filteret til delsætningen ORDER BY , kan følgende forespørgsel omskrives for at anvende et sammensat indeks:

Forespørgsel ved hjælp af områdeindeks:

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

Forespørgsel ved hjælp af sammensat indeks:

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

De samme forespørgselsoptimeringer kan generaliseres for alle ORDER BY forespørgsler med filtre, idet du skal være opmærksom på, at individuelle sammensatte indeks højst kan understøtte ét områdefilter.

Forespørgsel ved hjælp af områdeindeks:

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

Forespørgsel ved hjælp af sammensat indeks:

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

Derudover kan du bruge sammensatte indeks til at optimere forespørgsler med systemfunktioner og ORDER BY:

Forespørgsel ved hjælp af områdeindeks:

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

Forespørgsel ved hjælp af sammensat indeks:

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

Følgende overvejelser gælder, når du opretter sammensatte indeks for at optimere en forespørgsel med et filter og ORDER BY en delsætning:

• Hvis du ikke definerer et sammensat indeks for en forespørgsel med et filter på én egenskab og en separat ORDER BY delsætning ved hjælp af en anden egenskab, lykkes forespørgslen stadig. Ru-omkostningerne for forespørgslen kan dog reduceres med et sammensat indeks, især hvis egenskaben i delsætningen ORDER BY har en høj kardinalitet.

• Hvis forespørgslen filtrerer efter egenskaber, skal disse egenskaber inkluderes først i delsætningen ORDER BY .

• Hvis forespørgslen filtrerer efter flere egenskaber, skal lighedsfiltrene være de første egenskaber i delsætningen ORDER BY .

• Hvis forespørgslen filtrerer efter flere egenskaber, kan du maksimalt have ét områdefilter eller en systemfunktion anvendt pr. sammensat indeks. Den egenskab, der bruges i områdefilteret eller systemfunktionen, skal defineres sidst i det sammensatte indeks.

• Alle overvejelser i forbindelse med oprettelse af sammensatte indeks for ORDER BY forespørgsler med flere egenskaber og forespørgsler med filtre på flere egenskaber gælder stadig.

Forespørgsler med et filter og en aggregering

Hvis en forespørgsel filtrerer efter en eller flere egenskaber og har en aggregatsystemfunktion, kan det være nyttigt at oprette et sammensat indeks for egenskaberne i filter- og aggregeringssystemfunktionen. Denne optimering gælder for systemfunktionerne SUM og AVG .

Følgende overvejelser gælder, når du opretter sammensatte indeks for at optimere en forespørgsel med en filter- og aggregeringssystemfunktion.

• Sammensatte indeks er valgfrie, når du kører forespørgsler med aggregeringer. Ru-omkostningerne ved forespørgslen kan dog ofte reduceres med et sammensat indeks.

• Hvis forespørgslen filtrerer efter flere egenskaber, skal lighedsfiltrene være de første egenskaber i det sammensatte indeks.

• Du kan maksimalt have ét områdefilter pr. sammensat indeks, og det skal være på egenskaben i den aggregerede systemfunktion.

• Egenskaben i den aggregerede systemfunktion skal defineres sidst i det sammensatte indeks.

• ( orderASC eller DESC) betyder ikke noget.

Sammensatte indeks med et matrix jokertegn

Her er et eksempel på et sammensat indeks, der indeholder et matrix jokertegn:

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

Et eksempel på en forespørgsel, der kan drage fordel af dette sammensatte indeks, er:

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

Ændring af indekseringspolitikken

En opdatering af indekseringspolitikken udløser en transformation fra det gamle indeks til det nye. Denne transformation udføres på stedet og online. Der forbruges ingen ekstra lagerplads under handlingen. Den gamle indekseringspolitik transformeres effektivt til den nye politik, uden at det påvirker skrivetilgængeligheden, læsetilgængeligheden eller det gennemløb, der er klargjort på objektbeholderen. Indekstransformation er en asynkron handling, og den tid, det tager at fuldføre, afhænger af det klargjorte gennemløb, antallet af elementer og deres størrelse. Hvis du har brug for at foretage flere opdateringer af indekseringspolitikken, skal du udføre alle ændringerne i en enkelt handling. Denne fremgangsmåde gør det muligt at fuldføre indekstransformationen hurtigere.

Der er ingen indvirkning på skrivetilgængeligheden under indekstransformationer. Indekstransformationen bruger dine klargjorte RU'er, men har en lavere prioritet end dine CRUD-handlinger eller -forespørgsler.

Der er ingen indvirkning på læsetilgængeligheden, når du tilføjer nye indekserede stier. Forespørgsler bruger kun nye indekserede stier, når indekstransformationen er fuldført. Når du tilføjer en ny indekseret sti, har forespørgsler, der drager fordel af den indekserede sti, med andre ord samme ydeevne før og under indekstransformationen. Når indekstransformationen er fuldført, begynder forespørgselsprogrammet at bruge de nye indekserede stier.

Når du fjerner indekserede stier, skal du gruppere alle dine ændringer i én indekseringspolitiktransformation. Hvis du fjerner flere indekser og gør det i én enkelt ændring af indekseringspolitikken, giver forespørgselsprogrammet ensartede og komplette resultater i hele indekstransformationen. Men hvis du fjerner indeks gennem flere ændringer af indekseringspolitikken, giver forespørgselsprogrammet ikke ensartede eller komplette resultater, før alle indekstransformationer er fuldført. De fleste udviklere slipper ikke indekser og forsøger derefter med det samme at køre forespørgsler, der bruger disse indekser. I praksis er denne situation usandsynlig.

Når du slipper en indekseret sti, stopper forespørgselsprogrammet med det samme med at bruge den og udfører i stedet en komplet scanning. Hvis det er muligt, skal du altid gruppere fjernelse af flere indeks i en enkelt ændring af indekseringspolitikken.

Fjernelse af et indeks træder i kraft med det samme, mens tilføjelse af et nyt indeks tager noget tid, da det kræver en indekseringstransformation. Sørg for først at tilføje det nye indeks og vent derefter på, at indekstransformationen er færdig, før du fjerner det tidligere indeks fra indekseringspolitikken, når du erstatter et indeks med et andet. Følg f.eks. denne strategi, når du erstatter et indeks med en enkelt egenskab med et sammensat indeks. Ellers påvirker dette fejltrin din mulighed for at forespørge det forrige indeks negativt og kan ødelægge alle aktive arbejdsbelastninger, der refererer til det forrige indeks.

Indekseringspolitikker og TTL

Brug af funktionen time-to-Live (TTL) kræver indeksering.

Dette kræves, at:

• Det er ikke muligt at aktivere TTL på en objektbeholder, hvor indekseringstilstanden er angivet til none,

• Det er ikke muligt at angive indekseringstilstanden til Ingen i en objektbeholder, hvor TTL er aktiveret.

I scenarier, hvor ingen egenskabssti skal indekseres, men TTL er påkrævet, kan du bruge en indekseringspolitik, hvor indekseringstilstanden er angivet til consistent, ingen inkluderede stier og /* som den eneste udeladte sti.

Næste trin

• Gennemse indeksering konceptuelt i Cosmos DB i Microsoft Fabric
• Tilpas en indekseringspolitik for en objektbeholder i Cosmos DB i Microsoft Fabric