編製 Blob 和檔案的索引，以產生多個搜尋文件
依預設，索引子會將 Blob 或檔案的內容視為單一搜尋文件。 如果您想要在搜尋索引中使用更精細的表示法，您可以設定 parsingMode 值，從一個 Blob 或檔案建立多個搜尋文件。 產生許多搜尋文件的 parsingMode 值，包括 (CSV 的) delimitedText，以及 jsonArray 或 (JSON 的) jsonLines。
當您使用上述任何剖析模式，出現的新搜尋文件必須具有唯一的文件索引鍵，而且判斷該值的來源的問題。 父 Blob 在 metadata_storage_path property 中格式至少有一個唯一值，但如果父 Blob 將該值提供給多個搜尋文件，則索引鍵將不再是唯一。
為解決此問題，Blob 索引子會產生 AzureSearch_DocumentKey，可唯一識別從單一 Blob 父代建立的每個子搜尋文件。 本文將說明此功能的運作方式。
一對多文件索引鍵
索引中的每個文件都是依據文件索引鍵進行唯一識別。 如果未指定剖析模式，且如果搜尋文件索引鍵的索引子定義中沒有明確的欄位對應，則 Blob 索引子會自動將 metadata_storage_path property 對應為文件索引鍵。 此預設對應可確保每個 Blob 都會顯示為不同的搜尋文件，並儲存您建立此欄位對應的步驟 (通常只有具有相同名稱和類型的欄位會自動對應)。
在一對多搜尋文件的情況中，無法使用以 metadata_storage_path property 為基礎的隱含文件索引鍵。 作為因應措施，Azure AI 搜尋服務可針對從 Blob 擷取的每個實體產生文件密鑰。 產生的索引鍵會命名為 AzureSearch_DocumentKey，並且會新增至每個搜尋文件。 索引子會追蹤由每個 Blob 建立的「許多文件」，並在來源資料隨著時間變更時，以搜尋索引的更新為目標。
根據預設，當未指定索引鍵索引欄位的明確欄位對應時，會使用 base64Encode 欄位對應函式，與 AzureSearch_DocumentKey 進行對應。
範例
假設索引定義具有下列欄位：
idtemperaturepressuretimestamp
您的 Blob 容器具有具有下列結構的 Blob：
Blob1.json
{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }
Blob2.json
{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }
當您建立索引子，並將 parsingMode 設定為 jsonLines (而不指定索引鍵欄位的任何明確欄位對應) 時，將會隱含地套用下列對應。
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
此設定會導致文件索引鍵變得模稜兩可，類似於下圖 (為了簡潔起見，縮短為 base64 的已編碼識別碼)。
| 識別碼 | 溫度 | 壓力 | timestamp |
|---|---|---|---|
| aHR0 ...YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
| aHR0 ...YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
| aHR0 ...YjIuanNvbjsx | 1 | 1 | 2023-01-12T00:00:00Z |
| aHR0 ...YjIuanNvbjsy | 120 | 3 | 2022-05-11T00:00:00Z |
索引鍵欄位的自訂欄位對應
假設索引定義與上一個範例相同，您的 Blob 容器應有具下列結構的 Blob：
Blob1.json
recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
當您使用 delimitedText parsingMode 建立索引子時，可能會覺得將欄位對應函式設定為索引鍵欄位十分自然，如下所示：
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
不過，此對應「不會」在索引中顯示四份文件，因為 recordid 欄位在「Blob 之間」不是唯一項目。 因此，建議您針對「一對多」剖析模式，使用從 AzureSearch_DocumentKey 屬性套用至索引鍵索引欄位的隱含欄位對應。
如果您想要設定明確的欄位對應，請確定所有 Blob 中每個個別實體的 sourceField 都不同。
注意
AzureSearch_DocumentKey 用來確保每個擷取實體唯一性的方法可能有所變更，因此您不應該依賴其值來滿足應用程式需求。
指定您資料中的索引鍵欄位
假設索引定義與上一個範例相同，且 parsingMode 設定為 jsonLines，未指定任何明確的欄位對應，則對應會類似於第一個範例，您的 Blob 容器應該具有下列結構的 Blob：
Blob1.json
id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
請注意，每個文件都包含 id 欄位，該欄位在索引中定義為 key 欄位。 在這種情況下，即使會產生在文件內唯一的 AzureSearch_DocumentKey，也不會當成文件的「索引鍵」使用。 相反地，id 欄位的值將會對應至 key 欄位
與上一個範例類似，此對應不會在索引中顯示四份文件，因為 id 欄位在「Blob 之間」並不是唯一值。 在此情況下，任何指定 id 的 json 項目都會在現有文件上產生合併，而不是上傳新文件，而且索引的狀態會反映已指定 id 的最新讀取項目。
下一步
如果您還不熟悉 Blob 索引的基本結構和工作流程，您應該先檢閱使用 Azure AI 搜尋服務編製 Azure Blob 儲存體的索引。 如需不同 Blob 內容類型剖析模式的詳細資訊，請檢閱下列文章。