Index frissítése vagy újraépítése az Azure AI Searchben

Ez a cikk azt ismerteti, hogyan frissíthet egy meglévő indexet az Azure AI Searchben sémamódosításokkal vagy tartalomváltozásokkal növekményes indexeléssel. Ismerteti az újraépítések szükséges körülményeit, és javaslatokat nyújt az újraépítések folyamatban lévő lekérdezési kérelmekre gyakorolt hatásának mérséklésére.

Az aktív fejlesztés során gyakran előfordul, hogy az indexek elvetése és újraépítése az indexek tervezése során történik. A legtöbb fejlesztő az adatok egy kis reprezentatív mintával dolgozik, hogy az újraindexelés gyorsabb legyen.

A már éles környezetben lévő alkalmazások sémamódosításai esetén javasoljuk, hogy hozzon létre és teszteljön egy új indexet, amely egy meglévő index mellett fut. Az index aliasával felcserélheti az új indexet, így elkerülheti az alkalmazáskód módosítását.

Tartalom frissítése

Az index növekményes indexelése és szinkronizálása a forrásadatok változásaival alapvető fontosságú a legtöbb keresési alkalmazás számára. Ez a szakasz a keresési indexek mezőtartalmának REST API-val történő frissítésére szolgáló munkafolyamatot ismerteti, de az Azure SDK-k egyenértékű funkciókat biztosítanak.

A kérelem törzse egy vagy több indexelendő dokumentumot tartalmaz. A dokumentumokat egyedi, kis- és nagybetűket megkülönböztető kulcs azonosítja. Minden dokumentum egy művelethez van társítva: "upload", "delete", "merge" vagy "mergeOrUpload". A feltöltési kérelmeknek tartalmazniuk kell a dokumentumadatokat kulcs-érték párok készleteként.

{  
  "value": [  
    {  
      "@search.action": "upload (default) | merge | mergeOrUpload | delete",  
      "key_field_name": "unique_key_of_document", (key/value pair for key field from index schema)  
      "field_name": field_value (key/value pairs matching index schema)  
        ...  
    },  
    ...  
  ]  
}

• Először is használja az API-kat a dokumentumok betöltéséhez, például a Dokumentumok – Index (REST) vagy az Azure SDK-k egyenértékű API-jához. További információ az indexelési technikákról: Dokumentumok betöltése.

• Nagy frissítés esetén a kötegelés (kötegenként legfeljebb 1000 dokumentum, vagy kötegenként körülbelül 16 MB, bármelyik korlát is az első) ajánlott, és jelentősen javítja az indexelési teljesítményt.

• Állítsa be a paramétert @search.action az API-n a meglévő dokumentumokra gyakorolt hatás meghatározásához.

  Művelet	Hatály
  Törlés...	Eltávolítja a teljes dokumentumot az indexből. Ha el szeretne távolítani egy egyéni mezőt, használja az egyesítést, és állítsa a kérdéses mezőt null értékre. A törölt dokumentumok és mezők nem szabadít fel azonnal helyet az indexben. Néhány percenként egy háttérfolyamat végrehajtja a fizikai törlést. Függetlenül attól, hogy az Azure Portalt vagy egy API-t használ az indexstatisztikák visszaadásához, kis késésre számíthat, mielőtt a törlés megjelenik az Azure Portalon és API-kon keresztül.
  egyesül	Frissíti a már létező dokumentumot, és nem találja a dokumentumot. Az egyesítés lecseréli a meglévő értékeket. Ezért mindenképpen ellenőrizze, hogy a gyűjteménymezők több értéket tartalmaznak-e, például a típusmezőket Collection(Edm.String). Ha például egy tags mező egy értékével ["budget"] kezdődik, és egyesítést ["economy", "pool"]hajt végre, akkor a tags mező végső értéke .["economy", "pool"] Nem lesz ["budget", "economy", "pool"]. Ugyanez a viselkedés összetett gyűjteményekre is vonatkozik. Ha a dokumentum egy Szobák nevű összetett gyűjteménymezőt tartalmaz, amelynek értéke [{ "Type": "Budget Room", "BaseRate": 75.0 }], és egyesítést hajt végre egy értékével [{ "Type": "Standard Room" }, { "Type": "Budget Room", "BaseRate": 60.5 }], a Szobák mező végső értéke lesz [{ "Type": "Standard Room" }, { "Type": "Budget Room", "BaseRate": 60.5 }]. Új és meglévő értékek hozzáfűzése és egyesítése nem fog sikerülni.
  mergeOrUpload	Úgy viselkedik, mint az egyesítés, ha a dokumentum létezik, és feltölti, ha a dokumentum új. Ez a növekményes frissítések leggyakoribb művelete.
  upload	Hasonló ahhoz az "upsert"-hez, amelyben a dokumentum be lesz szúrva, ha új, és ha létezik, frissítve vagy lecserélve. Ha a dokumentum nem rendelkezik az index által igényelt értékekkel, a dokumentummező értéke null értékre van állítva.

