Dela via


Indexdata från Azure Table Storage

I den här artikeln får du lära dig hur du konfigurerar en indexerare som importerar innehåll från Azure Table Storage och gör det sökbart i Azure AI Search. Indata till indexeraren är dina entiteter i en enda tabell. Utdata är ett sökindex med sökbart innehåll och metadata som lagras i enskilda fält.

Den här artikeln kompletterar Skapa en indexerare med information som är specifik för indexering från Azure Table Storage. Den använder Azure Portal- och REST-API:er för att demonstrera ett arbetsflöde i tre delar som är gemensamt för alla indexerare: skapa en datakälla, skapa ett index, skapa en indexerare. Dataextrahering sker när du skickar begäran skapa indexerare.

Förutsättningar

  • Azure Table Storage

  • Tabeller som innehåller text. Om du har binära data bör du överväga AI-berikning för bildanalys.

  • Läsbehörigheter för Azure Storage. En "fullständig åtkomst" anslutningssträng innehåller en nyckel som ger åtkomst till innehållet, men om du använder Azure-roller kontrollerar du att söktjänstens hanterade identitet har behörigheter för läsare och dataåtkomst.

Om du vill gå igenom exemplen i den här artikeln behöver du Azure Portal eller en REST-klient. Om du använder Azure Portal kontrollerar du att åtkomsten till alla offentliga nätverk är aktiverad. Andra metoder för att skapa en Azure Table-indexerare är Azure SDK:er.

Prova med exempeldata

Använd de här anvisningarna för att skapa en tabell i Azure Storage i testsyfte.

  1. Logga in på Azure Portal, navigera till ditt lagringskonto och skapa en tabell med namnet hotels.

  2. Installera Azure Storage Explorer.

  3. Ladda ned HotelsData_toAzureSearch.csv från GitHub. Den här filen är en delmängd av den inbyggda exempeldatauppsättningen för hotell. Den utelämnar rumssamlingen, översatta beskrivningar och geografikoordinater.

  4. Logga in på Azure i Azure Storage Explorer, välj din prenumeration och välj sedan ditt lagringskonto.

  5. Öppna Tabeller och välj hotell.

  6. Välj Importera i kommandofältet och välj sedan filen HotelsData_toAzureSearch.csv .

  7. Acceptera alla standardinställningar. Välj Importera för att läsa in data.

Du bör ha 50 hotellposter i tabellen med en automatiskt genererad partitionKey, rowKey och tidsstämpel. Nu kan du använda det här innehållet för indexering i Azure Portal, REST-klienten eller en Azure SDK.

Fältet Beskrivning innehåller det mest utförliga innehållet. Du bör rikta in dig på det här fältet för fulltextsökning och valfria vektorfrågor.

Använda Azure Portal

Du kan använda guiden Importera data eller guiden Importera och vektorisera data för att automatisera indexeringen från en SQL-databastabell eller -vy. Konfigurationen av datakällan liknar båda guiderna.

  1. Starta assistenten.

  2. I Anslut till dina data väljer eller verifierar du att datakälltypen antingen är Azure Table Storage eller att datavalsfälten frågar efter tabeller.

    Namnet på datakällan refererar till datakällans anslutningsobjekt i Azure AI Search. Om du använder vektorguiden genereras datakällans namn automatiskt med ett anpassat prefix som anges i slutet av guidens arbetsflöde.

  3. Ange lagringskontot och tabellnamnet. Frågan är valfri. Det är användbart om du har specifika kolumner som du vill importera.

  4. Ange en autentiseringsmetod, antingen en hanterad identitet eller inbyggd API-nyckel. Om du inte anger en hanterad identitetsanslutning använder portalen nyckeln.

    Om du konfigurerar Azure AI Search för att använda en hanterad identitet och du skapar en rolltilldelning i Azure Storage som ger läsare och dataåtkomstbehörighet till identiteten, kan indexeraren ansluta till tabelllagring med hjälp av Microsoft Entra-ID och roller.

  5. För guiden Importera och vektorisera data kan du ange alternativ för borttagningsidentifiering,

    Borttagningsidentifiering kräver att du har ett befintligt fält i tabellen som kan användas som en flagga för mjuk borttagning. Det bör vara ett booleskt fält (du kan ge det namnet IsDeleted). Ange true som värdet för mjuk borttagning. I sökindexet lägger du till ett motsvarande sökfält med namnet IsDeleted set till hämtningsbar och filterbar.

  6. Fortsätt med de återstående stegen för att slutföra guiden:

Använda REST-API:er

Det här avsnittet visar REST API-anrop som skapar en datakälla, ett index och en indexerare.

Definiera datakällan

