Indexdata från Azure Table Storage

Artikel
02/22/2024

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 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 data- och läsarbehörighet.
Använd en REST-klient för att formulera REST-anrop som liknar dem som visas i den här artikeln.

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.

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

 POST https://[service name].search.windows.net/datasources?api-version=2023-11-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
 }

Ange "typ" till "azuretable" (krävs).
Ange "autentiseringsuppgifter" till en Azure Storage-anslutningssträng. I nästa avsnitt beskrivs de format som stöds.
Ange "container" till namnet på tabellen.
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-portalen 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.

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=2023-11-01 
{
  "name" : "my-search-index",
  "fields": [
    { "name": "Key", "type": "Edm.String", "key": true, "searchable": false },
    { "name": "SomeColumnInMyTable", "type": "Edm.String", "searchable": true }
  ]
}

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"
   }
]
```
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.

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.

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=2023-11-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,
        "base64EncodeKeys" : null,
        "configuration" : { }
    },
    "fieldMappings" : [ ],
    "cache": null,
    "encryptionKey": null
}

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"
   }
]
```
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 skickar du en get indexer-statusbegäran :

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

Svaret innehåller status och antalet bearbetade objekt. Det bör se ut ungefär som i följande exempel:

    {
        "status":"running",
        "lastResult": {
            "status":"success",
            "errorMessage":null,
            "startTime":"2023-02-21T00:23:24.957Z",
            "endTime":"2023-02-21T00:36:47.752Z",
            "errors":[],
            "itemsProcessed":1599501,
            "itemsFailed":0,
            "initialTrackingState":null,
            "finalTrackingState":null
        },
        "executionHistory":
        [
            {
                "status":"success",
                "errorMessage":null,
                "startTime":"2023-02-21T00:23:24.957Z",
                "endTime":"2023-02-21T00:36:47.752Z",
                "errors":[],
                "itemsProcessed":1599501,
                "itemsFailed":0,
                "initialTrackingState":null,
                "finalTrackingState":null
            },
            ... earlier history items
        ]
    }

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: