Adatok indexelése az Azure SQL Database-ből

A Azure SQL indexelő tartalmat importál az Azure SQL Database-ből vagy az Azure SQL Managed Instance-ből az Azure AI Keresés egyik indexébe.

Ez a cikk kiegészíti az Azure SQL-hez kapcsolódó információkat tartalmazó indexelő létrehozását. Az Azure Portal és a REST API-k használatával 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. Az adatkinyerés az Indexelő létrehozása kérés elküldésekor történik.

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.

Előfeltételek

• Nyilvános végponttal rendelkező Azure SQL-adatbázis vagy felügyelt SQL-példány.

• Egyetlen tábla vagy nézet.

  Használjon táblázatot, 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 (integrált SQL-változáskövetés), hogy tükrözze a keresési index új, módosított és törölt sorait.

  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. Az egyik megoldás egy új tábla létrehozása kifejezetten az Azure AI Keresés-indexbe való betöltéshez. Ha a nézet mellett dönt, használhatja a Magas vízjelet a változásészleléshez, de a törlésészleléshez kerülő megoldást kell használnia.

• Az elsődleges kulcsnak egyértékűnek kell lennie. Az asztalon fürtözésmentesnek kell lennie a teljes SQL integrált változáskövetéshez.

• Olvasási engedélyek. Az Azure AI Keresés támogatja az SQL Server hitelesítést, amelynél a felhasználónév és a jelszó megadva vannak a kapcsolati karakterláncban. Másik lehetőségként beállíthat egy felügyelt identitást, és azure-szerepköröket használhatSQL Server-közreműködői vagy SQL DB-közreműködői szerepkörök tagságával.

A cikkben szereplő példák végigdolgozásához az Azure Portalra vagy egy REST-ügyfélre van szükség. 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. Helyileg futó REST-ügyfél esetén konfigurálja az SQL Server tűzfalát, hogy engedélyezze a bejövő hozzáférést az eszköz IP-címéről. Az Azure SQL-indexelők létrehozásának egyéb megközelítései közé tartoznak az Azure SDK-k.

Kipróbálás mintaadatokkal

Ezeket az utasításokat követve létrehozhat és betölthet egy táblát az Azure SQL Database-ben tesztelési célokra.

1. Töltse le hotels-azure-sql.sql a GitHubról, és hozzon létre egy táblát az Azure SQL Database-ben, amely a szállodai mintaadatkészlet egy részhalmazát tartalmazza.

2. Jelentkezzen be az Azure Portalra, és hozzon létre egy Azure SQL-adatbázist és adatbázis-kiszolgálót. Fontolja meg az SQL Server-hitelesítés és a Microsoft Entra ID-hitelesítés konfigurálását. Ha nincs engedélye szerepkörök konfigurálására az Azure-ban, megkerülő megoldásként használhatja az SQL-hitelesítést.

3. Konfigurálja a kiszolgálói tűzfalat a helyi eszközről érkező összes bejövő kérésre.

4. Az Azure SQL-adatbázisban válassza a Lekérdezésszerkesztőt (előzetes verzió), majd az Új lekérdezés lehetőséget.

5. Illessze be, majd futtassa a szállodatáblát létrehozó T-SQL-szkriptet. Az SQL-be integrált változáskövetéshez nem fürtözött elsődleges kulcs szükséges.

   CREATE TABLE tbl_hotels
    (
        Id TINYINT PRIMARY KEY NONCLUSTERED,
        Modified DateTime NULL DEFAULT CURRENT_TIMESTAMP,
        IsDeleted TINYINT,
        HotelName VARCHAR(40),
        Category VARCHAR(20),
        City VARCHAR(30),
        State VARCHAR(4),
        Description VARCHAR(500)
    );
   