Datakällans definition anger vilka källdata som ska indexeras, autentiseringsuppgifter och principer för ändringsidentifiering. En datakälla är en oberoende resurs som kan användas av flera indexerare.

  1. Skapa eller uppdatera en datakälla för att ange dess definition:

     POST https://[service name].search.windows.net/datasources?api-version=2024-07-01 
     {
         "name": "my-table-storage-ds",
         "description": null,
         "type": "azuretable",
         "subtype": null,
         "credentials": {
            "connectionString": "DefaultEndpointsProtocol=https;AccountName=<account name>"
         },
         "container": {
            "name": "my-table-in-azure-storage",
            "query": ""
         },
         "dataChangeDetectionPolicy": null,
         "dataDeletionDetectionPolicy": null,
         "encryptionKey": null,
         "identity": null
     }
    
  2. Ange "typ" till "azuretable" (krävs).

  3. Ange "autentiseringsuppgifter" till en Azure Storage-anslutningssträng. I nästa avsnitt beskrivs de format som stöds.

  4. Ange "container" till namnet på tabellen.

  5. Du kan också ange "fråga" till ett filter på PartitionKey. Att ange den här egenskapen är en metod som förbättrar prestandan. Om "frågan" är null kör indexeraren en fullständig tabellgenomsökning, vilket kan leda till dåliga prestanda om tabellerna är stora.

En datakällsdefinition kan också innehålla principer för mjuk borttagning om du vill att indexeraren ska ta bort ett sökdokument när källdokumentet flaggas för borttagning.

Autentiseringsuppgifter och anslutningssträng som stöds

Indexerare kan ansluta till en tabell med hjälp av följande anslutningar.

Lagringskonto med fullständig åtkomst anslutningssträng
{ "connectionString" : "DefaultEndpointsProtocol=https;AccountName=<your storage account>;AccountKey=<your account key>;" }
Du kan hämta anslutningssträng från sidan Lagringskonto i Azure Portal genom att välja Åtkomstnycklar i det vänstra navigeringsfönstret. Se till att välja en fullständig anslutningssträng och inte bara en nyckel.
Hanterad identitet anslutningssträng
{ "connectionString" : "ResourceId=/subscriptions/<your subscription ID>/resourceGroups/<your resource group name>/providers/Microsoft.Storage/storageAccounts/<your storage account name>/;" }
Den här anslutningssträng kräver ingen kontonyckel, men du måste tidigare ha konfigurerat en söktjänst för att ansluta med hjälp av en hanterad identitet.
Signatur för delad åtkomst för lagringskonto** (SAS) anslutningssträng
{ "connectionString" : "BlobEndpoint=https://<your account>.blob.core.windows.net/;SharedAccessSignature=?sv=2016-05-31&sig=<the signature>&spr=https&se=<the validity end time>&srt=co&ss=b&sp=rl;" }
SAS bör ha listan och läsbehörigheter för tabeller och entiteter.
Signatur för delad åtkomst för containrar
{ "connectionString" : "ContainerSharedAccessUri=https://<your storage account>.blob.core.windows.net/<container name>?sv=2016-05-31&sr=c&sig=<the signature>&se=<the validity end time>&sp=rl;" }
SAS ska ha listan och läsbehörigheter för containern. Mer information finns i Använda signaturer för delad åtkomst.

Kommentar

Om du använder SAS-autentiseringsuppgifter måste du uppdatera autentiseringsuppgifterna för datakällan regelbundet med förnyade signaturer för att förhindra att de upphör att gälla. När SAS-autentiseringsuppgifterna upphör att gälla misslyckas indexeraren med ett felmeddelande som liknar "Autentiseringsuppgifterna som anges i anslutningssträng är ogiltiga eller har upphört att gälla".

Partition för bättre prestanda

Som standard använder Azure AI Search följande interna frågefilter för att hålla reda på vilka källentiteter som har uppdaterats sedan den senaste körningen: Timestamp >= HighWaterMarkValue. Eftersom Azure-tabeller inte har något sekundärt index i Timestamp fältet kräver den här typen av fråga en fullständig tabellgenomsökning och är därför långsam för stora tabeller.

Om du vill undvika en fullständig genomsökning kan du använda tabellpartitioner för att begränsa omfånget för varje indexerarjobb.

  • Om dina data naturligtvis kan partitioneras i flera partitionsintervall skapar du en datakälla och en motsvarande indexerare för varje partitionsintervall. Varje indexerare behöver nu endast bearbeta ett specifikt partitionsintervall, vilket ger bättre frågeprestanda. Om de data som behöver indexeras har ett litet antal fasta partitioner, ännu bättre: varje indexerare gör bara en partitionsgenomsökning.

    Om du till exempel vill skapa en datakälla för bearbetning av ett partitionsintervall med nycklar från 000 till 100använder du en fråga som den här: "container" : { "name" : "my-table", "query" : "PartitionKey ge '000' and PartitionKey lt '100' " }

  • Om dina data partitioneras efter tid (till exempel om du skapar en ny partition varje dag eller vecka) bör du överväga följande metod:

    • I datakällans definition anger du en fråga som liknar följande exempel: (PartitionKey ge <TimeStamp>) and (other filters).

    • Övervaka indexerarens förlopp med hjälp av Hämta indexerarens status-API och uppdatera <TimeStamp> regelbundet frågans villkor baserat på det senaste lyckade värdet för högvattenmärke.

    • Med den här metoden, om du behöver utlösa en fullständig omindexering, återställer du datakällans fråga förutom att återställa indexeraren.