A lekérdezések továbbra is futnak az indexelés során, de ha meglévő mezőket frissít vagy távolít el, vegyes eredményekre és a szabályozás gyakoribb előfordulására számíthat.

Válaszok

A rendszer a 200-ás állapotkódot adja vissza a sikeres válaszhoz, ami azt jelenti, hogy az összes elem tartósan lett tárolva, és elkezd indexelni. Az indexelés a háttérben fut, és az indexelési művelet befejeződése után néhány másodperccel elérhetővé teszi az új dokumentumokat (azaz lekérdezhető és kereshető). Az adott késés a szolgáltatás terhelésétől függ.

A sikeres indexelést jelzi, hogy az állapottulajdonság az összes elem esetében igaz értékre van állítva, valamint a statusCode tulajdonság értéke 201 (újonnan feltöltött dokumentumok esetén) vagy 200 (egyesített vagy törölt dokumentumok esetén):

{
  "value": [
    {
      "key": "unique_key_of_new_document",
      "status": true,
      "errorMessage": null,
      "statusCode": 201
    },
    {
      "key": "unique_key_of_merged_document",
      "status": true,
      "errorMessage": null,
      "statusCode": 200
    },
    {
      "key": "unique_key_of_deleted_document",
      "status": true,
      "errorMessage": null,
      "statusCode": 200
    }
  ]
}

A rendszer a 207-s állapotkódot adja vissza, ha legalább egy elem indexelése sikertelen volt. Az indexeletlen elemek állapotmezője hamis. A errorMessage tulajdonságok az statusCode indexelési hiba okát jelzik:

{
  "value": [
    {
      "key": "unique_key_of_document_1",
      "status": false,
      "errorMessage": "The search service is too busy to process this document. Please try again later.",
      "statusCode": 503
    },
    {
      "key": "unique_key_of_document_2",
      "status": false,
      "errorMessage": "Document not found.",
      "statusCode": 404
    },
    {
      "key": "unique_key_of_document_3",
      "status": false,
      "errorMessage": "Index is temporarily unavailable because it was updated with the 'allowIndexDowntime' flag set to 'true'. Please try again later.",
      "statusCode": 422
    }
  ]
}  

A errorMessage tulajdonság jelzi az indexelési hiba okát, ha lehetséges.

Az alábbi táblázat a válaszban visszaadható dokumentumonkénti állapotkódokat ismerteti. Egyes állapotkódok a kéréssel kapcsolatos problémákat, míg mások átmeneti hibafeltételeket jeleznek. Az utóbbit egy késleltetés után újra meg kell próbálkoznia.

Ha az ügyfélkód gyakran találkozik egy 207-ben megadott válaszsal, az egyik lehetséges ok az, hogy a rendszer terhelés alatt van. Ezt az 503-ra vonatkozó statusCode tulajdonság ellenőrzésével ellenőrizheti. Ha a statusCode értéke 503, javasoljuk az indexelési kérelmek szabályozását. Ellenkező esetben, ha a forgalom indexelése nem csökken, a rendszer 503 hibával elkezdheti elutasítani az összes kérést.

