国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

我用云緩存Redis實現了一個輕量級的搜索引擎!

Tecode / 1997人閱讀

摘要:這里會發現,漏了一個價格的條件。總結這里只是一個采用優化查詢搜索的一個簡單,和現有的開源搜索引擎相比,它更輕量,學習成本頁相應低些。

大家如果是做后端開發的,想必都實現過列表查詢的接口,當然有的查詢條件很簡單,一條 SQL 就搞定了。

但有的查詢條件極其復雜,再加上庫表中設計的各種不合理,導致查詢接口特別難寫,然后加班什么的就不用說了(不知各位有沒有這種感受呢~)。

下面以一個例子開始,這是某購物網站的搜索條件,如果讓你實現這樣的一個搜索接口,你會如何實現?

當然你說借助搜索引擎,像 Elasticsearch 之類的,你完全可以實現。但我這里想說的是,如果要你自己實現呢?

image.png

從上圖中可以看出,搜索總共分為 6 大類,每大類中又分了各個子類。

這中間,各大類條件之間是取的交集,各子類中有單選、多選、以及自定義的情況,最終輸出符合條件的結果集。

好了,既然需求很明確了,我們就開始來實現。

實現 1

率先登場是小 A 同學,他是寫 SQL 方面的“專家”。小 A 信心滿滿的說:“不就是一個查詢接口嗎?看著條件很多,但憑著我豐富的 SQL 經驗,這點還是難不倒我的。”

于是乎就寫出了下面這段代碼(這里以 MySQL 為例):

select ... from table_1
left join table_2
left join table_3
left join (select ... from table_x where ...) tmp_1
...
where ...
order by ...
limit m,n

代碼在測試環境跑了一把,結果好像都匹配上了,于是準備上預發。這一上預發,問題就開始暴露出來。

預發為了盡可能的逼真線上環境,所以數據量自然而然要比測試大的多。所以這么一個復雜的 SQL,它的執行效率可想而知。測試同學果斷把小 A 的代碼給打了回來。

實現 2

總結了小 A 失敗的教訓,小 B 開始對 SQL 進行了優化,先是通過了 explain 關鍵字進行 SQL 性能分析,對該加索引的地方都加上了索引。

同時將一條復雜 SQL 拆分成了多條 SQL,計算結果在程序內存中進行計算。

偽代碼如下:

$result_1 = query(select ... from table_1 where ...);
$result_2 = query(select ... from table_2 where ...);
$result_3 = query(select ... from table_3 where ...);
...

$result = array_intersect($result_1, $result_2, $result_3, ...);

這種方案從性能上明顯比第一種要好很多,可是在功能驗收的時候,產品經理還是覺得查詢速度不夠快。

小 B 自己也知道,每次查詢都會向數據庫查詢多次,而且有些歷史原因,部分條件是做不到單表查詢的,所以查詢等待的時間是避免不了的。

實現 3

小 C 從上面的方案中看到了優化的空間。他發現小 B 在思路上是沒問題的,將復雜條件拆分,計算各個子維度的結果集,最后將所有的子結果集進行一個匯總合并,得到最終想要的結果。

于是他突發奇想,能否事先將各個子維度的結果集給緩存起來,這要查詢的時候直接去取想要的子集,而不用每次去查庫計算。

這里小 C 采用 Redis 來存儲緩存數據,用它的主要原因是,它提供了多種數據結構,并且在 Redis 中進行集合的交并集操作是一件很容易的事情。

具體方案,如圖所示:

image.png

這里每個條件都事先將計算好的結果集 ID 存入對應的 Key 中,選用的數據結構是集合(Set)。

查詢操作包括:
子類單選:直接根據條件 Key,獲取對應結果集。
子類多選:根據多個條件 Key,進行并集操作,獲取對應結果集。
最終結果:將獲取的所有子類結果集進行交集操作,得到最終結果。

這其實就是所謂的反向索引。這里會發現,漏了一個價格的條件。從需求中可知,價格條件是個區間,并且是無窮舉的。

所以上述的這種窮舉條件的 Key-Value 方式是做不到的。這里我們采用 Redis 的另一種數據結構進行實現,有序集合(Sorted Set):

image.png

