隨著國內(nèi)服務共享化的熱潮普及，共享單車，共享雨傘，共享充電寶等各種服務如雨后春筍，隨之而來的LBS服務定位問題成為了后端服務的一個挑戰(zhàn)。MongoDB對LBS查詢的支持較為友好，也是各大LBS服務商的首選數(shù)據(jù)庫。騰訊云MongoDB團隊在運營中發(fā)現(xiàn)，原生MongoDB在LBS服務場景下有較大的性能瓶頸，經(jīng)騰訊云團隊專業(yè)的定位分析與優(yōu)化后，云MongoDB在LBS服務的綜合性能上，有10倍以上的提升。

騰訊云MongoDB提供的優(yōu)異綜合性能，為國內(nèi)各大LBS服務商，例如摩拜單車等，提供了強有力的保障。

LBS業(yè)務特點

以共享單車服務為例，LBS業(yè)務具有2個特點，分別是時間周期性和坐標分布不均勻。

一.時間周期性

高峰期與低谷期的QPS量相差明顯，并且高峰期和低峰期的時間點相對固定。

二.坐標分布不均勻

坐地鐵的上班族，如果留意可能會發(fā)現(xiàn)，在上班早高峰時，地鐵周圍擺滿了共享單車，而下班 時段，地鐵周圍的共享單車數(shù)量非常少。如下圖，經(jīng)緯度(121，31.44)附近集中了99%以上 的坐標。此外，一些特殊事件也會造成點的分布不均勻，例如深圳灣公園在特殊家假日涌入大量的客戶，同時這個地域也會投放大量的單車。部分地域單車量非常集中，而其他地域就非常稀疏。

MongoDB的LBS服務原理

MongoDB中使用2d_index 或2d_sphere_index來創(chuàng)建地理位置索引(geoIndex),兩者差別不大，下面我們以2d_index為例來介紹。

一.2D索引的創(chuàng)建與使用

db.coll.createIndex({"lag":"2d"}, {"bits":int})) 
通過上述命令來創(chuàng)建一個2d索引，索引的精度通過bits來指定，bits越大，索引的精度就越高。更大的bits帶來的插入的overhead可以忽略不計 
db.runCommand({ 
geoNear: tableName, 
maxDistance: 0.0001567855942887398, 
distanceMultiplier: 6378137.0, 
num: 30, 
near: [ 113.8679388183982, 22.58905429302385 ], 
spherical: true|false}) 

通過上述命令來查詢一個索引，其中spherical：true|false 表示應該如何理解創(chuàng)建的2d索引，false表示將索引理解為平面2d索引，true表示將索引理解為球面經(jīng)緯度索引。這一點比較有意思，一個2d索引可以表達兩種含義，而不同的含義是在查詢時被理解的，而不是在索引創(chuàng)建時。

二.2D索引的理論

MongoDB 使用GeoHash的技術來構(gòu)建2d索引(見wiki geohash 文字鏈https://en.wikipedia.org/wiki/Geohash )。MongoDB使用平面四叉樹劃分的方式來生成GeoHashId，每條記錄有一個GeoHashId，通過GeoHashId->RecordId的索引映射方式存儲在Btree中

很顯然的，一個2bits的精度能把平面分為4個grid，一個4bits的精度能把平面分為16個grid。

2d索引的默認精度是長寬各為26，索引把地球分為(2^26)(2^26)塊，每一塊的邊長估算為2PI6371000/(1<<26) = 0.57 米

mongodb的官網(wǎng)上說的60cm的精度就是這么估算出來的

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中的存儲

上面我們講到Mongodb使用平面四叉樹的方式計算Geohash。事實上，平面四叉樹僅存在于運算的過程中，在實際存儲中并不會被使用到。

插入

對于一個經(jīng)緯度坐標[x,y]，MongoDb計算出該坐標在2d平面內(nèi)的grid編號，該編號為是一個52bit的int64類型，該類型被用作btree的key，因此實際數(shù)據(jù)是按照 {GeoHashId->RecordValue}的方式被插入到btree中的。

查詢

對于geo2D索引的查詢，常用的有geoNear和geoWithin兩種。geoNear查找距離某個點最近的N個點的坐標并返回，該需求可以說是構(gòu)成了LBS服務的基礎(陌陌，滴滴，摩拜)，geoWithin是查詢一個多邊形內(nèi)的所有點并返回。我們著重介紹使用最廣泛的geoNear查詢。

geoNear的查詢過程,查詢語句如下

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可以理解為一個從起始點開始的不斷向外擴散的環(huán)形搜索過程。如下圖所示：

由于圓自身的性質(zhì)，外環(huán)的任意點到圓心的距離一定大于內(nèi)環(huán)任意點到圓心的距離，所以以圓

環(huán)進行擴張迭代的好處是：

1)減少需要排序比較的點的個數(shù)

2)能夠盡早發(fā)現(xiàn)滿足條件的點從而返回，避免不必要的搜索

