編製 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"
當您使用 delimitedTextparsingMode 建立索引子時，可能會覺得將欄位對應函式設定為索引鍵欄位十分自然，如下所示：
{
"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 內容類型剖析模式的詳細資訊，請檢閱下列文章。