將所有商品加入 Key 為價格的有序集合中,值為商品 ID,每個值對應的分數為商品價格的數值。

這樣在 Redis 的有序集合中就可以通過 ZRANGEBYSCORE 命令,根據分數(價格)區間,獲取相應結果集。

至此,方案三的優化已全部結束,將數據的查詢與計算通過緩存的手段,進行了分離。

在每次查找時,只需要簡單的查找 Redis 幾次就能得出結果。查詢速度上符合了驗收的要求。

擴展

①分頁

這里你或許發現了一個嚴重的功能缺陷,列表查詢怎么能沒有分頁。是的,我們馬上來看 Redis 是如何實現分頁的。

分頁主要涉及排序,這里簡單起見,就以創建時間為例。如圖所示:

image.png

圖中藍色部分是以創建時間為分值的商品有序集合,藍色下方的結果集即為條件計算而得的結果,通過 ZINTERSTORE 命令,賦結果集權重為 0,商品時間結果為 1,取交集而得的結果集賦予創建時間分值的新有序集合。

對新結果集的操作即能得到分頁所需的各個數據:

  • 頁面總數為:ZCOUNT 命令。
  • 當前頁內容:ZRANGE 命令。
  • 若以倒序排列:ZREVRANGE命令。

②數據更新

關于索引數據更新的問題,有兩種方式來進行。一種是通過商品數據的修改,來即時觸發更新操作,一種是通過定時腳本來進行批量更新。

這里要注意的是,關于索引內容的更新,如果暴力的刪除 Key,再重新設置 Key。

因為 Redis 中兩個操作不會是原子性進行的,所以中間可能存在空白間隙,建議采用僅移除集合中失效元素,添加新元素的方式進行。

③性能優化

Redis 是內存級操作,所以單次的查詢會很快。但是如果我們的實現中會進行多次的 Redis 操作,Redis 的多次連接時間可能是不必要時間消耗。

通過使用 MULTI 命令,開啟一個事務,將 Redis 的多次操作放在一個事務中,最后通過 EXEC 來進行原子性執行。

注意:這里所謂的事務,只是將多個操作在一次連接中執行,如果執行過程中遇到失敗,是不會回滾的。

總結

這里只是一個采用 Redis 優化查詢搜索的一個簡單 Demo,和現有的開源搜索引擎相比,它更輕量,學習成本頁相應低些。

其次,它的一些思想與開源搜索引擎是類似的,如果再加上詞語解析,也可以實現類似全文檢索的功能。

作者:jasonGeng88
編輯:陶家龍
出處:https://github.com/jasonGeng88/blog

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/125944.html

相關文章

  • 2015 年度小結(技術方面)

    摘要:因為路由層面受業務影響很大,經常修改一些功能的行為,所以后來大部分測試都是針對層面的單元測試。在我了解的過程中,我發現中文網絡上對的討論非常分散,于是我創建了中文社區,到年末已經有個注冊用戶和個帖子了。 https://jysperm.me/2016/02/programming-of-2015/ 從 2014 年末開始開發的一個互聯網金融項目終于在今年三月份上線了,這是一個 Node...

    宋華 評論0 收藏0
  • 2015 年度小結(技術方面)

    摘要:因為路由層面受業務影響很大,經常修改一些功能的行為,所以后來大部分測試都是針對層面的單元測試。在我了解的過程中,我發現中文網絡上對的討論非常分散,于是我創建了中文社區,到年末已經有個注冊用戶和個帖子了。 https://jysperm.me/2016/02/programming-of-2015/ 從 2014 年末開始開發的一個互聯網金融項目終于在今年三月份上線了,這是一個 Node...

    Nosee 評論0 收藏0
  • App后臺api開發前準備

    摘要:負責從拉取數據源,把數據源分詞,建立索引搜索模塊工作流程如下模塊從中拉取數據模塊用經過中文分詞后的數據建立索引客戶端向模塊發起搜索請求模塊查找索引中的數據模塊得到索引中符合要求的數據的等數據把數據返回給客戶端 (整理自《App后臺開發運維和架構實踐》 作者:曾健生) 一、從業務邏輯中提煉API接口 此過程可分為六個階段: 業務邏輯思維導圖 功能——業務邏輯思維導圖 基本功能模塊關系 ...

    yzzz 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<