利用mongodb開發lbs應用實踐【轉】

標籤：blog   http   io   ar   os   使用   sp   on   art   

近期作為突擊隊員，與同事一起突擊構建了一個簡單的lbs系統。當前比較主流的做法是使用mongodb，因為其已經封裝了常用的lbs基本操作（如尋找附近的人），功能非常強大，對於開發週期只有一周的項目，mongodb真可謂是救世主，把最重要的需求給完成了，謝天謝地！

mongodb是比較著名的nosql db，想瞭解的同學不妨問問Google或度娘，對於專業問題本人傾向於問Google。本文還參考了這篇文章。我們使用的是目前最新版本的mongodb-2.4.9。

首先從mongodb提供的lbs功能講起：mongodb支援以下幾種查詢：

1.地區內搜尋：所謂地區內搜尋，即列出附近一定範圍內的所有記錄，如baidu地圖的“附近”。mongodb使用$geoWithin命令即可實現此類查詢，其強大之處在於支援矩形地區（$box）、圓形地區（ $center）和多邊形地區（ $polygon）查詢！以圓形地區查詢為例，只需要給出圓心的經緯度和查詢半徑，就可以取到在該地區內的所有記錄，不過返回結果是無序的。

2.尋找附近：尋找附近即將某一個位置附近的記錄按照由近到遠的順序返回，如很多社交app的尋找附近的人。mongodb使用$near命令，輸入中心點的座標即可返回結果，結果是按照距離由小到大排序好的。$near介面比$geoWithin多了一步排序，但對2維座標建索引的話，二者的查詢效率基本相同。

另外還有一個命令是$geoNear，可以認為是$near的升級版，除了返回記錄之外還會返回距離及其他診斷資訊。我們的應用需要計算距離，一開始就想使用這個命令，但是其使用很不方便。很奇怪的，該命令不能像$near和$geoWithin般可以和find命令整合，使用過程中很不靈活，無法完全滿足我們的應用需求。

其次說說距離計算

MongoDB地理位置索引常用的有兩種：1）2d 平面座標索引，適用於基於平面的距離計算。2）2dsphere 幾何球體索引，適用於球面幾何距離運算。追求百分之百的精確，應選擇2dsphere。不過，在座標跨度不太大（如兩千公裡以內），這兩個索引計算出的距離相差幾乎可以忽略不計。關於mongodb實現的2維地理位置索引，可以參考這篇文章，寫的簡單易懂。

接下來說說實踐中碰到的複合索引的使用。因為mongodb是個開源項目，總會有些不完善的地方，而這些問題也只有使用的時候才會碰到。

複合索引即對多個欄位聯合建立索引，假設在一個mongo集合（collection）的記錄含有A和B兩個欄位，我們要查詢A大於0且B大於100的記錄，顯然A、B的複合索引{“A”:1，”B”:1}可以有效提高這類查詢的效率，mongodb也做到了。該查詢用mongo的語言描述為：db.posts.find({ “A”:{$gt:0}, “B”:{$gt:100} } )。但如果我們要得到A大於0且按照B升序排序的記錄，剛才建立的聯合索引就不起作用了。這個查詢用mongo的語言描述為：db.posts.find({ “A”:{$gt:0}} ).sort({“B”:1})。

而且即使對所取記錄總數做限制也無法提高查詢效率。例如我假設複合條件的記錄共有2000條，我只取100條，即db.posts.find({ “A”:{$gt:0}} ).sort({“B”:1}).limit(100)。按我的理解，如果複合索引起作用，不管limit與否都應該很快。但測試下來發現，查詢的時間跟合格記錄總數成正比，即2000條取100條要50ms，而1000條取100條就只要30ms，似乎是不管limit多少，mongo會把所有滿足find條件的記錄全部讀到記憶體，再根據sort的條件進行排序。這排序恰恰是效能的瓶頸所在，如果去除排序，2000條取100條也只要10ms左右，查詢A大於0且B大於100的記錄也是只要100ms。

據老外的分析，這個是mogodb目前的bug，應該會在2.6版本fix掉，希望如此吧。目前也沒有什麼辦法可以最佳化這個問題，只能在find的時候通過更多的限制條件，減少被排序的記錄數目，但在面對實際需求時往往不能這麼做。

所以，此次項目學到的經驗是，開源項目的確有非常強大的功能，幫我們解決了大部分基礎問題，也常常給我們很多驚喜（如mongo對地理資訊查詢的強大而全面的支援）。不過，所謂“天下沒有免費的午餐”，使用開源項目不僅需要學習怎麼用，使用過程中也會遇到一些坑，需要交點學費，所以，要時刻保持謹慎和批判的態度。

利用mongodb開發lbs應用實踐【轉】