存儲(chǔ)的瓶頸--大型網(wǎng)站技術(shù)演進(jìn)思考
一,題記
前不久公司請(qǐng)來(lái)了位互聯(lián)網(wǎng)界的技術(shù)大牛跟我們做了一次大型網(wǎng)站架構(gòu)的培訓(xùn),兩天12個(gè)小時(shí)信息量非常大,知識(shí)的廣度和難度也非常大,培訓(xùn)完后我很難完整理出全部聽(tīng)到的知識(shí),今天我換了個(gè)思路是回味這次培訓(xùn),這個(gè)思路就是通過(guò)本人目前的經(jīng)驗(yàn)和技術(shù)水平來(lái)思考下大型網(wǎng)站技術(shù)演進(jìn)的過(guò)程。
二,什么網(wǎng)站是大型網(wǎng)站
首先我們要思考一個(gè)問(wèn)題,什么樣的網(wǎng)站才是大型網(wǎng)站,從網(wǎng)站的技術(shù)指標(biāo)角度考慮這個(gè)問(wèn)題人們很容易犯一個(gè)毛病就是認(rèn)為網(wǎng)站的訪問(wèn)量是衡量的指標(biāo),懂點(diǎn)行的人也許會(huì)認(rèn)為是網(wǎng)站在單位時(shí)間里的并發(fā)量的大小來(lái)作為指標(biāo),如果按這些標(biāo)準(zhǔn)那么像hao123這樣的網(wǎng)站就是大型網(wǎng)站了,如下圖所示:
其實(shí)這種網(wǎng)站訪問(wèn)量非常大,并發(fā)數(shù)也非常高,但是它卻能用最為簡(jiǎn)單的web技術(shù)來(lái)實(shí)現(xiàn):我們只要保持網(wǎng)站的充分的靜態(tài)化,多部署幾臺(tái)服務(wù)器,那么就算地球上所有人都用它,網(wǎng)站也能正常運(yùn)行。
我覺(jué)得大型網(wǎng)站是技術(shù)和業(yè)務(wù)的結(jié)合,一個(gè)滿(mǎn)足某些用戶(hù)需求的網(wǎng)站只要技術(shù)和業(yè)務(wù)二者有一方難度很大,必然會(huì)讓企業(yè)投入更多的、更優(yōu)秀的人力成本實(shí)現(xiàn)它,那么這樣的網(wǎng)站就是所謂的大型網(wǎng)站了。
三,初建的網(wǎng)站
一個(gè)初建的網(wǎng)站往往用戶(hù)群都是很小的,最簡(jiǎn)單的網(wǎng)站架構(gòu)就能解決實(shí)際的用戶(hù)需求,當(dāng)然為了保證網(wǎng)站的穩(wěn)定性和安全性,我們會(huì)把網(wǎng)站的應(yīng)用部署到至少兩臺(tái)機(jī)器上,后臺(tái)的存儲(chǔ)使用數(shù)據(jù)庫(kù),如果經(jīng)濟(jì)實(shí)力允許,數(shù)據(jù)庫(kù)使用單臺(tái)服務(wù)器部署,由于數(shù)據(jù)是網(wǎng)站的生命線,因此我們常常會(huì)把部署數(shù)據(jù)庫(kù)的服務(wù)器使用的好點(diǎn),這個(gè)網(wǎng)站結(jié)構(gòu)如下所示:
這個(gè)結(jié)構(gòu)非常簡(jiǎn)單,其實(shí)大部分初建網(wǎng)站開(kāi)發(fā)里往往業(yè)務(wù)邏輯沒(méi)有企業(yè)級(jí)系統(tǒng)那么復(fù)雜,所以只要有個(gè)好的idea,建設(shè)一個(gè)新網(wǎng)站的成本是非常低的,所使用的技術(shù)手段也是非常的基本和簡(jiǎn)單,不過(guò)該圖我們要準(zhǔn)備三臺(tái)服務(wù)器,而且還要租個(gè)機(jī)房放置我們的服務(wù)器,這些成本對(duì)于草根和屌絲還是非常高的。
幸運(yùn)的是當(dāng)下很多大公司和機(jī)構(gòu)提供了云平臺(tái),我們可以花費(fèi)很少的錢(qián)將自己的應(yīng)用部署到云平臺(tái)上,這種做法我們甚至不用去考慮把應(yīng)用、數(shù)據(jù)庫(kù)分開(kāi)部署的問(wèn)題,更加進(jìn)一步的降低了網(wǎng)站開(kāi)發(fā)和運(yùn)維的成本,但是這種做法也有一個(gè)問(wèn)題,就是網(wǎng)站的小命被這個(gè)云平臺(tái)捏住了,如果云平臺(tái)掛了,俺們的網(wǎng)站服務(wù)也就跟著掛了。
四,網(wǎng)站遇到的問(wèn)題
這里我先講講自己獨(dú)立使用服務(wù)器部署網(wǎng)站的問(wèn)題,如果我們要把網(wǎng)站服務(wù)應(yīng)用使用多臺(tái)服務(wù)器部署,這么做的目的一般有兩個(gè):
保證網(wǎng)站的可用性,多臺(tái)服務(wù)器部署應(yīng)用,那么其中一些服務(wù)器掛掉了,只要網(wǎng)站還有服務(wù)器能正常運(yùn)轉(zhuǎn),那么網(wǎng)站對(duì)外任然可以正常提供服務(wù)。
提高網(wǎng)站的并發(fā)量,服務(wù)器越多那么網(wǎng)站能夠服務(wù)的用戶(hù),單位時(shí)間內(nèi)能承載的請(qǐng)求數(shù)也就越大。
不過(guò)要做到以上兩點(diǎn),并不是我們簡(jiǎn)單將網(wǎng)站分開(kāi)部署就可以滿(mǎn)足的,因?yàn)榇蠖鄶?shù)網(wǎng)站在用戶(hù)使用時(shí)候都是要保持用戶(hù)的狀態(tài),具體點(diǎn)就是網(wǎng)站要記住請(qǐng)求是歸屬到那一個(gè)客戶(hù)端,而這個(gè)狀態(tài)在網(wǎng)站開(kāi)發(fā)里就是通過(guò)會(huì)話(huà)session來(lái)體現(xiàn)的。
分開(kāi)部署的web應(yīng)用服務(wù)要解決的一個(gè)首要問(wèn)題就是要保持不同物理部署服務(wù)器之間的session同步問(wèn)題,從而達(dá)到當(dāng)用戶(hù)第一次請(qǐng)求訪問(wèn)到服務(wù)器A,第二個(gè)請(qǐng)求訪問(wèn)到服務(wù)器B,網(wǎng)站任然知道這兩個(gè)請(qǐng)求是同一個(gè)人,解決方案很直接:服務(wù)器A和服務(wù)器B上的session信息要時(shí)刻保持同步,那么如何保證兩臺(tái)服務(wù)器之間session信息的同步呢?
為了回答上面的問(wèn)題,我們首先要理解下session的機(jī)制,session信息在web容器里都是存儲(chǔ)在內(nèi)存里的,web容器會(huì)給每個(gè)連接它的客戶(hù)端生成一個(gè)sessionid值,這個(gè)sessionid值會(huì)被web容器置于http協(xié)議里的cookie域下,當(dāng)響應(yīng)被客戶(hù)端處理后,客戶(hù)端本地會(huì)存儲(chǔ)這個(gè)sessionid值,用戶(hù)以后的每個(gè)請(qǐng)求都會(huì)讓這個(gè)sessionid值隨cookie一起傳遞到服務(wù)器,服務(wù)器通過(guò)sessionid找到內(nèi)存中存儲(chǔ)的該用戶(hù)的session內(nèi)容,session在內(nèi)存的數(shù)據(jù)結(jié)構(gòu)是一個(gè)map的格式。
五,服務(wù)器越多,并發(fā)數(shù)反而越慢
那么為了保證不同服務(wù)器之間的session共享,那么最直接的方案就是讓服務(wù)器之間session不斷的傳遞和復(fù)制,例如java開(kāi)發(fā)里常用的tomcat容器就采用這種方案,以前我測(cè)試過(guò)tomcat這種session同步的性能,我發(fā)現(xiàn)當(dāng)需要同步的web容器越多,web應(yīng)用所能承載的并發(fā)數(shù)并沒(méi)有因?yàn)榉?wù)器的增加而線性提升,當(dāng)服務(wù)器數(shù)量達(dá)到一個(gè)臨界值后,整個(gè)web應(yīng)用的并發(fā)數(shù)甚至還會(huì)下降,為什么會(huì)這樣了?
原因很簡(jiǎn)單,不同服務(wù)器之間session的傳遞和復(fù)制會(huì)消耗服務(wù)器本身的系統(tǒng)資源,當(dāng)服務(wù)器數(shù)量越大,消耗的資源越多,當(dāng)用戶(hù)請(qǐng)求越頻繁,系統(tǒng)消耗資源也會(huì)越來(lái)越大。如果我們多部署服務(wù)器的目的只是想保證系統(tǒng)的穩(wěn)定性,采用這種方案還是不錯(cuò)的,不過(guò)web應(yīng)用最好部署少點(diǎn),這樣才不會(huì)影響到web應(yīng)用的性能問(wèn)題,如果我們還想提升網(wǎng)站的并發(fā)量那么就得采取其他的方案了。
時(shí)下使用的比較多的方案就是使用獨(dú)立的緩存服務(wù)器,也就是將session的數(shù)據(jù)存儲(chǔ)在一臺(tái)獨(dú)立的服務(wù)器上,如果覺(jué)得存在一臺(tái)服務(wù)器不安全,那么可以使用memcached這樣的分布式緩存服務(wù)器進(jìn)行存儲(chǔ),這樣既可以滿(mǎn)足了網(wǎng)站穩(wěn)定性問(wèn)題也提升了網(wǎng)站的并發(fā)能力。
不過(guò)早期的淘寶在這個(gè)問(wèn)題解決更加巧妙,他們將session的信息直接存儲(chǔ)到瀏覽器的cookie里,每次請(qǐng)求cookie信息都會(huì)隨著http一起傳遞到web服務(wù)器,這樣就避免了web服務(wù)器之間session信息同步的問(wèn)題,這種方案會(huì)讓很多人詬病,詬病的原因是cookie的不安全性是總所周知的,如果有人惡意截取cookie信息那么網(wǎng)站不就不安全了嗎?這個(gè)答案還真不好說(shuō),但是我覺(jué)得我們僅僅是跟蹤用戶(hù)的狀態(tài),把session存在cookie里其實(shí)也沒(méi)什么大不了的。
其實(shí)如此專(zhuān)業(yè)的淘寶這么做其實(shí)還是很有深意的,還記得本文開(kāi)篇提到的hao123網(wǎng)站,它是可以承載高并發(fā)的網(wǎng)站,它之所以可以做到這一點(diǎn),原因很簡(jiǎn)單它是個(gè)靜態(tài)網(wǎng)站,靜態(tài)網(wǎng)站的特點(diǎn)就是不需要記錄用戶(hù)的狀態(tài),靜態(tài)網(wǎng)站的服務(wù)器不需要使用寶貴的系統(tǒng)資源來(lái)存儲(chǔ)大量的session會(huì)話(huà)信息,這樣它就有更多系統(tǒng)資源來(lái)處理請(qǐng)求,而早期淘寶將cookie存在客戶(hù)端也是為了達(dá)到這樣的目的,所以這個(gè)方案在淘寶網(wǎng)站架構(gòu)里還是使用了很長(zhǎng)時(shí)間的。
在我的公司里客戶(hù)端的請(qǐng)求到達(dá)web服務(wù)器之前,會(huì)先到F5,F(xiàn)5是一個(gè)用來(lái)做負(fù)載均衡的硬件設(shè)備,它的作用是將用戶(hù)請(qǐng)求均勻的分發(fā)到后臺(tái)的服務(wù)器集群,F(xiàn)5是硬件的負(fù)載均衡解決方案,如果我們沒(méi)那么多錢(qián)買(mǎi)這樣的設(shè)備,也有軟件的負(fù)載均衡解決方案,這個(gè)方案就是大名鼎鼎的LVS了!
這些負(fù)載均衡設(shè)備除了可以分發(fā)請(qǐng)求外它們還有個(gè)能力,這個(gè)能力是根據(jù)http協(xié)議的特點(diǎn)設(shè)計(jì)的,一個(gè)http請(qǐng)求從客戶(hù)端到達(dá)最終的存儲(chǔ)服務(wù)器之前可能會(huì)經(jīng)過(guò)很多不同的設(shè)備,如果我們把一個(gè)請(qǐng)求比作高速公路上的一輛汽車(chē),這些設(shè)備也可以叫做這些節(jié)點(diǎn)就是高速路上的收費(fèi)站,這些收費(fèi)站都能根據(jù)自己的需求改變http報(bào)文的內(nèi)容,所以負(fù)載均衡設(shè)備可以記住每個(gè)sessionid值對(duì)應(yīng)的后臺(tái)服務(wù)器。
當(dāng)一個(gè)帶有sessionid值的請(qǐng)求通過(guò)負(fù)載均衡設(shè)備時(shí)候,負(fù)載均衡設(shè)備會(huì)根據(jù)該sessionid值直接找到指定的web服務(wù)器,這種做法有個(gè)專(zhuān)有名詞就是session粘滯,這種做法也比那種session信息在不同服務(wù)器之間拷貝復(fù)制要高效,不過(guò)該做法還是比存cookie的效率低下,而且對(duì)于網(wǎng)站的穩(wěn)定性也有一定影響即如果某臺(tái)服務(wù)器掛掉了,那么連接到該服務(wù)器的用戶(hù)的會(huì)話(huà)都會(huì)失效。
解決session的問(wèn)題的本質(zhì)也就是解決session的存儲(chǔ)問(wèn)題,其本質(zhì)也就是解決網(wǎng)站的存儲(chǔ)問(wèn)題,一個(gè)初建的網(wǎng)站在早期的運(yùn)營(yíng)期需要解決的問(wèn)題基本都是由存儲(chǔ)導(dǎo)致的。上文里我提到時(shí)下很多新建的web應(yīng)用會(huì)將服務(wù)器部署后云平臺(tái)里,好的云平臺(tái)里或許會(huì)幫助我們解決負(fù)載均衡和session同步的問(wèn)題,但是云平臺(tái)里有個(gè)問(wèn)題很難解決那就是數(shù)據(jù)庫(kù)的存儲(chǔ)問(wèn)題,如果我們使用的云平臺(tái)發(fā)生了重大事故,導(dǎo)致云平臺(tái)存儲(chǔ)的數(shù)據(jù)丟失,這種會(huì)不會(huì)導(dǎo)致我們?cè)谠破脚_(tái)里數(shù)據(jù)庫(kù)的信息也會(huì)丟失了,雖然這個(gè)事情的概率不高,但是發(fā)生這種事情的幾率還是有的,雖然很多云平臺(tái)都聲稱(chēng)自己多么可靠,但是真實(shí)可靠性有多高不是局中人還真不清楚哦,因此使用云平臺(tái)我們首要考慮的就是要做好數(shù)據(jù)備份,假如真發(fā)生了數(shù)據(jù)丟失,對(duì)于一個(gè)快速成長(zhǎng)的網(wǎng)站而言可能非常致命。
六,網(wǎng)站的瓶頸
寫(xiě)到這里一個(gè)嬰兒般的網(wǎng)站就這樣被我們創(chuàng)造出來(lái)了,我們希望網(wǎng)站能健康快速的成長(zhǎng),如果網(wǎng)站真的按我們預(yù)期成長(zhǎng)了,那么一定會(huì)有一天我們制造的寶寶屋已經(jīng)滿(mǎn)足不了現(xiàn)實(shí)的需求,這個(gè)時(shí)候我們應(yīng)該如何抉擇了?換掉,全部換掉,使用新的架構(gòu)例如我們以前長(zhǎng)提的SOA架構(gòu),分布式技術(shù),這個(gè)方法不錯(cuò),但是SOA和分布式技術(shù)是很難的,成本是很高的,如果這時(shí)候我們通過(guò)添加幾臺(tái)服務(wù)器就能解決問(wèn)題的話(huà),我們絕對(duì)不要去選擇什么分布式技術(shù),因?yàn)檫@個(gè)成本太高了。上面我講到幾種session共享的方案,這個(gè)方案解決了應(yīng)用的水平擴(kuò)展問(wèn)題,那么當(dāng)我們網(wǎng)站出現(xiàn)瓶頸時(shí)候就多加幾臺(tái)服務(wù)器不就行了嗎?那么這里就有個(gè)問(wèn)題了,當(dāng)網(wǎng)站成長(zhǎng)很快,網(wǎng)站首先碰到的瓶頸到底是哪個(gè)方面的問(wèn)題?
本人是做金融網(wǎng)站的,我們所做的網(wǎng)站有個(gè)特點(diǎn)就是當(dāng)用戶(hù)訪問(wèn)到我們所做的網(wǎng)站時(shí)候,目的都很明確就是為了付錢(qián),用戶(hù)到了我們所做的網(wǎng)站時(shí)候都希望能快點(diǎn),再快點(diǎn)完成本網(wǎng)站的操作,很多用戶(hù)在使用我們做的網(wǎng)站時(shí)候不太去關(guān)心網(wǎng)站的其他內(nèi)容,因此我們所做的網(wǎng)站相對(duì)于數(shù)據(jù)庫(kù)而言就是讀寫(xiě)比例其實(shí)非常的均勻,甚至很多場(chǎng)景寫(xiě)比讀要高,這個(gè)特點(diǎn)是很多專(zhuān)業(yè)服務(wù)網(wǎng)站的特點(diǎn),其實(shí)這樣的網(wǎng)站和企業(yè)開(kāi)發(fā)的特點(diǎn)很類(lèi)似:業(yè)務(wù)操作的重要度超過(guò)了業(yè)務(wù)展示的重要度,因此專(zhuān)業(yè)性網(wǎng)站吸納企業(yè)系統(tǒng)開(kāi)發(fā)的特點(diǎn)比較多。但是大部分我們?nèi)粘3S玫木W(wǎng)站,我們逗留時(shí)間很長(zhǎng)的網(wǎng)站按數(shù)據(jù)庫(kù)角度而言往往是讀遠(yuǎn)遠(yuǎn)大于寫(xiě),例如大眾點(diǎn)評(píng)網(wǎng)站它的讀寫(xiě)比率往往是9比1。
12306或許是中國(guó)最著名的網(wǎng)站之一,我記得12306早期經(jīng)常出現(xiàn)一個(gè)問(wèn)題就是用戶(hù)登錄老是登不上,甚至在高峰期整個(gè)網(wǎng)站掛掉,頁(yè)面顯示503網(wǎng)站拒絕訪問(wèn)的問(wèn)題,這個(gè)現(xiàn)象很好理解就是網(wǎng)站并發(fā)高了,大量人去登錄網(wǎng)站,購(gòu)票,系統(tǒng)掛掉了,最后所有的人都不能使用網(wǎng)站了。
當(dāng)網(wǎng)站出現(xiàn)503拒絕訪問(wèn)時(shí)候,那么這個(gè)網(wǎng)站就出現(xiàn)了最致命的問(wèn)題,解決大用戶(hù)訪問(wèn)的確是個(gè)超級(jí)難題,但是當(dāng)高并發(fā)無(wú)法避免時(shí)候,整個(gè)網(wǎng)站都不能使用這個(gè)只能說(shuō)網(wǎng)站設(shè)計(jì)上發(fā)生了致命錯(cuò)誤,一個(gè)好的網(wǎng)站設(shè)計(jì)在應(yīng)對(duì)超出自己能力的并發(fā)時(shí)候我們首先應(yīng)該是不讓他掛掉,因?yàn)檫@種結(jié)果是誰(shuí)都不能使用,我們希望那些在可接受的請(qǐng)求下,讓在可接受請(qǐng)求范圍內(nèi)的請(qǐng)求還是可以正常使用,超出的請(qǐng)求可以被拒絕,但是它們絕對(duì)不能影響到全網(wǎng)站的穩(wěn)定性,現(xiàn)在我們看到了12306網(wǎng)站的峰值從未減少過(guò),而且是越變?cè)蕉?,但?2306出現(xiàn)全站掛掉的問(wèn)題是越來(lái)越少了。通過(guò)12036網(wǎng)站改變我們更進(jìn)一步思考下網(wǎng)站的瓶頸問(wèn)題。
排除一些不可控的因素,網(wǎng)站在高并發(fā)下掛掉的原因90%都是因?yàn)閿?shù)據(jù)庫(kù)不堪重負(fù)所致,而應(yīng)用的瓶頸往往只有在解決了存儲(chǔ)瓶頸后才會(huì)暴露,那么我們要升級(jí)網(wǎng)站能力的第一步工作就是提升數(shù)據(jù)庫(kù)的承載能力,對(duì)于讀遠(yuǎn)大于寫(xiě)的網(wǎng)站我們采取的方式就是將數(shù)據(jù)庫(kù)從讀寫(xiě)這個(gè)角度拆分,具體操作就是將數(shù)據(jù)庫(kù)讀寫(xiě)分離,如下圖所示:
我們這時(shí)要設(shè)計(jì)兩個(gè)數(shù)據(jù)庫(kù),一個(gè)數(shù)據(jù)庫(kù)主要負(fù)責(zé)寫(xiě)操作我們稱(chēng)之為主庫(kù),一個(gè)數(shù)據(jù)庫(kù)專(zhuān)門(mén)負(fù)責(zé)讀操作我們稱(chēng)之為副庫(kù),副庫(kù)的數(shù)據(jù)都是從主庫(kù)導(dǎo)入的,數(shù)據(jù)庫(kù)的讀寫(xiě)分離可以有效的保證關(guān)鍵數(shù)據(jù)的安全性,但是有個(gè)缺點(diǎn)就是當(dāng)用戶(hù)瀏覽數(shù)據(jù)時(shí)候,讀的數(shù)據(jù)都會(huì)有點(diǎn)延時(shí),這種延時(shí)比起全站不可用那肯定是可以接受的。
不過(guò)針對(duì)12306的場(chǎng)景,僅僅讀寫(xiě)分離還是遠(yuǎn)遠(yuǎn)不夠的,特別是負(fù)責(zé)讀操作的副庫(kù),在高訪問(wèn)下也是很容易達(dá)到性能的瓶頸的,那么我們就得使用新的解決方案:使用分布式緩存,不過(guò)緩存的缺點(diǎn)就是不能有效的實(shí)時(shí)更新,因此我們使用緩存前首先要對(duì)讀操作的數(shù)據(jù)進(jìn)行分類(lèi),對(duì)于那些經(jīng)常不發(fā)生變化的數(shù)據(jù)可以事先存放到緩存里,緩存的訪問(wèn)效率很高,這樣會(huì)讓讀更加高效,同時(shí)也減輕了數(shù)據(jù)庫(kù)的訪問(wèn)壓力。
至于用于寫(xiě)操作的主庫(kù),因?yàn)榇蟛糠志W(wǎng)站讀寫(xiě)的比例是嚴(yán)重失衡,所以讓主庫(kù)達(dá)到瓶頸還是比較難的,不過(guò)主庫(kù)也有一個(gè)讀的壓力就是主庫(kù)和副庫(kù)的數(shù)據(jù)同步問(wèn)題,不過(guò)同步時(shí)候數(shù)據(jù)都是批量操作,而不是像請(qǐng)求那樣進(jìn)行少量數(shù)據(jù)讀取操作,讀取操作特別多,因此想達(dá)到瓶頸還是有一定的難度的。聽(tīng)人說(shuō),美國(guó)牛逼的facebook對(duì)數(shù)據(jù)的任何操作都是事先合并為批量操作,從而達(dá)到減輕數(shù)據(jù)庫(kù)壓力的目的。
七,海量數(shù)據(jù)檢索
上面的方案我們可以保證在高并發(fā)下網(wǎng)站的穩(wěn)定性,但是針對(duì)于讀,如果數(shù)據(jù)量太大了,就算網(wǎng)站不掛掉了,用戶(hù)能很快的在海量數(shù)據(jù)里檢索到所需要的信息又成為了網(wǎng)站的一個(gè)瓶頸,如果用戶(hù)需要很長(zhǎng)時(shí)間才能獲得自己想要的數(shù)據(jù),很多用戶(hù)會(huì)失去耐心從而放棄對(duì)網(wǎng)站的使用,那么這個(gè)問(wèn)題又該如何解決了?
解決方案就是我們經(jīng)常使用的百度,谷歌哪里得來(lái),對(duì)于海量數(shù)據(jù)的讀我們可以采用搜索技術(shù),我們可以將數(shù)據(jù)庫(kù)的數(shù)據(jù)導(dǎo)出到文件里,對(duì)文件建立索引,使用倒排索引技術(shù)來(lái)檢索信息,我們看到了百度,谷歌有整個(gè)互聯(lián)網(wǎng)的信息我們?nèi)稳荒芎芸斓臋z索到數(shù)據(jù),搜索技術(shù)是解決快速讀取數(shù)據(jù)的一個(gè)有效方案,不過(guò)這個(gè)讀取還是和數(shù)據(jù)庫(kù)的讀取有所區(qū)別的,如果用戶(hù)查詢(xún)的數(shù)據(jù)是通過(guò)數(shù)據(jù)庫(kù)的主鍵字段,或者是通過(guò)很明確的建立了索引的字段來(lái)檢索,那么數(shù)據(jù)庫(kù)的查詢(xún)效率是很高的,但是使用網(wǎng)站的人跟喜歡使用一些模糊查詢(xún)來(lái)查找自己的信息,那么這個(gè)操作在數(shù)據(jù)庫(kù)里就是個(gè)like操作,like操作在數(shù)據(jù)庫(kù)里效率是很低的,這個(gè)時(shí)候使用搜索技術(shù)的優(yōu)勢(shì)就非常明顯了,搜索技術(shù)非常適合于模糊查詢(xún)操作。