Lägga till sökfält i ett index

I ett sökindex lägger du till fält för att acceptera innehållet och metadata för dina tabellentiteter.

  1. Skapa eller uppdatera ett index för att definiera sökfält som lagrar innehåll från entiteter:

    POST https://[service name].search.windows.net/indexes?api-version=2024-07-01 
    {
      "name" : "my-search-index",
      "fields": [
        { "name": "Key", "type": "Edm.String", "key": true, "searchable": false },
        { "name": "SomeColumnInMyTable", "type": "Edm.String", "searchable": true }
      ]
    }
    
  2. Skapa ett dokumentnyckelfält ("nyckel": sant), men låt indexeraren fylla i det automatiskt. En tabellindexerare fyller nyckelfältet med sammanfogade partitions- och radnycklar från tabellen. Om till exempel en rads PartitionKey är 1 och RowKey är 1_123är 11_123är nyckelvärdet . Om partitionsnyckeln är null används bara radnyckeln.

    Om du använder guiden Importera data för att skapa indexet härleder portalen ett nyckelfält för sökindexet och använder en implicit fältmappning för att ansluta käll- och målfälten. Du behöver inte lägga till fältet själv och du behöver inte konfigurera en fältmappning.

    Om du använder REST-API:er och vill ha implicita fältmappningar skapar och namnger du dokumentnyckelfältet "Nyckel" i sökindexdefinitionen enligt föregående steg ({ "name": "Key", "type": "Edm.String", "key": true, "searchable": false }). Indexeraren fyller i nyckelfältet automatiskt, utan att det krävs några fältmappningar.

    Om du inte vill ha ett fält med namnet "Nyckel" i sökindexet lägger du till en explicit fältmappning i indexerarens definition med det fältnamn du vill använda och anger källfältet till "Nyckel":

     "fieldMappings" : [
       {
         "sourceFieldName" : "Key",
         "targetFieldName" : "MyDocumentKeyFieldName"
       }
    ]
    
  3. Lägg nu till andra entitetsfält som du vill ha i ditt index. Om en entitet till exempel ser ut som i följande exempel bör ditt sökindex ha fält för HotelName, Beskrivning och Kategori för att ta emot dessa värden.

    Skärmbild av tabellinnehåll i Storage-webbläsaren.

    Med samma namn och kompatibla datatyper minimeras behovet av fältmappningar. När namn och typer är desamma kan indexeraren bestämma datasökvägen automatiskt.

Konfigurera och köra tabellindexeraren

När du har ett index och en datakälla är du redo att skapa indexeraren. Indexerarens konfiguration anger indata, parametrar och egenskaper som styr körningstidsbeteenden.

  1. Skapa eller uppdatera en indexerare genom att ge den ett namn och referera till datakällan och målindexet:

    POST https://[service name].search.windows.net/indexers?api-version=2024-07-01
    {
        "name" : "my-table-indexer",
        "dataSourceName" : "my-table-storage-ds",
        "targetIndexName" : "my-search-index",
        "disabled": null,
        "schedule": null,
        "parameters" : {
            "batchSize" : null,
            "maxFailedItems" : null,
            "maxFailedItemsPerBatch" : null,
            "configuration" : { }
        },
        "fieldMappings" : [ ],
        "cache": null,
        "encryptionKey": null
    }
    
  2. Ange fältmappningar om det finns skillnader i fältnamn eller typ, eller om du behöver flera versioner av ett källfält i sökindexet. Fältet Mål är namnet på fältet i sökindexet.

     "fieldMappings" : [
       {
         "sourceFieldName" : "Description",
         "targetFieldName" : "HotelDescription"
       }
    ]
    
  3. Mer information om andra egenskaper finns i Skapa en indexerare .

En indexerare körs automatiskt när den skapas. Du kan förhindra detta genom att ange "inaktiverad" till true. Om du vill kontrollera indexerarens körning kör du en indexerare på begäran eller sätter den enligt ett schema.

Kontrollera status för indexerare

Om du vill övervaka indexerarens status och körningshistorik kontrollerar du indexerarens körningshistorik i Azure Portal eller skickar rest-APIrequest för Get Indexer Status

  1. Öppna Indexerare för sökhantering>på söktjänstsidan.

  2. Välj en indexerare för att komma åt konfigurations- och körningshistoriken.

  3. Välj ett specifikt indexeringsjobb för att visa information, varningar och fel.

Körningshistoriken innehåller upp till 50 av de senast slutförda körningarna, som sorteras i omvänd kronologisk ordning så att den senaste körningen kommer först.

Nästa steg

Läs mer om hur du kör indexeraren, övervakar status eller schemalägger indexerarens körning. Följande artiklar gäller för indexerare som hämtar innehåll från Azure Storage: