![](/2022/11/22/%E7%94%A8-App-search-%E7%9A%84-curation-%E6%A6%82%E5%BF%B5%E8%A7%A3%E6%B1%BA%E7%86%B1%E9%96%80%E6%99%AF%E9%BB%9E%E7%9A%84%E6%90%9C%E5%B0%8B%E5%95%8F%E9%A1%8C/autocomplete.png)
無論在哪個領域,「搜尋」這個議題,一直都是以讓使用者找到最適合的內容為最高原則。而 LBS 這類服務,如果要做搜尋通常都會再加上「經緯度」為變因,但常會遇到在「台北市」找不到「東京鐵塔」,這類我們想要讓使用者能夠直接搜尋到的景點,這篇文章就是要來分享 Funliday 如何解決這個問題。
小編今年買了一本喬叔的 Elasticsearch 實戰書籍 (非業配,但覺得真的不錯),看到裡面介紹了 App search,這其實就是把 Elasticsearch 再封裝之後的服務,把搜尋功能的開發難度降低許多。而其中的 curation 更是啟發小編,讓小編不會糾結在搜尋只能在一個索引上完成。
在接觸 curation 這個概念之前,小編一直認為搜尋就應該要在同樣一個索引上完成才對,沒有想到其實可以做兩次索引的操作。而 curation 其實就是將想要讓使用者特別找到的內容,放在另一個索引,搜尋時先搜這個索引,然後再搜原本的索引,就能達成想要的內容先出現,剩下的依序排在後面,這樣子也就達成依照熱門程度的搜尋結果。
一開始只是想做 autocomplete 熱門景點
在還沒開發熱門景點搜尋的時候,一開始其實只是想在畫面上用 autocomplete 讓使用者選擇熱門景點,而當初也不想大改原本的資料結構,所以就用 Redis 來做熱門景點的 POI autocomplete。
開發完後在 dev 環境測試沒發生問題,但是 production 環境在建立資料時,Redis 無論加到多少記憶體都不夠用,這是始料未及的。主要是 production 資料比較完整,所以要寫入到資料庫的內容相比就多很多。另外因為 Redis 是 in-memory database,跟硬碟相比記憶體又特別貴,所以只好捨棄 Redis,改用 Elasticsearch 來做。
雖然用 Elasticsearch 來做 autocomplete 會稍慢於 Redis,但在成本跟效率相比,這是目前最平衡的做法。
把 curation 概念套入 search 熱門景點
用 Elasticsearch 實作完 autocomplete 之後,又想到書上寫的 curation 這個概念,看了看現在的這個索引,好像可以用來做熱門景點的搜尋。
無論輸入的關鍵字是什麼,都先在熱門景點這個 index 搜尋,然後再進原本的 index 搜尋,這樣可以達成在任何地方,都保證能找到東京的「東京鐵塔」,然後才是該地區的「東京鐵塔」。
1 | { |
也可以拿來做別名功能
大家可以看到這個 index 把所有語言都放在一起,然後再用 edge n-gram 分詞,所以無論是哪種語言都可以搜出相同的景點。更重要的是,當這個結構建立之後,小編發現也可以拿來做別名 (alias name) 了!
像「東京鐵塔」其實只是別名,正式名稱叫做「日本電波塔」,在沒有這個 index 之前,雖然 Elasticsearch 有同義詞 synonym 的功能,但維護不是很方便 (每次都要 reopen index,而且也無法指定 document),所以一直沒有拿來使用。有了這個 index,做別名搜尋可以更得心應手!
到此為止,search v2 的整體架構算是大致成形,當然還有超多細節,像是 autocomplete 及 search 這兩支 API,如何讓前端串接更容易 (因為太多邏輯了),又或是如何更精準搜尋到想要的內容等,由於涉及商業邏輯過多,之後有機會再來分享給大家看看吧。