建站
咨詢
售后
建站咨詢
新聞中心
隨著國(guó)內(nèi)服務(wù)共享化的熱潮普及，共享單車(chē)，共享雨傘，共享充電寶等各種服務(wù)如雨后春筍，隨之而來(lái)的LBS服務(wù)定位問(wèn)題成為了后端服務(wù)的一個(gè)挑戰(zhàn)。MongoDB對(duì)LBS查詢的支持較為友好，也是各大LBS服務(wù)商的首選數(shù)據(jù)庫(kù)。騰訊云MongoDB團(tuán)隊(duì)在運(yùn)營(yíng)中發(fā)現(xiàn)，原生MongoDB在LBS服務(wù)場(chǎng)景下有較大的性能瓶頸，經(jīng)騰訊云團(tuán)隊(duì)專業(yè)的定位分析與優(yōu)化后，云MongoDB在LBS服務(wù)的綜合性能上，有10倍以上的提升。
騰訊云MongoDB提供的優(yōu)異綜合性能，為國(guó)內(nèi)各大LBS服務(wù)商，例如摩拜單車(chē)等，提供了強(qiáng)有力的保障。
LBS業(yè)務(wù)特點(diǎn)
以共享單車(chē)服務(wù)為例，LBS業(yè)務(wù)具有2個(gè)特點(diǎn)，分別是時(shí)間周期性和坐標(biāo)分布不均勻。
一.時(shí)間周期性
高峰期與低谷期的QPS量相差明顯，并且高峰期和低峰期的時(shí)間點(diǎn)相對(duì)固定。
二.坐標(biāo)分布不均勻
坐地鐵的上班族，如果留意可能會(huì)發(fā)現(xiàn)，在上班早高峰時(shí)，地鐵周?chē)鷶[滿了共享單車(chē)，而下班 時(shí)段，地鐵周?chē)墓蚕韱诬?chē)數(shù)量非常少。如下圖，經(jīng)緯度(121，31.44)附近集中了99%以上 的坐標(biāo)。此外，一些特殊事件也會(huì)造成點(diǎn)的分布不均勻，例如深圳灣公園在特殊家假日涌入大量的客戶，同時(shí)這個(gè)地域也會(huì)投放大量的單車(chē)。部分地域單車(chē)量非常集中，而其他地域就非常稀疏。
MongoDB的LBS服務(wù)原理
MongoDB中使用2d_index 或2d_sphere_index來(lái)創(chuàng)建地理位置索引(geoIndex),兩者差別不大，下面我們以2d_index為例來(lái)介紹。
一.2D索引的創(chuàng)建與使用
- db.coll.createIndex({"lag":"2d"}, {"bits":int}))
- 通過(guò)上述命令來(lái)創(chuàng)建一個(gè)2d索引，索引的精度通過(guò)bits來(lái)指定，bits越大，索引的精度就越高。更大的bits帶來(lái)的插入的overhead可以忽略不計(jì)
- db.runCommand({
- geoNear: tableName,
- maxDistance: 0.0001567855942887398,
- distanceMultiplier: 6378137.0,
- num: 30,
- near: [ 113.8679388183982, 22.58905429302385 ],
- spherical: true|false})
通過(guò)上述命令來(lái)查詢一個(gè)索引，其中spherical：true|false 表示應(yīng)該如何理解創(chuàng)建的2d索引，false表示將索引理解為平面2d索引，true表示將索引理解為球面經(jīng)緯度索引。這一點(diǎn)比較有意思，一個(gè)2d索引可以表達(dá)兩種含義，而不同的含義是在查詢時(shí)被理解的，而不是在索引創(chuàng)建時(shí)。
二.2D索引的理論
MongoDB 使用GeoHash的技術(shù)來(lái)構(gòu)建2d索引(見(jiàn)wiki geohash 文字鏈https://en.wikipedia.org/wiki/Geohash )。MongoDB使用平面四叉樹(shù)劃分的方式來(lái)生成GeoHashId，每條記錄有一個(gè)GeoHashId，通過(guò)GeoHashId->RecordId的索引映射方式存儲(chǔ)在Btree中
很顯然的，一個(gè)2bits的精度能把平面分為4個(gè)grid，一個(gè)4bits的精度能把平面分為16個(gè)grid。
2d索引的默認(rèn)精度是長(zhǎng)寬各為26，索引把地球分為(2^26)(2^26)塊，每一塊的邊長(zhǎng)估算為2PI6371000/(1<<26) = 0.57 米
mongodb的官網(wǎng)上說(shuō)的60cm的精度就是這么估算出來(lái)的
By default, a 2d index on legacy coordinate pairs uses 26 bits of precision, which isroughly equivalent to 2 feet or 60 centimeters of precision using the default range of-180 to 180
三.2D索引在Mongodb中的存儲(chǔ)
上面我們講到Mongodb使用平面四叉樹(shù)的方式計(jì)算Geohash。事實(shí)上，平面四叉樹(shù)僅存在于運(yùn)算的過(guò)程中，在實(shí)際存儲(chǔ)中并不會(huì)被使用到。
插入
對(duì)于一個(gè)經(jīng)緯度坐標(biāo)[x,y]，MongoDb計(jì)算出該坐標(biāo)在2d平面內(nèi)的grid編號(hào)，該編號(hào)為是一個(gè)52bit的int64類型，該類型被用作btree的key，因此實(shí)際數(shù)據(jù)是按照 {GeoHashId->RecordValue}的方式被插入到btree中的。
查詢
對(duì)于geo2D索引的查詢，常用的有g(shù)eoNear和geoWithin兩種。geoNear查找距離某個(gè)點(diǎn)最近的N個(gè)點(diǎn)的坐標(biāo)并返回，該需求可以說(shuō)是構(gòu)成了LBS服務(wù)的基礎(chǔ)(陌陌，滴滴，摩拜)，geoWithin是查詢一個(gè)多邊形內(nèi)的所有點(diǎn)并返回。我們著重介紹使用最廣泛的geoNear查詢。
geoNear的查詢過(guò)程,查詢語(yǔ)句如下
- db.runCommand(
- {
- geoNear: "places", //table Name
- near: [ -73.9667, 40.78 ] , // central point
- spherical: true, // treat the index as a spherical index
- query: { category: "public" } // filters
- maxDistance: 0.0001531 // distance in about one kilometer
- }
geoNear可以理解為一個(gè)從起始點(diǎn)開(kāi)始的不斷向外擴(kuò)散的環(huán)形搜索過(guò)程。如下圖所示：
由于圓自身的性質(zhì)，外環(huán)的任意點(diǎn)到圓心的距離一定大于內(nèi)環(huán)任意點(diǎn)到圓心的距離，所以以圓
環(huán)進(jìn)行擴(kuò)張迭代的好處是：
1)減少需要排序比較的點(diǎn)的個(gè)數(shù)
2)能夠盡早發(fā)現(xiàn)滿足條件的點(diǎn)從而返回，避免不必要的搜索
MongoDB在實(shí)現(xiàn)的細(xì)節(jié)中，如果內(nèi)環(huán)搜索到的點(diǎn)數(shù)過(guò)少，圓環(huán)每次擴(kuò)張的步長(zhǎng)會(huì)倍增
MongoDB LBS服務(wù)遇到的問(wèn)題
部分大客戶在使用MongoDB的geoNear功能查找附近的對(duì)象時(shí)，經(jīng)常會(huì)發(fā)生慢查詢較多的問(wèn)題，早高峰壓力是低谷時(shí)段的10-20倍，坐標(biāo)不均勻的情況慢查詢嚴(yán)重，瀕臨雪崩。初步分析發(fā)現(xiàn)，這些查詢掃描了過(guò)多的點(diǎn)集。
如下圖，查找500米范圍內(nèi)，距離最近的10條記錄，花費(fèi)了500ms，掃描了24000+的記錄。類似的慢查詢占據(jù)了高峰期5%左右的查詢量
測(cè)試環(huán)境復(fù)現(xiàn)與定位
排查數(shù)據(jù)庫(kù)的性能問(wèn)題，主要從鎖等待,IO等待,CPU消耗三封面分析。上面的截圖掃描了過(guò)多的記錄，直覺(jué)上是CPU或者IO消耗性的瓶頸。為了嚴(yán)謹(jǐn)起見(jiàn)，我們?cè)跍y(cè)試環(huán)境復(fù)現(xiàn)后，發(fā)現(xiàn)慢日志中無(wú)明顯的timeAcquiringMicroseconds項(xiàng)排除了MongoDB執(zhí)行層面的鎖競(jìng)爭(zhēng)問(wèn)題，并選用較大內(nèi)存的機(jī)器使得數(shù)據(jù)常駐內(nèi)存，發(fā)現(xiàn)上述用例依舊需要200ms以上的執(zhí)行時(shí)間。10核的CPU資源針對(duì)截圖中的case，只能支持50QPS。
為何掃描集如此大
上面我們說(shuō)過(guò)，MongoDB搜索距離最近的點(diǎn)的過(guò)程是一個(gè)環(huán)形擴(kuò)張的過(guò)程，如果內(nèi)環(huán)滿足條件的點(diǎn)不夠多，每次的擴(kuò)張半徑都會(huì)倍增。因此在遇到內(nèi)環(huán)點(diǎn)稀少，外環(huán)有密集點(diǎn)的場(chǎng)景時(shí)，容易陷入BadCase。如下圖，我們希望找到離中心點(diǎn)距離最近的三個(gè)點(diǎn)。由于圓環(huán)擴(kuò)張?zhí)?，外環(huán)做了很多的無(wú)用掃描與排序。
這樣的用例很符合實(shí)際場(chǎng)景，早高峰車(chē)輛聚集在地鐵周?chē)?，你從家出發(fā)一路向地鐵，邊走邊找，共享單車(chē)軟件上動(dòng)態(tài)搜索距你最近的10輛車(chē)，附近只有三兩輛，于是擴(kuò)大搜索半徑到地鐵周?chē)瑢⒌罔F周?chē)乃袔浊лv車(chē)都掃描計(jì)算一遍，返回距離你最近的其余的七八輛
問(wèn)題的解決
問(wèn)題我們已經(jīng)知道了，我們對(duì)此的優(yōu)化方式是控制每一圈的搜索量，為此我們?yōu)間eoNear命令增加了兩個(gè)參數(shù)，將其傳入NearStage中。hintCorrectNum可以控制結(jié)果品質(zhì)的下限，返回的前N個(gè)一定是最靠近中心點(diǎn)的N個(gè)點(diǎn)。hintScan用以控制掃描集的大小的上限。
hintScan: 已經(jīng)掃描的點(diǎn)集大小大于hintScan后，做模糊處理。
hintCorrectNum:已經(jīng)返回的結(jié)果數(shù)大于hintCorrectNum后，做模糊處理。
該優(yōu)化本質(zhì)上是通過(guò)犧牲品質(zhì)來(lái)盡快返回結(jié)果。對(duì)于國(guó)內(nèi)大部分LBS服務(wù)來(lái)說(shuō)，完全的嚴(yán)格最近并不是必要的。且可以通過(guò)控制參數(shù)獲得嚴(yán)格最近的效果。在搜索過(guò)程中，密集的點(diǎn)落到一個(gè)環(huán)內(nèi)，本身距離相差也不會(huì)不大。該優(yōu)化在上線后，將部分大客戶的MongoDB性能上限從單機(jī)1000QPS提升了10倍到10000QPS以上。
和Redis3.2的對(duì)比
Redis3.2也加入了地理位置查詢的功能，我們也將開(kāi)源Redis和云數(shù)據(jù)庫(kù)MongoDB進(jìn)行對(duì)比。
Redis使用方式：GEORADIUS appname 120.993965 31.449034 500 m count 30 asc。在密集數(shù)據(jù)集場(chǎng)景下，使用騰訊云MongoDB和開(kāi)源的Redis進(jìn)行了性能對(duì)比。下圖是在密集數(shù)據(jù)集上，在24核CPU機(jī)器上，MongoDB單實(shí)例與Redis單實(shí)例的測(cè)試對(duì)比。需要注意的是Redis本身是單線程的內(nèi)存緩存數(shù)據(jù)庫(kù)。MongoDB是多線程的高可用持久化的數(shù)據(jù)庫(kù)，兩者的使用場(chǎng)景有較大不同。
總結(jié)
MongoDB原生的geoNear接口是國(guó)內(nèi)各大LBS應(yīng)用的主流選擇。原生MongoDB在點(diǎn)集稠密的情況下，geoNear接口效率會(huì)急劇下降，單機(jī)甚至不到1000QPS。騰訊云MongoDB團(tuán)隊(duì)對(duì)此進(jìn)行了持續(xù)的優(yōu)化，在不影響效果的前提下，geoNear的效率有10倍以上的提升，為我們的客戶如摩拜提供了強(qiáng)力的支持，同時(shí)相比Redis3.2也有較大的性能優(yōu)勢(shì)。
當(dāng)前名稱：云MongoDB優(yōu)化讓LBS服務(wù)性能提升十倍
URL網(wǎng)址：http://www.5511xx.com/article/djeceho.html