6. Illessze be és futtassa a rekordokat beszúró T-SQL-szkriptet.

    -- Insert rows
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (1, CURRENT_TIMESTAMP, 0,  'Stay-Kay City Hotel', 'Boutique', 'New York', 'NY', 'This classic hotel is fully-refurbished and ideally located on the main commercial artery of the city in the heart of New York. A few minutes away is Times Square and the historic centre of the city, as well as other places of interest that make New York one of Americas most attractive and cosmopolitan cities.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (10, CURRENT_TIMESTAMP, 0, 'Countryside Hotel', 'Extended-Stay', 'Durham', 'NC', 'Save up to 50% off traditional hotels. Free WiFi, great location near downtown, full kitchen, washer & dryer, 24\/7 support, bowling alley, fitness center and more.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (11, CURRENT_TIMESTAMP, 0, 'Royal Cottage Resort', 'Extended-Stay', 'Bothell', 'WA', 'Your home away from home. Brand new fully equipped premium rooms, fast WiFi, full kitchen, washer & dryer, fitness center. Inner courtyard includes water features and outdoor seating. All units include fireplaces and small outdoor balconies. Pets accepted.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (12, CURRENT_TIMESTAMP, 0, 'Winter Panorama Resort', 'Resort and Spa', 'Wilsonville', 'OR', 'Plenty of great skiing, outdoor ice skating, sleigh rides, tubing and snow biking. Yoga, group exercise classes and outdoor hockey are available year-round, plus numerous options for shopping as well as great spa services. Newly-renovated with large rooms, free 24-hr airport shuttle & a new restaurant. Rooms\/suites offer mini-fridges & 49-inch HDTVs.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (13, CURRENT_TIMESTAMP, 0, 'Luxury Lion Resort', 'Luxury', 'St. Louis', 'MO', 'Unmatched Luxury. Visit our downtown hotel to indulge in luxury accommodations. Moments from the stadium and transportation hubs, we feature the best in convenience and comfort.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (14, CURRENT_TIMESTAMP, 0, 'Twin Vortex Hotel', 'Luxury', 'Dallas', 'TX', 'New experience in the making. Be the first to experience the luxury of the Twin Vortex. Reserve one of our newly-renovated guest rooms today.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (15, CURRENT_TIMESTAMP, 0, 'By the Market Hotel', 'Budget', 'New York', 'NY', 'Book now and Save up to 30%. Central location. Walking distance from the Empire State Building & Times Square, in the Chelsea neighborhood. Brand new rooms. Impeccable service.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (16, CURRENT_TIMESTAMP, 0, 'Double Sanctuary Resort', 'Resort and Spa', 'Seattle', 'WA', '5 Star Luxury Hotel - Biggest Rooms in the city. #1 Hotel in the area listed by Traveler magazine. Free WiFi, Flexible check in\/out, Fitness Center & espresso in room.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (17, CURRENT_TIMESTAMP, 0, 'City Skyline Antiquity Hotel', 'Boutique', 'New York', 'NY', 'In vogue since 1888, the Antiquity Hotel takes you back to bygone era. From the crystal chandeliers that adorn the Green Room, to the arched ceilings of the Grand Hall, the elegance of old New York beckons. Elevate Your Experience. Upgrade to a premiere city skyline view for less, where old world charm combines with dramatic views of the city, local cathedral and midtown.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (18, CURRENT_TIMESTAMP, 0, 'Ocean Water Resort & Spa', 'Luxury', 'Tampa', 'FL', 'New Luxury Hotel for the vacation of a lifetime. Bay views from every room, location near the pier, rooftop pool, waterfront dining & more.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (19, CURRENT_TIMESTAMP, 0, 'Economy Universe Motel', 'Budget', 'Redmond', 'WA', 'Local, family-run hotel in bustling downtown Redmond. We are a pet-friendly establishment, near expansive Marymoor park, haven to pet owners, joggers, and sports enthusiasts. Close to the highway and just a short drive away from major cities.');
    INSERT INTO tbl_hotels (Id, Modified, IsDeleted, HotelName, Category, City, State, Description) VALUES (20, CURRENT_TIMESTAMP, 0, 'Delete Me Hotel', 'Unknown', 'Nowhere', 'XX', 'Test-case row for change detection and delete detection. For change detection, modify any value, and then re-run the indexer. For soft-delete, change IsDeleted from zero to a one, and then re-run the indexer.');
   
   

7. A feltöltés megerősítéséhez futtasson egy lekérdezést.

   SELECT Description FROM tbl_hotels;
   

   Az alábbi képernyőképhez hasonló eredményeket kell látnia.

   

A Leírás mező a legigértelmesebb tartalmat biztosítja. Ezt a mezőt a teljes szöveges keresésre és az opcionális vektorizálásra kell céloznia.

Most, hogy már rendelkezik adatbázistáblával, az Azure Portal, a REST-ügyfél vagy az Azure SDK használatával indexelheti az adatokat.

Az indexelő folyamat beállítása

Ebben a lépésben adja meg az adatforrást, az indexet és az indexelőt.

Az indexelő állapotának ellenőrzése

Az indexelőzmények állapotának és végrehajtási előzményeinek monitorozásához ellenőrizze az indexelőzményeket az Azure Portalon, vagy küldjön egy Indexelőzmények állapotának lekérése REST API-kérést

GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2026-04-01
  Content-Type: application/json  
  api-key: [admin key]

    {
        "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 (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:

• Azure SQL Database vagy SQL Managed Instance. Azure-beli virtuális gép használata esetén az SQL Server 2016-os vagy újabb verziója.
• Az adatbázisnak engedélyeznie kell a változáskövetést
• Csak táblák (nézetek nélkül).
• A táblák nem csoportosíthatók. Ennek a követelménynek a teljesítéséhez törölje a fürtözött indexet, és hozza létre újra nem fürtözött indexként. Ez a kerülő megoldás gyakran rontja a teljesítményt. Az indexelők feldolgozására dedikált második táblázatban lévő tartalom duplikálása hasznos megoldás lehet.
• A táblázatok nem lehetnek üresek. Ha TRUNCATE TABLE használatával törli a sorokat, az indexelő alaphelyzetbe állítása és újrafuttatása nem távolítja el a megfelelő keresési dokumentumokat. A keresési dokumentumok eltávolításához árván, meg kell indexelnie őket egy törlési művelettel.
• Az elsődleges kulcs nem lehet összetett kulcs (egynél több oszlopot tartalmaz).
• Az elsődleges kulcsnak nem klaszterezettnek kell lennie, ha törlési észlelést szeretne.

A változásészlelési szabályzatok hozzá lesznek adva az adatforrás-definíciókhoz. A szabályzat használatához szerkessze az adatforrás definícióját az Azure Portalon, vagy a REST használatával frissítse az adatforrást az alábbi módon:

POST https://myservice.search.windows.net/datasources?api-version=2026-04-01
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, és az elsődleges kulcsnak nem fürtözöttnek kell lennie.

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, csúcsérték-politikát kell alkalmaznia.

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]

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=2026-04-01
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]"
        }
    }

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 összekapcsolásokkal rendelkező nézetek tartalmazhatnak ismétlődő verzióértékekkel bíró sorokat. 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 adja hozzá a következő parameters tulajdonságot az indexelő létrehozásakor vagy frissítésekor:

{
    "parameters": {
        "configuration": {
            "convertHighWaterMarkToRowVersion": true
        }
    }
}

lekérdezési időkorlát

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, adja hozzá a következő parameters tulajdonságot az indexelő létrehozásakor vagy frissítésekor:

{
    "parameters": {
        "configuration": {
            "queryTimeout": "00:10:00"
        }
    }
}

letiltOrderByHighWaterMarkOszlop

Ezt a(z) ORDER BY [High Water Mark Column] záradékot is kikapcsolhatja. Ez a művelet 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 is, ha az indexelő a megszakítás időpontjában szinte az összes sort feldolgozta.

A ORDER BY záradék letiltásához adja hozzá a következő parameters tulajdonságot az indexelő létrehozásakor vagy frissítésekor:

{
    "parameters": {
        "configuration": {
            "disableOrderByHighWaterMarkColumn": true
        }
    }
}

Lágy törlés oszlop törlésének é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 számára meg van oldva. 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 Keresés nem tudja kikövetkeztetni a már nem létező rekordok jelenlétét. A "puha törlés" technikával azonban logikailag törölheti a sorokat a táblából való fizikai eltávolítás nélkü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álatakor adja hozzá a következő dataDeletionDetectionPolicy tulajdonságot az adatforrás létrehozásakor vagy frissítésekor:

{
    "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 karakterlánc-reprezentációjá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 szöveges literált "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. Az előző példákban egyszerűen írja be a 1, True vagy true az Azure portál mezőjébe.

GYIK

K: Indexelhetem az Always Encrypted oszlopokat?

Nem, az Always Encrypted oszlopokat jelenleg nem támogatják az Azure AI Keresés-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óért lásd: Az Azure AI Keresés indexelő és az Azure VM-en futó SQL Server közötti kapcsolat konfigurálása.

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 Keresés-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 Keresés 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 a High Water Mark szabályzatot kell használnia.

Szokásos javaslatunk az, hogy a rowversion adattípust használjuk a határérték 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 irányítania, ha sorverziót 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) elérhetőségi példányokon. 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 Keresés 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 az esetlegesen kihagyott sorok felkutatására.