雲MongoDB優化讓LBS服務性能提高十倍

時間 2019-11-08

標籤 mongodb 優化 lbs 服務性能提高十倍欄目 MongoDB 简体版

原文原文鏈接

歡迎你們前往騰訊雲技術社區，獲取更多騰訊海量技術實踐乾貨哦~mongodb

隨着國內服務共享化的熱潮普及，共享單車，共享雨傘，共享充電寶等各類服務如雨後春筍，隨之而來的LBS服務定位問題成爲了後端服務的一個挑戰。MongoDB對LBS查詢的支持較爲友好，也是各大LBS服務商的首選數據庫。騰訊雲MongoDB團隊在運營中發現，原生MongoDB在LBS服務場景下有較大的性能瓶頸，經騰訊雲團隊專業的定位分析與優化後，雲MongoDB在LBS服務的綜合性能上，有10倍以上的提高。
騰訊雲MongoDB提供的優異綜合性能，爲國內各大LBS服務商，例如摩拜單車等，提供了強有力的保障。數據庫

LBS業務特色

以共享單車服務爲例，LBS業務具備2個特色，分別是時間週期性和座標分佈不均勻。小程序

一．時間週期性

高峯期與低谷期的QPS量相差明顯，而且高峯期和低峯期的時間點相對固定。後端

二.座標分佈不均勻

坐地鐵的上班族，若是留意可能會發現，在上班早高峯時，地鐵周圍擺滿了共享單車，而下班時段，地鐵周圍的共享單車數量很是少。以下圖，經緯度（121，31.44）附近集中了99%以上的座標。此外，一些特殊事件也會形成點的分佈不均勻，例如深圳灣公園在特殊家假日涌入大量的客戶，同時這個地域也會投放大量的單車。部分地域單車量很是集中，而其餘地域就很是稀疏。緩存

MongoDB的LBS服務原理

MongoDB中使用2d_index 或2d_sphere_index來建立地理位置索引(geoIndex),二者差異不大，下面咱們以2d_index爲例來介紹。網絡

一．2D索引的建立與使用多線程

db.coll.createIndex({"lag":"2d"}, {"bits":int}))
經過上述命令來建立一個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 表示應該如何理解建立的2d索引，false表示將索引理解爲平面2d索引，true表示將索引理解爲球面經緯度索引。這一點比較有意思，一個2d索引能夠表達兩種含義，而不一樣的含義是在查詢時被理解的，而不是在索引建立時。架構

二．2D索引的理論app

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

很顯然的，一個2bits的精度能把平面分爲4個grid，一個4bits的精度能把平面分爲16個grid。
2d索引的默認精度是長寬各爲26，索引把地球分爲(226)(226)塊，每一塊的邊長估算爲2PI6371000/(1<<26) = 0.57 米。
mongodb的官網上說的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。事實上，平面四叉樹僅存在於運算的過程當中，在實際存儲中並不會被使用到。

插入
對於一個經緯度座標[x,y]，MongoDb計算出該座標在2d平面內的grid編號，該編號爲是一個52bit的int64類型，該類型被用做btree的key，所以實際數據是按照 {GeoHashId->RecordValue}的方式被插入到btree中的。

查詢
對於geo2D索引的查詢，經常使用的有geoNear和geoWithin兩種。geoNear查找距離某個點最近的N個點的座標並返回，該需求能夠說是構成了LBS服務的基礎（陌陌，滴滴，摩拜），geoWithin是查詢一個多邊形內的全部點並返回。咱們着重介紹使用最普遍的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能夠理解爲一個從起始點開始的不斷向外擴散的環形搜索過程。以下圖所示：

因爲圓自身的性質，外環的任意點到圓心的距離必定大於內環任意點到圓心的距離，因此以圓
環進行擴張迭代的好處是：

1）減小須要排序比較的點的個數；
2）可以儘早發現知足條件的點從而返回，避免沒必要要的搜索。

