Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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.
Éles környezetben már működő alkalmazások sémamódosításakor javasoljuk, hogy hozzon létre és teszteljen egy új indexet, amely párhuzamosan fut egy meglévő indexszel. 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 index tartalmának REST API-val történő hozzáadására, eltávolítására vagy felülírására 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 kérésen belül az index minden dokumentuma a következő:
- Egyedi kis- és nagybetű-érzékeny kulcs által azonosítva.
- Művelethez társítva: "feltöltés", "törlés", "összevonás" vagy "összevonás vagy feltöltés".
- A hozzáadott vagy frissített mezőkhöz tartozó név-érték párok készletével van feltöltve.
{
"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 (name/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.actionaz API-n a meglévő dokumentumokra gyakorolt hatás meghatározásához.Művelet Hatály töröl 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ít Frissíti a már létező dokumentumot, és sikertelen, ha a dokumentum nem található. 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 egytagsmező egy["budget"]értékkel kezdődik, és végrehajt egyesítést["economy", "pool"]-val/vel, akkor atagsmező végső értéke["economy", "pool"]. Nem lesz["budget", "economy", "pool"].
Ugyanez a viselkedés összetett gyűjteményekre is vonatkozik. Ha a dokumentum tartalmaz egy Szobák nevű összetett gyűjteménymezőt, amelynek értéke[{ "Type": "Budget Room", "BaseRate": 75.0 }], és végrehajt egy egyesítést egy[{ "Type": "Standard Room" }, { "Type": "Budget Room", "BaseRate": 60.5 }]értékkel, akkor a Szobák mező végső értéke[{ "Type": "Standard Room" }, { "Type": "Budget Room", "BaseRate": 60.5 }]lesz. Új és meglévő értékek hozzáfűzése és egyesítése nem fog sikerülni.egyesítés vagy feltöltés Ú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. feltölt Hasonló egy olyan művelethez, ahol a dokumentum beillesztésre kerül, ha új, és frissítésre vagy cserére, ha már létezik. 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, viszont ha meglévő mezőket frissít vagy eltávolít, számíthat vegyes eredményekre és a korlátozás gyakoribb előfordulására.
Feljegyzés
Nincsenek olyan végrehajtási sorrend garanciák, amelyek biztosítanák, hogy a kérelem törzsében melyik műveletet hajtják végre először. Nem ajánlott több "egyesítési" műveletet társítani ugyanahhoz a dokumentumhoz egyetlen kérelemtörzsben. Ha több "egyesítési" műveletre van szükség ugyanahhoz a dokumentumhoz, végezze el az egyesítést az ügyféloldalon, mielőtt frissítené a dokumentumot a keresési indexben.
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.
| Állapotkód | Értelmezés | Újrapróbálható | Jegyzetek |
|---|---|---|---|
| 200 | A dokumentum módosítása vagy törlése sikeresen megtörtént. | n.a. | A törlési műveletek idempotensek. Vagyis még ha egy dokumentumkulcs nem is létezik az indexben, a törlési művelet megkísérlése ezzel a kulccsal 200-as állapotkódot eredményez. |
| 201 | A dokumentum létrehozása sikeresen megtörtént. | n.a. | |
| 400 | Hiba történt a dokumentumban, amely megakadályozta az indexelést. | Nem | A válaszban megjelenő hibaüzenet jelzi, hogy mi a probléma a dokumentummal. |
| 404 | A dokumentum nem egyesíthető, mert a megadott kulcs nem létezik az indexben. | Nem | Ez a hiba nem fordul elő a feltöltések esetében, mivel új dokumentumokat hoznak létre, és nem törlődnek, mert idempotensek. |
| 409 | A rendszer verzióütközést észlelt egy dokumentum indexelésének megkísérlésekor. | Igen | Ez akkor fordulhat elő, ha ugyanazt a dokumentumot egy időben többször próbálja indexelni. |
| 422 | Az index átmenetileg nem érhető el, mert „true” (igaz) értékű allowIndexDowntime jelölővel lett frissítve. | Igen | |
| 429 | Túl sok kérés | Igen | Ha ezt a hibakódot az indexelés során kapja meg, az általában azt jelenti, hogy kevés a tárterület. A tárterületkorlátok közeledtével a szolgáltatás olyan állapotba léphet, amelyben nem vehet fel vagy nem frissíthet, amíg nem töröl néhány dokumentumot. További információ: Kapacitás megtervezése és kezelése , ha több tárterületre van szüksége, vagy szabadítson fel helyet a dokumentumok törlésével. |
| 503 | A keresési szolgáltatás átmenetileg nem érhető el, valószínűleg nagy terhelés miatt. | Igen | Ebben az esetben a kódnak várnia kell az újrapróbálkozás előtt, különben fennáll a veszélye, hogy a szolgáltatás továbbra sem lesz elérhető. |
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 csökkenté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 az indexenkénti dokumentumok számával kapcsolatos kvótát. Magasabb kapacitáskorlátokra kell frissítenie , vagy létre kell hoznia egy új indexet.
Feljegyzés
Amikor időzóna-adatokat tartalmazó értékeket tölt fel DateTimeOffset az indexbe, az Azure AI Search normalizálja ezeket az értékeket UTC értékre. A 2024-01-13T14:03:00-08:00 például 2024-01-13T22:03:00Z néven van tárolva. Ha időzóna-információkat kell tárolnia, adjon hozzá egy további oszlopot az indexhez ehhez az adatponthoz.
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
mergeOrUploadkeresési műveletként.Az adatcsomagnak 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
storedtulajdonsá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. Astoredhamissá állításának egyik mellékhatása, hogy a vektorok elvesznek egy újraindexelési művelet során. A vektor megadása a dokumentumok adathordozójában 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 soron belüli módosításokat karakterlánc-gyűjteménybe szeretné egyesíteni, adja meg a teljes értéket. Idézze fel az
tagselő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.
- Indexleírás hozzáadása (előzetes verzió)
- Új mező hozzáadása
- Az
retrievableattribútum beállítása egy meglévő mezőben - Frissítse a
searchAnalyzerértékét egy meglévőindexAnalyzermezőn. - Ú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ő:
Módosítsa a sémát az előző lista frissítéseivel.
Frissítse az indexsémát a keresési szolgáltatásban.
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.
| Művelet | Leírás |
|---|---|
| Mező törlése | Egy mező összes nyomának fizikai eltávolításához újra kell építenie az indexet. Ha az azonnali újraépítés nem praktikus, módosíthatja az alkalmazás kódját, hogy átirányítsa a hozzáférést egy elavult mezőről, vagy használja a searchFields parancsot , és válassza ki a lekérdezési paramétereket, hogy kiválassza a keresett és visszaadott mezőket. Fizikailag a meződefiníció és a tartalom az indexben marad a következő újraépítésig, amikor olyan sémát alkalmaz, amely kihagyja a szóban forgó mezőt. |
| Meződefiníció módosítása | A mezőnév, adattípus vagy adott indexattribútumok (kereshető, szűrhető, rendezhető, facetable) korrektúrái teljes újraépítést igényelnek. |
| Egy elemző hozzárendelése a mezőhöz | Az elemzők egy indexben vannak definiálva, mezőkhöz vannak rendelve, majd meghívhatók az indexelés során, hogy tájékoztassák a jogkivonatok létrehozásának módját. Az indexhez bármikor hozzáadhat új elemződefiníciót, de csak a mező létrehozásakor rendelhet hozzá elemzőt. Ez az elemző és az indexAnalyzer tulajdonságaira is igaz. A searchAnalyzer tulajdonság kivétel (ezt a tulajdonságot hozzárendelheti egy meglévő mezőhöz). |
| Elemződefiníció frissítése vagy törlése egy indexben | A meglévő elemzőkonfigurációkat (elemző, tokenizáló, tokenszűrő vagy karakterszűrő) nem lehet törölni vagy módosítani az indexben, hacsak nem építi újra a teljes indexet. |
| Mező hozzáadása javaslattevőhöz | Ha egy mező már létezik, és hozzá szeretné adni egy Javaslattevő-szerkezethez , építse újra az indexet. |
| A szolgáltatás vagy a szint frissítése | Ha több kapacitásra van szüksége, ellenőrizze, hogy frissítheti-e a szolgáltatást , vagy átválthat-e magasabb tarifacsomagra. Ha nem, létre kell hoznia egy új szolgáltatást, és újra kell építenie az indexeket az alapoktól. A folyamat automatizálásához használhat olyan kódmintát, amely JSON-fájlok sorozatára készít biztonsági másolatot az indexről. Ezután létrehozhatja az indexet egy ön által megadott keresési szolgáltatásban. |
A műveletek sorrendje a következő:
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.
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.
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.
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.
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.
Indexleírás hozzáadása (előzetes verzió)
A REST API 2025-05-01 előzetes verziójától kezdve az a ddescription verzió már támogatott. Ez az ember által olvasható szöveg felbecsülhetetlen értékű, ha egy rendszernek több indexhez kell hozzáférnie, és a leírás alapján döntést kell hoznia. Fontolja meg a Model Context Protocol (MCP) kiszolgálót, amely futásidőben a megfelelő indexet kell kiválasztania. A döntés a leíráson alapulhat, nem csak az index neve alapján.
Az index leírása sémafrissítés, és hozzáadhatja anélkül, hogy újra kellene építenie a teljes indexet.
- A sztring hossza legfeljebb 4000 karakter lehet.
- A tartalomnak emberi olvasásra alkalmasnak kell lennie Unicode-ban. A használati esetnek meg kell határoznia, hogy melyik nyelvet használja.
Az index leírásának támogatása az előzetes REST API-ban, az Azure Portalon vagy a funkciót biztosító előzetes Azure SDK-csomagban érhető el.
Az Azure Portal támogatja a legújabb előzetes verziójú API-t.
Jelentkezzen be az Azure Portalra, és keresse meg a keresési szolgáltatást.
A Kereséskezelési>indexek csoportban válasszon ki egy indexet.
Válassza a JSON szerkesztése lehetőséget.
Szúrja be
"description", majd a leírást. Az értéknek 4000 karakternél kisebbnek kell lennie, unicode formátumban.
Mentse az indexet.
Munkaterhelések 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, használja a select parancsot, hogy lekérje azt 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.
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.
Ellenőrizze a dokumentumkulcs mező értékeit:
search=*&$select=HotelId. Az egyszerű karakterláncok egyértelműek, de ha az index egy base-64 kódolású mezőt használ, vagy ha keresési dokumentumokat hoztak létre egyparsingModebeállításból, előfordulhat, hogy olyan értékekkel dolgozik, amelyekkel nem feltétlenül van tisztában.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ű karakterláncot mutatnak be a Hotels mintaindexhez, valamint egy base-64 kódolású karakterláncot a cog-search-demo index metadata_storage_path kulcsához.
GET https://[service name].search.windows.net/indexes/hotel-sample-index/docs/1111?api-version=2024-07-01GET https://[service name].search.windows.net/indexes/cog-search-demo/docs/aHR0cHM6Ly9oZWlkaWJsb2JzdG9yYWdlMi5ibG9iLmNvcmUud2luZG93cy5uZXQvY29nLXNlYXJjaC1kZW1vL2d1dGhyaWUuanBn0?api-version=2024-07-01Törölje a dokumentumot egy törlési funkcióval
@search.actiona keresési indexből való eltávolításhoz.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" } ] }