亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

云MongoDB怎么優化讓LBS服務性提升十倍

發布時間:2021-11-03 15:26:15 來源:億速云 閱讀:129 作者:柒染 欄目:云計算

MongoDB怎么優化讓LBS服務性提升十倍,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

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

騰訊云MongoDB提供的優異綜合性能,為國內各大LBS服務商,例如摩拜單車等,提供了強有力的保障。

LBS業務特點

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

一.時間周期性

云MongoDB怎么優化讓LBS服務性提升十倍

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

二.坐標分布不均勻

云MongoDB怎么優化讓LBS服務性提升十倍

坐地鐵的上班族,如果留意可能會發現,在上班早高峰時,地鐵周圍擺滿了共享單車,而下班 時段,地鐵周圍的共享單車數量非常少。如下圖,經緯度(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索引的理論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,索引把地球分為(2^26)(2^26)塊,每一塊的邊長估算為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 Namenear: [ -73.9667, 40.78 ] , // central pointspherical: true, // treat the index as a spherical indexquery: { category: "public" } // filtersmaxDistance: 0.0001531 // distance in about one kilometer}

geoNear可以理解為一個從起始點開始的不斷向外擴散的環形搜索過程。如下圖所示: 由于圓自身的性質,外環的任意點到圓心的距離一定大于內環任意點到圓心的距離,所以以圓 環進行擴張迭代的好處是:1)減少需要排序比較的點的個數2)能夠盡早發現滿足條件的點從而返回,避免不必要的搜索MongoDB在實現的細節中,如果內環搜索到的點數過少,圓環每次擴張的步長會倍增

MongoDB LBS服務遇到的問題

云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輛車,附近只有三兩輛,于是擴大搜索半徑到地鐵周圍,將地鐵周圍的所有幾千輛車都掃描計算一遍,返回距離你最近的其余的七八輛

問題的解決

云MongoDB怎么優化讓LBS服務性提升十倍

問題我們已經知道了,我們對此的優化方式是控制每一圈的搜索量,為此我們為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也有較大的性能優勢。

關于云MongoDB怎么優化讓LBS服務性提升十倍問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

专栏| 永昌县| 新津县| 平邑县| 宁安市| 广平县| 康平县| 朝阳区| 班戈县| 邹平县| 祥云县| 柳河县| 万州区| 大港区| 广丰县| 黄龙县| 历史| 本溪市| 江门市| 盐津县| 平乡县| 柘荣县| 岱山县| 乐业县| 广汉市| 孟州市| 辽阳市| 菏泽市| 饶阳县| 容城县| 疏附县| 共和县| 蓝山县| 哈尔滨市| 垣曲县| 望都县| 措勤县| 平顶山市| 东至县| 页游| 延吉市|