MongoDB在實現的細節中，若是內環搜索到的點數過少，圓環每次擴張的步長會倍增

MongoDB LBS服務遇到的問題

部分大客戶在使用MongoDB的geoNear功能查找附近的對象時，常常會發生慢查詢較多的問題，早高峯壓力是低谷時段的10-20倍，座標不均勻的狀況慢查詢嚴重，瀕臨雪崩。初步分析發現，這些查詢掃描了過多的點集。

以下圖，查找500米範圍內，距離最近的10條記錄，花費了500ms，掃描了24000+的記錄。相似的慢查詢佔據了高峯期5%左右的查詢量

測試環境復現與定位

排查數據庫的性能問題，主要從鎖等待,IO等待,CPU消耗三封面分析。上面的截圖掃描了過多的記錄，直覺上是CPU或者IO消耗性的瓶頸。爲了嚴謹起見，咱們在測試環境復現後，發現慢日誌中無明顯的timeAcquiringMicroseconds項排除了MongoDB執行層面的鎖競爭問題，並選用較大內存的機器使得數據常駐內存，發現上述用例依舊須要200ms以上的執行時間。10核的CPU資源針對截圖中的case，只能支持50QPS。

爲什麼掃描集如此大

上面咱們說過，MongoDB搜索距離最近的點的過程是一個環形擴張的過程，若是內環知足條件的點不夠多，每次的擴張半徑都會倍增。所以在遇到內環點稀少，外環有密集點的場景時，容易陷入BadCase。以下圖，咱們但願找到離中心點距離最近的三個點。因爲圓環擴張太快，外環作了不少的無用掃描與排序。

這樣的用例很符合實際場景，早高峯車輛彙集在地鐵周圍，你從家出發一路向地鐵，邊走邊找，共享單車軟件上動態搜索距你最近的10輛車，附近只有三兩輛，因而擴大搜索半徑到地鐵周圍，將地鐵周圍的全部幾千輛車都掃描計算一遍，返回距離你最近的其他的七八輛。

問題的解決

問題咱們已經知道了，咱們對此的優化方式是控制每一圈的搜索量，爲此咱們爲geoNear命令增長了兩個參數，將其傳入NearStage中。hintCorrectNum能夠控制結果品質的下限，返回的前N個必定是最靠近中心點的N個點。hintScan用以控制掃描集的大小的上限。

hintScan: 已經掃描的點集大小大於hintScan後，作模糊處理。
hintCorrectNum:已經返回的結果數大於hintCorrectNum後，作模糊處理。

該優化本質上是經過犧牲品質來儘快返回結果。對於國內大部分LBS服務來講，徹底的嚴格最近並非必要的。且能夠經過控制參數得到嚴格最近的效果。在搜索過程當中，密集的點落到一個環內，自己距離相差也不會不大。該優化在上線後，將部分大客戶的MongoDB性能上限從單機1000QPS提高了10倍到10000QPS以上。

和Redis3.2的對比

Redis3.2也加入了地理位置查詢的功能，咱們也將開源Redis和雲數據庫MongoDB進行對比。
Redis使用方式：GEORADIUS appname 120.993965 31.449034 500 m count 30 asc。在密集數據集場景下，使用騰訊雲MongoDB和開源的Redis進行了性能對比。下圖是在密集數據集上，在24核CPU機器上，MongoDB單實例與Redis單實例的測試對比。須要注意的是Redis自己是單線程的內存緩存數據庫。MongoDB是多線程的高可用持久化的數據庫，二者的使用場景有較大不一樣。

總結

MongoDB原生的geoNear接口是國內各大LBS應用的主流選擇。原生MongoDB在點集稠密的狀況下，geoNear接口效率會急劇降低，單機甚至不到1000QPS。騰訊雲MongoDB團隊對此進行了持續的優化，在不影響效果的前提下，geoNear的效率有10倍以上的提高，爲咱們的客戶如摩拜提供了強力的支持，同時相比Redis3.2也有較大的性能優點。