A 429-es állapotkód azt jelzi, hogy túllépte a kvótát az indexenkénti dokumentumok száma alapján. Létre kell hoznia egy új indexet, vagy frissítenie kell a nagyobb kapacitáskorlátok érdekében.

Tippek növekményes indexeléshez

• Az indexelők automatizálják a növekményes indexelést. Ha használhat indexelőt, és ha az adatforrás támogatja a változáskövetést, az indexelőt ismétlődő ütemezés szerint futtathatja a kereshető tartalom hozzáadásához, frissítéséhez vagy felülírásához, hogy az szinkronizálva legyen a külső adatokkal.

• Ha indexhívásokat indít közvetlenül a leküldéses API-val, használja mergeOrUpload keresési műveletként.

• A hasznos adatnak tartalmaznia kell minden hozzáadni, frissíteni vagy törölni kívánt dokumentum kulcsait vagy azonosítóit.

• Ha az index vektormezőket tartalmaz, és a stored tulajdonságot hamis értékre állítja, győződjön meg arról, hogy a vektort a részleges dokumentumfrissítésben adja meg, még akkor is, ha az érték változatlan. A hamis értékre állítás stored egyik mellékhatása, hogy a vektorok egy újraindexelési műveletre kerülnek. A vektornak a dokumentumok hasznos adataiban való megadása megakadályozza ezt.

• Ha összetett típusok egyszerű mezőinek és almezőinek tartalmát szeretné frissíteni, csak a módosítani kívánt mezőket listázhatja. Ha például csak egy leírásmezőt kell frissítenie, a hasznos adatoknak a dokumentumkulcsból és a módosított leírásból kell állniuk. Ha más mezőket kihagy, az megőrzi a meglévő értékeket.

• Ha a beágyazott módosításokat sztringgyűjteménybe szeretné egyesíteni, adja meg a teljes értéket. Idézze fel az tags előző szakasz mező példáját. Az új értékek felülírják egy teljes mező régi értékeit, és a mező tartalmában nincs egyesítés.

Íme egy REST API-példa , amely az alábbi tippeket mutatja be:

### Get Stay-Kay City Hotel by ID
GET  {{baseUrl}}/indexes/hotels-vector-quickstart/docs('1')?api-version=2024-07-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

### Change the description, city, and tags for Stay-Kay City Hotel
POST {{baseUrl}}/indexes/hotels-vector-quickstart/docs/search.index?api-version=2024-07-01  HTTP/1.1
  Content-Type: application/json
  api-key: {{apiKey}}

    {
        "value": [
            {
            "@search.action": "mergeOrUpload",
            "HotelId": "1",
            "Description": "I'm overwriting the description for Stay-Kay City Hotel.",
            "Tags": ["my old item", "my new item"],
            "Address": {
                "City": "Gotham City"
                }
            }
        ]
    }
       
### Retrieve the same document, confirm the overwrites and retention of all other values
GET  {{baseUrl}}/indexes/hotels-vector-quickstart/docs('1')?api-version=2024-07-01  HTTP/1.1
    Content-Type: application/json
    api-key: {{apiKey}}

Indexséma frissítése

Az indexséma meghatározza a keresési szolgáltatásban létrehozott fizikai adatstruktúrákat, így nem sok sémamódosítást hajthat végre teljes újraépítés nélkül.

Frissítések újraépítés nélkül

Az alábbi lista felsorolja azokat a sémamódosításokat, amelyek zökkenőmentesen bevezethetők egy meglévő indexbe. A lista általában a lekérdezés végrehajtása során használt új mezőket és funkciókat tartalmazza.