MongoDB在實現(xiàn)的細節(jié)中，如果內(nèi)環(huán)搜索到的點數(shù)過少，圓環(huán)每次擴張的步長會倍增

MongoDB LBS服務遇到的問題

部分大客戶在使用MongoDB的geoNear功能查找附近的對象時，經(jīng)常會發(fā)生慢查詢較多的問題，早高峰壓力是低谷時段的10-20倍，坐標不均勻的情況慢查詢嚴重，瀕臨雪崩。初步分析發(fā)現(xiàn)，這些查詢掃描了過多的點集。

如下圖，查找500米范圍內(nèi)，距離最近的10條記錄，花費了500ms，掃描了24000+的記錄。類似的慢查詢占據(jù)了高峰期5%左右的查詢量

測試環(huán)境復現(xiàn)與定位

排查數(shù)據(jù)庫的性能問題，主要從鎖等待,IO等待,CPU消耗三封面分析。上面的截圖掃描了過多的記錄，直覺上是CPU或者IO消耗性的瓶頸。為了嚴謹起見，我們在測試環(huán)境復現(xiàn)后，發(fā)現(xiàn)慢日志中無明顯的timeAcquiringMicroseconds項排除了MongoDB執(zhí)行層面的鎖競爭問題，并選用較大內(nèi)存的機器使得數(shù)據(jù)常駐內(nèi)存，發(fā)現(xiàn)上述用例依舊需要200ms以上的執(zhí)行時間。10核的CPU資源針對截圖中的case，只能支持50QPS。

為何掃描集如此大

上面我們說過，MongoDB搜索距離最近的點的過程是一個環(huán)形擴張的過程，如果內(nèi)環(huán)滿足條件的點不夠多，每次的擴張半徑都會倍增。因此在遇到內(nèi)環(huán)點稀少，外環(huán)有密集點的場景時，容易陷入BadCase。如下圖，我們希望找到離中心點距離最近的三個點。由于圓環(huán)擴張?zhí)欤猸h(huán)做了很多的無用掃描與排序。

這樣的用例很符合實際場景，早高峰車輛聚集在地鐵周圍，你從家出發(fā)一路向地鐵，邊走邊找，共享單車軟件上動態(tài)搜索距你最近的10輛車，附近只有三兩輛，于是擴大搜索半徑到地鐵周圍，將地鐵周圍的所有幾千輛車都掃描計算一遍，返回距離你最近的其余的七八輛

問題的解決

問題我們已經(jīng)知道了，我們對此的優(yōu)化方式是控制每一圈的搜索量，為此我們?yōu)間eoNear命令增加了兩個參數(shù)，將其傳入NearStage中。hintCorrectNum可以控制結(jié)果品質(zhì)的下限，返回的前N個一定是最靠近中心點的N個點。hintScan用以控制掃描集的大小的上限。

hintScan: 已經(jīng)掃描的點集大小大于hintScan后，做模糊處理。

hintCorrectNum:已經(jīng)返回的結(jié)果數(shù)大于hintCorrectNum后，做模糊處理。

該優(yōu)化本質(zhì)上是通過犧牲品質(zhì)來盡快返回結(jié)果。對于國內(nèi)大部分LBS服務來說，完全的嚴格最近并不是必要的。且可以通過控制參數(shù)獲得嚴格最近的效果。在搜索過程中，密集的點落到一個環(huán)內(nèi)，本身距離相差也不會不大。該優(yōu)化在上線后，將部分大客戶的MongoDB性能上限從單機1000QPS提升了10倍到10000QPS以上。

和Redis3.2的對比

Redis3.2也加入了地理位置查詢的功能，我們也將開源Redis和云數(shù)據(jù)庫MongoDB進行對比。

Redis使用方式：GEORADIUS appname 120.993965 31.449034 500 m count 30 asc。在密集數(shù)據(jù)集場景下，使用騰訊云MongoDB和開源的Redis進行了性能對比。下圖是在密集數(shù)據(jù)集上，在24核CPU機器上，MongoDB單實例與Redis單實例的測試對比。需要注意的是Redis本身是單線程的內(nèi)存緩存數(shù)據(jù)庫。MongoDB是多線程的高可用持久化的數(shù)據(jù)庫，兩者的使用場景有較大不同。

總結(jié)

MongoDB原生的geoNear接口是國內(nèi)各大LBS應用的主流選擇。原生MongoDB在點集稠密的情況下，geoNear接口效率會急劇下降，單機甚至不到1000QPS。騰訊云MongoDB團隊對此進行了持續(xù)的優(yōu)化，在不影響效果的前提下，geoNear的效率有10倍以上的提升，為我們的客戶如摩拜提供了強力的支持，同時相比Redis3.2也有較大的性能優(yōu)勢。

原文鏈接：https://cloud.tencent.com/community/article/723875

【本文是51CTO專欄作者“騰訊云技術社區(qū)”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】

戳這里，看該作者更多好文