我們新開發了一個電商平臺，需要實現附近的店鋪功能，經過預研，覺得沒有必要採用mongodb的地理位置查詢功能，因爲涉及數據同步，還有聯合索引的問題。直接用MySQL5.7內置的距離計算功能就可以滿足大規模計算距離的需求。
計算附近的店鋪時侯，一般的需求是傳入用戶的座標，需要計算出附近的店鋪，按照用戶和店鋪的距離排序返回前端。在成千上萬家店鋪選擇附近的店鋪就涉及效率的問題了。最好的方式是先找到附近的店鋪，然後再在選定的店鋪範圍內計算距離，這樣就能大幅減少計算量。業界採用的是geohash，首先在獲取店鋪座標時候，就計算出店鋪的geohash,在用戶傳入座標後，也計算出用戶的geohash和他周圍8個區域的geohash，然後看店鋪如果在用戶周圍的geohash範圍內，才計算店鋪和用戶之間的距離。這裏有個問題，如果用戶在一個周圍都是店鋪的區域，那麼檢索的範圍可能比較小就可以拿到用戶每次翻頁所請求店鋪數了，但是如果用戶在一個周圍店鋪不多的區域內，就需要檢索一個比較大的範圍纔可以拿到用戶每次翻頁所請求的店鋪數。這裏就涉及geohash的精度問題了，geohash位數越高，所表示的範圍越小，距離用戶越近，反之越遠。店鋪需要預先計算一個精度比較高的geohash，如果想要取比較大的區域，只需要店鋪的geohash like用戶的geohash前幾位就可以了.每次用戶請求的時候,前端需要告訴後臺用戶的gps座標,其他過濾條件,之前已經返回給用戶的商鋪id列表,後臺按照用戶的gps座標按照7位精度計算出用戶周圍的9個geohash區域,加上過濾條件和不需要計算的店鋪id列表,查詢一下附近的店鋪數,如果店鋪數小於前端請求的數據條數的2倍(這裏取2倍是考慮過的,假設店鋪是平均分佈的,用戶的位置比較極端,恰好在他所在的geohash的角上,這樣距離他比較近的點就在它周圍的4個區域內,其他的5個區域的點離他都比較遠,從區域的數量上來看是4:5,接近1:1吧,所以就選了2倍,應該差不多),就將計算的geohash列表的位數縮小一位,再去查詢用戶周圍的店鋪數,如果滿足條件就退出,否則一直計算到4位精度,然後用最後拿到的geohash列表和過濾條件真正去計算用戶周圍的店鋪和距離用戶的距離,返回給前端.這樣能最小化數據庫計算和排序的壓力.即使這樣,作爲數據庫仍然是壓力比較大的,在這裏採用多從庫可以解決併發的問題.至此,我們實現了基於Mysql5.7查找附近的店鋪,計算量壓縮到了極致,並發達到了無限.