Adatok indexelése az Azure SQL-ből az Azure AI Searchben
Ebből a cikkből megtudhatja, hogyan konfigurálhat olyan indexelőt, amely tartalmat importál az Azure SQL Database-ből vagy egy felügyelt Azure SQL-példányból, és hogyan teszi kereshetővé az Azure AI Searchben.
Ez a cikk kiegészíti az Azure SQL-hez kapcsolódó információkat tartalmazó indexelő létrehozását. A REST API-k segítségével egy háromrészes munkafolyamatot mutat be, amely az összes indexelőre jellemző: adatforrás létrehozása, index létrehozása, indexelő létrehozása.
Ez a cikk a következőket is tartalmazza:
Az Azure SQL-indexelő által támogatott változásészlelési szabályzatok leírása a növekményes indexelés beállításához.
Gyakori kérdések (GYIK) szakasz a funkciókompatibilitással kapcsolatos kérdésekre adott válaszokhoz.
Feljegyzés
Indexelővel nem lehetséges valós idejű adatszinkronizálás. Az indexelők legfeljebb öt percenként újraindexelhetik a táblázatot. Ha az adatfrissítéseket előbb meg kell jeleníteni az indexben, javasoljuk, hogy közvetlenül nyomja le a frissített sorokat.
Előfeltételek
Egy Azure SQL-adatbázis egyetlen táblában vagy nézetben lévő adatokkal, vagy nyilvános végponttal rendelkező felügyelt SQL-példány.
Használjon táblát, ha az adatok nagyok, vagy ha növekményes indexelésre van szüksége az SQL natív változásészlelési képességeivel.
Ha több táblából szeretne adatokat összesíteni, használjon nézetet. A nagyméretű nézetek nem ideálisak az SQL-indexelők számára. Megkerülő megoldás egy új tábla létrehozása csak az Azure AI Search-indexbe való betöltéshez. Használhatja az SQL integrált változáskövetését, amely egyszerűbben implementálható, mint a High Water Mark.
Olvasási engedélyek. Az Azure AI Search támogatja az SQL Server-hitelesítést, ahol a felhasználónév és a jelszó meg van adva a kapcsolati sztring. Másik lehetőségként beállíthat egy felügyelt identitást, és azure-szerepköröket használhat.
A cikkben szereplő példák végigdolgozásához REST-ügyfélre van szükség.
Az Azure SQL-indexelők létrehozásának egyéb módjai közé tartoznak az Azure SDK-k vagy az Adatok importálása varázsló az Azure Portalon. Ha az Azure Portalt használja, győződjön meg arról, hogy az összes nyilvános hálózathoz való hozzáférés engedélyezve van az Azure SQL-tűzfalon, és hogy az ügyfél egy bejövő szabályon keresztül rendelkezik hozzáféréssel.
Az adatforrás meghatározása
Az adatforrás definíciója meghatározza az adatok indexeléséhez, hitelesítő adataihoz és szabályzataihoz az adatok változásainak azonosításához. Egy adatforrás független erőforrásként van definiálva, így több indexelő is használhatja.
Adatforrás létrehozása vagy adatforrás frissítése a definíció beállításához:
POST https://myservice.search.windows.net/datasources?api-version=2020-06-30 Content-Type: application/json api-key: admin-key { "name" : "myazuresqldatasource", "description" : "A database for testing Azure AI Search indexes.", "type" : "azuresql", "credentials" : { "connectionString" : "Server=tcp:<your server>.database.windows.net,1433;Database=<your database>;User ID=<your user name>;Password=<your password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" }, "container" : { "name" : "name of the table or view that you want to index", "query" : null (not supported in the Azure SQL indexer) }, "dataChangeDetectionPolicy": null, "dataDeletionDetectionPolicy": null, "encryptionKey": null, "identity": null }Adja meg az Azure AI Search elnevezési konvencióit követő adatforrás egyedi nevét.
Állítsa be a
"azuresql""type" (típus) értéket (kötelező).Állítsa be a "hitelesítő adatokat" egy kapcsolati sztring:
Az Azure Portalon teljes hozzáférésű kapcsolati sztring kaphat. Használja a
ADO.NET connection stringlehetőséget. Adja meg a felhasználónevet és a jelszót.Másik lehetőségként megadhat egy olyan felügyelt identitást kapcsolati sztring, amely nem tartalmaz adatbázis-titkos kulcsokat a következő formátumban:
Initial Catalog|Database=<your database name>;ResourceId=/subscriptions/<your subscription ID>/resourceGroups/<your resource group name>/providers/Microsoft.Sql/servers/<your SQL Server name>/;Connection Timeout=connection timeout length;.
További információ: Csatlakozás az Azure SQL Database indexelője számára felügyelt identitás használatával.
Keresési mezők hozzáadása indexhez
Keresési indexben adjon hozzá az SQL Database mezőinek megfelelő mezőket. Győződjön meg arról, hogy a keresési index sémája kompatibilis a forrássémával egyenértékű adattípusok használatával.
Hozzon létre vagy frissítsen egy indexet az adatokat tároló keresési mezők definiálásához:
POST https://[service name].search.windows.net/indexes?api-version=2020-06-30 Content-Type: application/json api-key: [Search service admin key] { "name": "mysearchindex", "fields": [{ "name": "id", "type": "Edm.String", "key": true, "searchable": false }, { "name": "description", "type": "Edm.String", "filterable": false, "searchable": true, "sortable": false, "facetable": false, "suggestions": true } ] }Hozzon létre egy dokumentumkulcsmezőt ("kulcs": igaz), amely egyedileg azonosítja az egyes keresési dokumentumokat. Ez az egyetlen kötelező mező a keresési indexben. A tábla elsődleges kulcsa általában az indexkulcs mezőre van leképezve. A dokumentumkulcsnak egyedinek és nem null értékűnek kell lennie. Az értékek lehetnek numerikusak a forrásadatokban, de egy keresési indexben a kulcs mindig sztring.
További mezők létrehozása több kereshető tartalom hozzáadásához. Útmutatásért tekintse meg az index létrehozása című témakört.
Adattípusok leképezése
| SQL-adattípus | Az Azure AI Search mezőtípusai | Jegyzetek |
|---|---|---|
| Kicsit | Edm.Boolean, Edm.String | |
| int, smallint, tinyint | Edm.Int32, Edm.Int64, Edm.String | |
| bigint | Edm.Int64, Edm.String | |
| valós, lebegőpontos | Edm.Double, Edm.String | |
| smallmoney, money decimal numerikus | Edm.String | Az Azure AI Search nem támogatja a decimális típusok Edm.Double konvertálását, mert ezzel elveszíti a pontosságot |
| char, nchar, varchar, nvarchar | Edm.String Collection(Edm.String) |
Egy SQL-sztring használható Gyűjtemény(Edm.String) mező kitöltésére, ha a sztring egy JSON-sztringtömböt jelöl: ["red", "white", "blue"] |
| smalldatetime, datetime, datetime2, date, datetimeoffset | Edm.DateTimeOffset, Edm.String | |
| uniqueidentifer | Edm.String | |
| Földrajz | Edm.GeographyPoint | Csak az SRID 4326 típusú POINT típusú földrajzi példányok támogatottak (ez az alapértelmezett) |
| rowversion | Nem alkalmazható | A sorverziós oszlopok nem tárolhatók a keresési indexben, de a változáskövetéshez használhatók |
| idő, idő, bináris, varbináris, kép, xml, geometria, CLR-típusok | Nem alkalmazható | Nem támogatott |
Az Azure SQL-indexelő konfigurálása és futtatása
Az index és az adatforrás létrehozása után készen áll az indexelő létrehozására. Az indexelő konfigurációja meghatározza a futási idő viselkedését vezérlő bemeneteket, paramétereket és tulajdonságokat.
Hozzon létre vagy frissítsen egy indexelőt úgy, hogy megad neki egy nevet, és hivatkozik az adatforrásra és a célindexre:
POST https://[service name].search.windows.net/indexers?api-version=2020-06-30 Content-Type: application/json api-key: [search service admin key] { "name" : "[my-sqldb-indexer]", "dataSourceName" : "[my-sqldb-ds]", "targetIndexName" : "[my-search-index]", "disabled": null, "schedule": null, "parameters": { "batchSize": null, "maxFailedItems": 0, "maxFailedItemsPerBatch": 0, "base64EncodeKeys": false, "configuration": { "queryTimeout": "00:04:00", "convertHighWaterMarkToRowVersion": false, "disableOrderByHighWaterMarkColumn": false } }, "fieldMappings": [], "encryptionKey": null }A paraméterek alatt a konfigurációs szakasz az Azure SQL-hez kapcsolódó paraméterekkel rendelkezik:
Az SQL-lekérdezések végrehajtásának alapértelmezett lekérdezési időtúllépése 5 perc, amelyet felülbírálhat.
A "convertHighWaterMarkToRowVersion" a High Water Mark változásészlelési szabályzatra optimalizál. A változásészlelési szabályzatok az adatforrásban vannak beállítva. Ha natív változásészlelési szabályzatot használ, ennek a paraméternek nincs hatása.
A "disableOrderByHighWaterMarkColumn" miatt a magas vízjel-szabályzat által használt SQL-lekérdezés kihagyja az ORDER BY záradékot. Ha natív változásészlelési szabályzatot használ, ennek a paraméternek nincs hatása.
Mezőleképezéseket adhat meg, ha a mezőnév vagy a típus eltérést mutat, vagy ha egy forrásmező több verziójára van szüksége a keresési indexben.
További információt az egyéb tulajdonságokról az Indexelő létrehozása című témakörben talál.
Az indexelő automatikusan fut a létrehozásakor. Ezt úgy akadályozhatja meg, hogy a "letiltva" értéket igaz értékre állítja. Az indexelő végrehajtásának szabályozásához futtasson egy indexelőt igény szerint , vagy ütemezze.
Az indexelő állapotának ellenőrzése
Az indexelőzmények állapotának és végrehajtási előzményeinek figyeléséhez küldjön egy indexelőzmény-lekéréses kérést:
GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2020-06-30
Content-Type: application/json
api-key: [admin key]
A válasz tartalmazza az állapotot és a feldolgozott elemek számát. A következő példához hasonlóan kell kinéznie:
{
"status":"running",
"lastResult": {
"status":"success",
"errorMessage":null,
"startTime":"2022-02-21T00:23:24.957Z",
"endTime":"2022-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
"executionHistory":
[
{
"status":"success",
"errorMessage":null,
"startTime":"2022-02-21T00:23:24.957Z",
"endTime":"2022-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
... earlier history items
]
}
A végrehajtási előzmények legfeljebb 50 legutóbbi végrehajtást tartalmaznak, amelyek fordított időrendi sorrendben vannak rendezve, hogy a legújabb végrehajtás legyen az első.
Új, módosított és törölt sorok indexelése
Ha az SQL-adatbázis támogatja a változáskövetést, a keresési indexelők csak az új és frissített tartalmakat tudják felvenni a későbbi indexelők futtatásakor.
A növekményes indexelés engedélyezéséhez állítsa be a "dataChangeDetectionPolicy" tulajdonságot az adatforrás definíciójában. Ez a tulajdonság jelzi az indexelőnek, hogy melyik változáskövetési mechanizmust használja a tábla vagy a nézet.
Az Azure SQL-indexelők esetében két változásészlelési szabályzat létezik:
"SqlIntegratedChangeTrackingPolicy" (csak táblákra vonatkozik)
"HighWaterMarkChangeDetectionPolicy" (táblákhoz és nézetekhez használható)
Integrált SQL-változáskövetési szabályzat
A "SqlIntegratedChangeTrackingPolicy" használatát javasoljuk a hatékonyság és a törölt sorok azonosításának képessége érdekében.
Adatbázisra vonatkozó követelmények:
- Ha SQL Servert használ az Azure-beli virtuális gépeken, akkor az SQL Server 2012 SP3 vagy újabb verziója szükséges
- Azure SQL Database vagy felügyelt SQL-példány
- Csak táblák (nézetek nélkül)
- Az adatbázisban engedélyezze a változáskövetést a táblához
- Nincs összetett elsődleges kulcs (egynél több oszlopot tartalmazó elsődleges kulcs) a táblában
- Nincsenek fürtözött indexek a táblában. Áthidaló megoldásként a fürtözött indexeket el kell vetni, és nemclustered indexként kell újra létrehozni, azonban a forrás teljesítménye hatással lehet a fürtözött indexekhez képest
A változásészlelési szabályzatok hozzá lesznek adva az adatforrás-definíciókhoz. A szabályzat használatához hozza létre vagy frissítse az adatforrást a következő módon:
POST https://myservice.search.windows.net/datasources?api-version=2020-06-30
Content-Type: application/json
api-key: admin-key
{
"name" : "myazuresqldatasource",
"type" : "azuresql",
"credentials" : { "connectionString" : "connection string" },
"container" : { "name" : "table name" },
"dataChangeDetectionPolicy" : {
"@odata.type" : "#Microsoft.Azure.Search.SqlIntegratedChangeTrackingPolicy"
}
Az SQL integrált változáskövetési szabályzat használatakor ne adjon meg külön adattörlési észlelési szabályzatot. Az SQL integrált változáskövetési szabályzata beépített támogatást nyújt a törölt sorok azonosításához. Ahhoz azonban, hogy a törölt sorok automatikusan észlelhetők legyenek, a keresési index dokumentumkulcsának meg kell egyeznie az SQL-tábla elsődleges kulcsával.
Feljegyzés
Ha a TRUNCATE TABLE használatával nagy számú sort távolít el egy SQL-táblából, az indexelőt alaphelyzetbe kell állítani a változáskövetési állapot alaphelyzetbe állításához a sorok törlésének felvételéhez.
Magas vízjelek változásészlelési szabályzata
Ez a változásészlelési szabályzat a tábla vagy nézet "magas vízjel" oszlopára támaszkodik, amely rögzíti a sor utolsó frissítésének verzióját vagy időpontját. Ha nézetet használ, magas vízjel-szabályzatot kell használnia.
A magas vízjel oszlopnak meg kell felelnie a következő követelményeknek:
- Minden beszúrás megadja az oszlop értékét.
- Az elem minden frissítése az oszlop értékét is módosítja.
- Az oszlop értéke minden beszúrással vagy frissítéssel nő.
- A következő WHERE és ORDER BY záradékkal rendelkező lekérdezések hatékonyan végrehajthatók:
WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]
Feljegyzés
Határozottan javasoljuk, hogy használja a rowversion adattípust a magas vízjel oszlophoz. Ha bármilyen más adattípust használ, a változáskövetés nem garantáltan rögzíti az indexelő lekérdezéssel egyidejűleg végrehajtott tranzakciók összes módosítását. Ha csak olvasható replikákkal rendelkező konfigurációban használ sorverziót , az indexelőt az elsődleges replikára kell mutatnia. Adatszinkronizálási forgatókönyvekhez csak elsődleges replika használható.
A változásészlelési szabályzatok hozzá lesznek adva az adatforrás-definíciókhoz. A szabályzat használatához hozza létre vagy frissítse az adatforrást a következő módon:
POST https://myservice.search.windows.net/datasources?api-version=2020-06-30
Content-Type: application/json
api-key: admin-key
{
"name" : "myazuresqldatasource",
"type" : "azuresql",
"credentials" : { "connectionString" : "connection string" },
"container" : { "name" : "table or view name" },
"dataChangeDetectionPolicy" : {
"@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
"highWaterMarkColumnName" : "[a rowversion or last_updated column name]"
}
}
Feljegyzés
Ha a forrástábla nem rendelkezik indexel a magas vízjel oszlopban, az SQL-indexelő által használt lekérdezések időtúllépést okozhatnak. A záradék megköveteli, hogy az ORDER BY [High Water Mark Column] index hatékonyan fusson, ha a tábla sok sort tartalmaz.
convertHighWaterMarkToRowVersion
Ha rowversion adattípust használ a magas vízjel oszlophoz, fontolja meg a convertHighWaterMarkToRowVersion tulajdonság indexelőkonfigurációjában való beállítását. A tulajdonság igaz értékre állítása az alábbi viselkedéseket eredményezi:
A rowversion adattípust használja az indexelő SQL-lekérdezés magas vízjel oszlopához. A megfelelő adattípus használata javítja az indexelő lekérdezés teljesítményét.
Kivon egyet a rowversion értékből az indexelő lekérdezés futtatása előtt. Az egy-a-többhöz illesztésű nézetekben ismétlődő sorfordítási értékekkel rendelkező sorok lehetnek. Az egyik kivonásával biztosítható, hogy az indexelő lekérdezés ne hagyja ki ezeket a sorokat.
A tulajdonság engedélyezéséhez hozza létre vagy frissítse az indexelőt a következő konfigurációval:
{
... other indexer definition properties
"parameters" : {
"configuration" : { "convertHighWaterMarkToRowVersion" : true } }
}
queryTimeout
Ha időtúllépési hibákba ütközik, állítsa az queryTimeout indexelő konfigurációs beállítását az alapértelmezett 5 perces időtúllépésnél magasabb értékre. Ha például 10 percre szeretné beállítani az időtúllépést, hozza létre vagy frissítse az indexelőt a következő konfigurációval:
{
... other indexer definition properties
"parameters" : {
"configuration" : { "queryTimeout" : "00:10:00" } }
}
disableOrderByHighWaterMarkColumn
A záradékot ORDER BY [High Water Mark Column] is letilthatja. Ez azonban nem ajánlott, mert ha az indexelő végrehajtását hiba szakítja meg, az indexelőnek újra kell feldolgoznia az összes sort, ha később fut, még akkor sem, ha az indexelő a megszakítás időpontjában szinte az összes sort feldolgozta. A ORDER BY záradék letiltásához használja az disableOrderByHighWaterMarkColumn indexelő definíciójának beállítását:
{
... other indexer definition properties
"parameters" : {
"configuration" : { "disableOrderByHighWaterMarkColumn" : true } }
}
Helyreállítható törlési oszloptörlési észlelési szabályzat
Ha sorokat töröl a forrástáblából, valószínűleg ezeket a sorokat is törölni szeretné a keresési indexből. Ha az SQL integrált változáskövetési szabályzatát használja, ez az Ön feladata. A magas vízjelek változáskövetési szabályzata azonban nem segít a törölt sorokban. Mi a teendő?
Ha a sorok fizikailag törlődnek a táblából, az Azure AI Search nem tudja kikövetkeztetni a már nem létező rekordok jelenlétét. A "helyreállítható törlés" technikával azonban logikailag törölheti a sorokat anélkül, hogy eltávolítaná őket a táblából. Adjon hozzá egy oszlopot a táblához, vagy tekintse meg és jelölje meg a sorokat töröltként az adott oszlop használatával.
A helyreállítható törlési technika használata esetén az adatforrás létrehozásakor vagy frissítésekor az alábbiak szerint adhatja meg a helyreállítható törlési szabályzatot:
{
…,
"dataDeletionDetectionPolicy" : {
"@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
"softDeleteColumnName" : "[a column name]",
"softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
}
}
A softDeleteMarkerValue-nak sztringnek kell lennie az adatforrás JSON-ábrázolásában. Használja a tényleges érték sztring-ábrázolását. Ha például van egy egész szám oszlopa, amelyben a törölt sorok 1 értékkel vannak megjelölve, használja a következőt "1": . Ha van egy BIT oszlopa, amelyben a törölt sorok logikai igaz értékkel vannak megjelölve, használja a sztringkonstanst "True" , vagy "true"az eset nem számít.
Ha helyreállítható törlési szabályzatot állít be az Azure Portalról, ne adjon hozzá idézőjeleket a helyreállítható törlési jelölő értékéhez. A mező tartalma már sztringként van értelmezve, és automatikusan JSON-sztringgé lesz lefordítva. A fenti példákban egyszerűen írja be 1vagy Truetrue írja be a portál mezőjét.
GYIK
K: Indexelhetem az Always Encrypted oszlopokat?
Szám Az Always Encrypted oszlopokat jelenleg nem támogatják az Azure AI Search-indexelők.
K: Használhatom az Azure SQL Indexert az Azure-beli IaaS virtuális gépeken futó SQL-adatbázisokkal?
Igen. Engedélyeznie kell azonban, hogy a keresési szolgáltatás csatlakozzon az adatbázishoz. További információ: Kapcsolat konfigurálása Azure AI Search-indexelő és SQL Server között azure-beli virtuális gépen.
K: Használhatom az Azure SQL Indexert helyszíni SQL-adatbázisokkal?
Közvetlenül nem. Nem javasoljuk vagy nem támogatjuk a közvetlen kapcsolatot, mivel ehhez meg kell nyitnia az adatbázisokat az internetes forgalom számára. Az ügyfelek sikeresen alkalmazták ezt a forgatókönyvet olyan hídtechnológiák használatával, mint az Azure Data Factory. További információ: Adatok leküldése Azure AI Search-indexbe az Azure Data Factory használatával.
K: Használhatok másodlagos replikát egy feladatátvevő fürtben adatforrásként?
Ez a konkrét licenctől függ. Egy tábla vagy nézet teljes indexeléséhez használhat másodlagos replikát.
A növekményes indexeléshez az Azure AI Search két változásészlelési szabályzatot támogat: az SQL integrált változáskövetését és a Magas vízjelet.
Írásvédett replikákon az SQL Database nem támogatja az integrált változáskövetést. Ezért magas vízjel szabályzatot kell használnia.
Standard javaslatunk a rowversion adattípus használata a magas vízjel oszlophoz. A rowversion használata azonban a MIN_ACTIVE_ROWVERSION függvényre támaszkodik, amely nem támogatott írásvédett replikákon. Ezért az indexelőt egy elsődleges replikára kell mutatnia, ha sorfordítást használ.
Ha csak olvasható replikán próbálja meg használni a rowversion-t, a következő hibaüzenet jelenik meg:
"A rowversion oszlop használata a változáskövetéshez nem támogatott másodlagos (írásvédett) rendelkezésre állási replikákon. Frissítse az adatforrást, és adjon meg egy kapcsolatot az elsődleges rendelkezésre állási replikával. Az adatbázis frissíthetőségének jelenlegi tulajdonsága a "READ_ONLY".
K: Használhatok alternatív, nem sorirányú oszlopot a magas vízjelek változáskövetéséhez?
Nem ajánlott. Csak a rowversion teszi lehetővé a megbízható adatszinkronizálást. Az alkalmazáslogikától függően azonban biztonságos lehet, ha:
Meggyőződhet arról, hogy az indexelő futtatásakor nincsenek függőben lévő tranzakciók az indexelt táblán (például az összes táblafrissítés kötegként történik egy ütemezésben, és az Azure AI Search indexelő ütemezése úgy van beállítva, hogy ne legyen átfedésben a táblafrissítés ütemezésével).
Rendszeresen teljes újraindexelést hajt végre a kihagyott sorok felvételéhez.