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

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. 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

• 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. Az SQL integrált változáskövetési funkcióval nyomon követheti az új és módosított sorokat, amelyek implementálása egyszerűbb, 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 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 hoteltáblát létrehozó T-SQL-szkriptet.

   CREATE TABLE tbl_hotels
    (
        Id TINYINT PRIMARY KEY,
        Modified DateTime NULL DEFAULT '0000-00-00 00:00:00',
        IsDeleted TINYINT,
        HotelName VARCHAR(40),
        Category VARCHAR(20),
        City VARCHAR(30),
        State VARCHAR(4),
        Description VARCHAR(500)
    );
   

6. Illessze be, majd 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 IsDelete 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éshez és az opcionális vektorizáláshoz kell megcélznia.

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 Azure Portal használata

Az Adatok importálása varázslóval vagy az Adatok importálása és vektorizálása varázslóval automatizálhatja az indexelést egy SQL-adatbázistáblából vagy nézetből. Az adatforrás konfigurációja mindkét varázsló esetében hasonló.

1. Indítsa el a varázslót.

2. Az adatokhoz való csatlakozás során válassza ki vagy ellenőrizze, hogy az adatforrás típusa azure SQL Database vagy SQL-adatbázis-e.

   Az adatforrás neve az Azure AI Search adatforrás-kapcsolati objektumára hivatkozik. Ha a vektorvarázslót használja, az adatforrás neve automatikusan létrejön a varázsló munkafolyamatának végén megadott egyéni előtaggal.

3. Adja meg a kiszolgáló nevét, az adatbázis nevét, valamint a tábla vagy a nézet nevét.

   az Azure Portal ellenőrzi a kapcsolatot. Ha az adatbázis inaktivitás miatt szünetel, lépjen az adatbázis-kiszolgáló lapjára, és győződjön meg arról, hogy az adatbázis állapota online állapotú. Az adatbázis aktiválásához bármely táblán futtathat lekérdezést.

   

4. Adjon meg egy hitelesítési módszert, vagy egy SQL Server-bejelentkezést, amely a kiszolgáló beállításakor van meghatározva, vagy egy felügyelt identitást.

   Ha úgy konfigurálja az Azure AI Search szolgáltatást, hogy felügyelt identitást használjon, és létrehoz egy szerepkör-hozzárendelést az adatbázis-kiszolgálón, amely sql server-közreműködői vagy SQL DB-közreműködői engedélyeket biztosít az identitáshoz, az indexelő Microsoft Entra-azonosító és szerepkörök használatával csatlakozhat az Azure SQL-hez.

5. Az Adatok importálása és vektorizálása varázslóban megadhatja a módosítás- és törléskövetési beállításokat.

   • A törléskövetés az egyéni metaadatokkal végzett helyreállítható törlésen alapul.

   • A változáskövetés az SQL Server integrált változáskövetésén vagy a magas vízjelű változáskövetésen alapul.

6. Folytassa a varázsló végrehajtásához szükséges további lépésekkel:

   • Rövid útmutató: Adatok importálása varázsló

   • Rövid útmutató: Adatok importálása és vektorizálása varázsló

A REST API-k használata

Ez a szakasz az adatforrást, indexet és indexelőt létrehozó REST API-hívásokat mutatja be.

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.

1. Adatforrás létrehozása vagy adatforrás létrehozása vagy frissítése a definíció beállításához:

    POST https://myservice.search.windows.net/datasources?api-version=2024-07-01
    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
    }
   

2. Adja meg az Azure AI Search elnevezési konvencióit követő adatforrás egyedi nevét.

3. Állítsa be a "azuresql" "type" (típus) értéket (kötelező).

4. Á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 string lehető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őhöz 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.

1. 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=2024-07-01
   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
       }
     ]
   }
   

2. 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.

3. 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

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.

1. 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=2024-07-01
   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
   }
   

2. 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 magas vízjelek változásészlelési szabályzatára 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.

3. 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.

4. 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 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=2024-07-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" (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=2024-07-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.

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]

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=2024-07-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 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. Az előző példákban egyszerűen írja be 1Truetrue vagy írja be az Azure Portal mezőjébe.

GYIK

K: Indexelhetem az Always Encrypted oszlopokat?

Nem, 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.