Azure搜索的文檔設計

我正在發佈任何人是否有解決方案或可以提供一些建模指導，以便在天藍色的搜索中使用。Azure搜索的文檔設計

我目前使用DocumentDB模型的一些數據，我想搜索的問題域。我的文檔，我將在目前所謂的「實體A」看起來像：

{ 
_id,       //key - Guid 
name,       //searchable - String 
description,     //searchable - String 
tags: [ "T1", "T2", ...]  //facet - Collection(String) 
locations: [ 
    { 
     coordinate,    //filter - GeoLocation (lat & long) 
     startDateTime,   //filter - DateTimeOffset 
     endDateTime    //filter - DateTimeOffset 
    }, 
    ... 
    ] 
... 
}, 
...

關係：標籤0，...，N實體A &位置0，...，N實體A

壓扁實體A併爲標記的名稱，描述和構面設置簡單的索引和查詢是很好的，並且工作得很好。

問題在於試圖將位置添加到索引。實際上，我想要搜索的內容是：對於給定的術語，找到所有實體爲靠近與x開始日期和y結束日期重疊的座標

從我在網上可以找到的內容 - 展開地點只有在成爲字符串時纔有效。

https://blogs.msdn.microsoft.com/kaevans/2015/03/09/indexing-documentdb-with-azure-seach/ https://docs.microsoft.com/en-us/azure/search/search-howto-index-json-blobs

這似乎失去了能夠進行地表距離，和日期範圍查詢的權力。

當前思想

斯普利特實體文檔到兩個集合

新實體的文件：

{ 
    _id,       //key - Guid 
    name,       //searchable - String 
    description,     //searchable - String 
    tags: [ "T1", "T2", ...]  //facet - Collection(String) 
    ... 
    },

和多個位置的實體

{ 
    _id, 
    documentId,      //relates to Document._id 
    coordinate, 
    startDate, 
    endDate 
}

問題：

有兩個指標 - 一個用於新的實體A和一個用於位置，然後加入結果會更好嗎？

我覺得這是多租戶的搜索 https://docs.microsoft.com/en-us/azure/search/search-modeling-multitenant-saas-applications

有誰知道實現這個的例子嗎？

優點

認爲這會工作

缺點

將需要爲每個查詢兩個搜索點擊，然後將結果進行合併（這可能會或可能不會很理想）。

是不如完全「顛倒」的實體A和位置的實體，即像

{ 
    _id, 
    documentDBId,      //relates to Document._id 
    coordinate, 
    startDate, 
    endDate, 
    name, 
    description, 
    tags: [] 
    ... 
}

優點

姿色平平已經如此應易於索引和查詢
One sea RCH擊中，沒有合併

缺點

對於名稱，描述，標籤等，將需要進行多次更新如果這些改變。
會得到多個結果相同的「實體A」如果日期跨越多個開始和結束日期

難道還有其他選擇嗎？如果需要的話

來源

2017-02-14 Chris Wallace

我的偏向你的第二個完全扁平化或倒掛選項

{ 
    _id, 
    documentDBId,      //relates to Document._id 
    coordinate, 
    startDate, 
    endDate, 
    name, 
    description, 
    tags: [] 
    ... 
}

我的主要論據，這是尋呼

謝謝，我很高興地澄清。如果您有兩次搜索，並且您希望在頁面上返回10個結果，那麼您要求搜索多少結果，更重要的是，您從哪裏開始搜索第2頁？

也有排名結果的問題，但這些比分頁更易於管理。

來源

2017-02-14 16:41:37

只要匹配給定查詢的位置/日期組合數量相對較少，我不確定分頁是否會成爲問題。您將獲取所有匹配項，將相應文檔ID的列表放在一起，然後使用它篩選實體A索引。用於向用戶顯示的目的的分頁將發生在實體A索引上。 –

啊，是的，只要第一次搜索的結果數量合理，這樣做就可以處理分頁。 –

謝謝@布魯斯約翰斯頓。我要給它一槍，看看我得到多少/遇到的問題。 –

Azure搜索的文檔設計

回答

相關問題