• Új mező hozzáadása
• Az retrievable attribútum beállítása egy meglévő mezőben
• Frissítés searchAnalyzer meglévővel rendelkező mezőn indexAnalyzer
• Új elemződefiníció hozzáadása indexhez (amely új mezőkre alkalmazható)
• Pontozási profilok hozzáadása, frissítése vagy törlése
• Szinonimatérképek hozzáadása, frissítése vagy törlése
• Szemantikai konfigurációk hozzáadása, frissítése vagy törlése
• CORS-beállítások hozzáadása, frissítése vagy törlése

A műveletek sorrendje a következő:

1. Kérje le az indexdefiníciót.

2. Módosítsa a sémát az előző lista frissítéseivel.

3. Frissítse az indexsémát a keresési szolgáltatásban.

4. Ha új mezőt adott hozzá, frissítse az index tartalmát úgy, hogy megfeleljen a módosított sémának. Az összes többi módosítás esetén a meglévő indexelt tartalom is használatban van.

Amikor új mezőre módosít egy indexsémát, az index meglévő dokumentumai null értéket kapnak az adott mezőhöz. A következő indexelési feladatban a külső forrásadatok értékei helyettesítik az Azure AI Search által hozzáadott null értékeket.

A frissítések során nem lehetnek lekérdezési fennakadások, de a lekérdezési eredmények a frissítések érvénybe lépésekor eltérőek lesznek.

Újraépítést igénylő frissítések

Egyes módosításokhoz az indexek elvetése és újraépítése szükséges, és az aktuális indexet egy újra kell cserélni.

A műveletek sorrendje a következő:

1. Szerezze be az indexdefiníciót arra az esetre, ha a jövőben szüksége lenne rá, vagy egy új verzió alapjául szolgál.

2. Fontolja meg biztonsági mentési és visszaállítási megoldás használatát az indextartalom másolatának megőrzéséhez. A C#-ban és a Pythonban is vannak megoldások. A Python-verziót javasoljuk, mert naprakészebb.

   Ha rendelkezik kapacitással a keresési szolgáltatásban, tartsa meg a meglévő indexet az új létrehozása és tesztelése során.

3. A meglévő index elvetése. Az indexet megcélzó lekérdezéseket a rendszer azonnal elveti. Ne feledje, hogy az index törlése visszafordíthatatlan, ami megsemmisíti a mezők gyűjteményének és egyéb szerkezeteinek fizikai tárolását.

4. Módosított index közzététele, amelyben a kérelem törzse módosított vagy módosított meződefiníciókat és konfigurációkat tartalmaz.

5. Töltse be az indexet külső forrásból származó dokumentumokkal . A dokumentumok indexelése az új séma meződefiníciói és konfigurációi alapján történik.

Az index létrehozásakor a rendszer lefoglalja a fizikai tárolót az indexséma egyes mezőihez, az egyes kereshető mezőkhöz pedig fordított indexet, az egyes vektormezőkhöz pedig egy vektorindexet. A nem kereshető mezők szűrőkben vagy kifejezésekben használhatók, de nem rendelkeznek fordított indexekkel, és nem teljes szöveges vagy homályos kereshetőek. Az indexek újraépítésekor ezek az invertált indexek és vektorindexek törlődnek és újra létrejönnek a megadott indexséma alapján.

Az alkalmazáskód megszakadásának minimalizálása érdekében érdemes lehet létrehozni egy index aliast. Az alkalmazáskód az aliasra hivatkozik, de frissítheti annak az indexnek a nevét, amelyre az alias mutat.

Számítási feladatok kiegyensúlyozása

Az indexelés nem fut a háttérben, de a keresési szolgáltatás kiegyensúlyozza az indexelési feladatokat a folyamatban lévő lekérdezésekkel. Az indexelés során az Azure Portalon figyelheti a lekérdezési kérelmeket, hogy a lekérdezések időben befejeződjenek.

Ha a számítási feladatok indexelése elfogadhatatlan mértékű lekérdezési késést eredményez, végezzen teljesítményelemzést , és tekintse át ezeket a teljesítménytippeket a lehetséges kockázatcsökkentés érdekében.

