如何為Elasticsearch索引此數據

Question

我本質上是試圖模仿ES中的連接，我知道這不是ES的一個很好的用例，但與此同時，我想要完成的搜索功能似乎並不常見。 我已經閱讀了ES文檔，博客文章，繪制的圖表，當然還在本地測試了不同的場景，但是我仍然很難理解如何為ES索引這些數據。 這是我的第一個ES項目，也是我與noSQL類環境的第一次真實交互。

想象一下社交食譜網站（為簡單起見）......

用戶可以發布原始食譜。 其他用戶可以“喜歡”（一次），“保存到”（多次保存到不同類別），以及“烹飪”（可以多次烹飪食譜）食譜。

用戶可以搜索食譜並在不同的簡單標志上過濾它們，例如“食譜至少煮過一次”以及他們是否喜歡，保存和/或烹飪食譜。 此外，當您查看用戶的個人資料時，您可以搜索他們喜歡，保存和烹飪的食譜。 以及用戶創建的食譜。

當前的設置，但似乎不可擴展，是一個Recipe被索引其各種yes / no標志，以及一個字段，每個字段為likes_by_users，saved_by_users和cooked_by_users。 這些字段包含一組user_id，這些user_id已對配方執行了任何操作。 然后，當我想要過濾時，我傳遞user_id（或者，如果你想看看你的朋友已經烹飪了什么，則傳遞user_ids）並過濾關於id是否顯示在相關數組中的結果。 但是，如果最終可能有數以百萬計的這些交互，那么這種方式的存儲和搜索似乎並不好。 我也可以將配方ID存儲在用戶身上，但最后，似乎我最終會遇到類似的問題，而且我會更加麻煩地需要首先從用戶查詢這些ID。

我一直在嘗試和/或思考的事情：

1. 使一切都變形。 我認為這是首選的ES方式，但我擔心這只是重復數據（可以搜索食譜標題，內容，類別等），其中一些經常變化。 例如，如果用戶喜歡食譜，則更新該食譜的喜歡計數，以便可以按照計數對結果進行排序。

我相信這需要為曾經與之交互的用戶創建一份配方副本，然后在那里存儲交互。 因此，喜歡的標志和已保存的類別的數據數組，以及已經烹飪的數據數組。 我相信我仍然需要傳遞一個user_ids數組來過濾，如果有人過濾了他們的朋友煮過的東西，但我不認為用戶會有數百萬的朋友，可能不到200歲。這還是許多ID傳入？ 將那么多數據保存到太多數據？ 事實上，有些字段可能經常更新，這使得這個聲音更加糟糕。

2. 在用戶下嵌套配方也聽起來不正確，因為在更新任何其他內容時需要重新編制索引。

3. 在文檔中，父/子聽起來像是最后的選擇，對於這個用例也聽起來不安靜。

4. 我已經考慮過從iSQL中刪除id（即用戶與之交互的配方ID）並將它們傳遞給ES。 但是，其中一個，mySQL只能連接這么多的id（同樣地，不確定在代碼中如果它們對於mySQL來說太長，將它們構建成代碼中的字符串是否明智），還有兩個，我不確定這是不是過濾ES結果的有效方法（過多的數據）。

我已經嘗試了一些其他的東西，比如分別索引用戶和食譜之間的關系，但一切似乎都歸結為瘋狂的城鎮。

我也不太清楚ES有多少太多了。 通過文檔閱讀，有人提到“如果你有很多XYZ，這不是一個好主意”，但我不知道在這些情況下有多少意味着什么。 我讀到的唯一具體部分是關於更新非規范化博客帖子中用戶的名稱，更新“幾千”只需不到一秒鍾。 我是否可以使用任何規則來估計存儲在字段中的數據，或者傳遞給過濾器的數據或要更新的文檔的數量有多大？

Answer 1

在Elasticsearch上實現這一點非常棘手，因為實體（用戶，配方，類別......）以各種方式鏈接在一起，並且在沒有競爭條件的情況下以高吞吐量更新這些數據並非易事。

用戶之間是否共享類別？ 我的意思是當食譜保存到類別（如標記）時，每個人都可以看到這些信息嗎？ 如果是這樣，這個結構應該讓你開始。

聽起來你應該有兩種類型的文件：食譜和烹飪動作/用戶/食譜。

配方結構：

{
  "_id": "rga9gia0934gau90" (could be auto-generated by ES)
  "created_by": 123         (user id)
  "contents": "Pour x grams of sugar..."
  "ingredients": ["sugar", "..."],
  "tags": ["unhealthy", "sweet", "..."]
}

烹飪日期結構：

{
  "_id": "123-rga9gia0934gau90" (generated as {user_id}-{recipe-id})
  "user_id": 123,
  "recipe_id": "rga9gia0934gau90",
  "cooked_at_dates": ["2017-01-02", "2017-01-07"],
  "cooked_n_times": 2
}

這樣，大多數更新都是單個文檔的本地更新。 然而，諸如“甜食譜用戶X還沒有烹飪”的一些查詢需要兩個ES查詢：首先獲得用戶已經烹飪的所有食譜的食譜ID，並且第二查詢查找沒有任何食譜的所有甜食譜。列出的ids。 這不會擴展到成千上萬的食譜，但應該可以正常工作數百或數千。