Frissítések keresése

Az első dokumentum betöltése után azonnal megkezdheti az index lekérdezését. Ha ismeri egy dokumentum azonosítóját, a Keresési dokumentum REST API visszaadja az adott dokumentumot. A szélesebb körű teszteléshez meg kell várnia, amíg az index teljesen betöltődik, majd lekérdezésekkel ellenőrizheti a várt környezetet.

A frissített tartalom kereséséhez használhatja a Search Explorert vagy a REST-ügyfelet.

Ha hozzáadott vagy átnevezett egy mezőt, a kijelöléssel adja vissza a mezőt:

"search": "*",
"select": "document-id, my-new-field, some-old-field",
"count": true

Az Azure Portal indexméretet és vektorindex-méretet biztosít. Az index frissítése után ellenőrizheti ezeket az értékeket, de ne felejtsen el kis késést várni, mivel a szolgáltatás feldolgozza a módosítást, és figyelembe veszi a portál frissítési gyakoriságát, ami néhány perc is lehet.

Árva dokumentumok törlése

Az Azure AI Search támogatja a dokumentumszintű műveleteket, így elkülönítve kereshet, frissíthet és törölhet egy adott dokumentumot. Az alábbi példa bemutatja, hogyan törölhet egy dokumentumot.

A dokumentumok törlése nem szabadít fel azonnal helyet az indexben. Néhány percenként egy háttérfolyamat végrehajtja a fizikai törlést. Függetlenül attól, hogy az Azure Portalt vagy egy API-t használ az indexstatisztikák visszaadásához, kis késésre számíthat, mielőtt a törlés megjelenik az Azure Portalon és az API-metrikákban.

1. Határozza meg, hogy melyik mező a dokumentumkulcs. Az Azure Portalon megtekintheti az egyes indexek mezőit. A dokumentumkulcsok sztringmezők, és kulcsikonnal vannak jelölve, hogy könnyebben észrevehetők legyenek.

2. Ellenőrizze a dokumentumkulcs mező értékeit: search=*&$select=HotelId. Az egyszerű sztringek egyszerűek, de ha az index egy base-64 kódolású mezőt használ, vagy ha keresési dokumentumokat hoztak létre egy parsingMode beállításból, előfordulhat, hogy olyan értékekkel dolgozik, amelyeket nem ismer.

3. Keresse meg a dokumentumot a dokumentumazonosító értékének ellenőrzéséhez és a dokumentum tartalmának áttekintéséhez a törlés előtt. Adja meg a kérés kulcsát vagy dokumentumazonosítóját. Az alábbi példák egy egyszerű sztringet mutatnak be a Hotels mintaindexhez , valamint egy base-64 kódolású sztringet a fogaskerék-keresés-demo index metadata_storage_path kulcsához.

   GET https://[service name].search.windows.net/indexes/hotel-sample-index/docs/1111?api-version=2024-07-01
   

   GET https://[service name].search.windows.net/indexes/cog-search-demo/docs/aHR0cHM6Ly9oZWlkaWJsb2JzdG9yYWdlMi5ibG9iLmNvcmUud2luZG93cy5uZXQvY29nLXNlYXJjaC1kZW1vL2d1dGhyaWUuanBn0?api-version=2024-07-01
   

4. Törölje a dokumentumot törléssel @search.action a keresési indexből való törléshez.

   POST https://[service name].search.windows.net/indexes/hotels-sample-index/docs/index?api-version=2024-07-01
   Content-Type: application/json   
   api-key: [admin key] 
   {  
     "value": [  
       {  
         "@search.action": "delete",  
         "id": "1111"  
       }  
     ]  
   }
   

Lásd még

• Az indexelő áttekintése
• Nagy méretű adathalmazok indexelése
• Indexelés az Azure Portalon
• Azure SQL Database indexelő
• Azure Cosmos DB for NoSQL indexelő
• Azure Blob Indexer
• Azure-táblák indexelője
• Biztonság az Azure AI Searchben