1樓：老雕蟲
用資料庫空間索引看起來顯然是最簡單的解決方案，但我們要明白當資料達到一定量級，資料庫的效率和擴充套件性都將遇到瓶頸。典型的例子就是打車軟體搜尋附近車輛，車輛的座標實時變化，像滴滴或者uber這個併發量，是無法用資料庫滿足的。
目前比較常用的方案是將空間座標的geohash值存到一組高可用的redis分布式集群裡，然後利用key*做匹配。但key*的效率仍然存在一定的問題，各家公司都對此有一系列的優化方案。
2樓：思念
geohash的演算法可行，這需要插入或更新點座標時構建對應的樹。可以建議使用kd樹，效率會更高點。快速全球索引的設計思想是基於geohash的，效率也不錯。
3樓：Baggio
這是我見過最簡潔最有效的方案，PostgreSQL+PostGIS，你值得擁有。
4樓：番薯
geohash是一種方法，但是精度不高，我們一般首選支援空間查詢的資料庫，如mongodb，sphinx。但是大併發的需求，我們自己寫中介軟體，用r樹實現，直接支援按範圍查詢和topN查詢
5樓：
以前用mysql，通過距離計算乙個正方形區域，搜尋座標點範圍內的記錄，挨個計算距離，這樣比較麻煩，計算完還要排序什麼的。
現在採用mongo，很方便，返回的就是按距離排序的
6樓：南極
有現成的高可用方案。
PostgreSQL + PostGIS
PostGIS — Spatial and Geographic Objects for PostgreSQL
7樓：李陶冶
可以看看RTree這個資料結構，不少資料庫索引也是採用這種結構。比較適合算曼哈頓距離。歐氏距離也能用。對於找最近的100人這種查詢，配合二分就可以了。
實際應用中，不會有太特殊的例子（比如：你在中心，周圍100w人眾星捧月般的呆在離你1km的地方），用不上Voronoi圖這種大招。
8樓：jiaao yu
用經緯度做索引，
先粗算，比如把經緯度差一以上的全去掉，where latitude>y-1 and latitudex-1 and longitude 再小範圍概算，使用類似這樣的公式 order by abs(longitude -x)+abs(latitude -y) limit 100;
最後顯示時再精確計算使用類似這樣的公式:(2 * 6378.137* ASIN(SQRT(POW(SIN(PI()*(y-lat)/360),2)+COS(PI()*x/180)* COS(lat * PI()/180)*POW(SIN(PI()*(x-lng)/360),2))))。
前兩項在資料庫端計算，後一項在應用伺服器端計算即可。
9樓：呂力
按位置進行mysql的記憶體表建設，無需使用mc！因為mc是hash模式，mysql可以使用邏輯比較。
mongodb不是效能最優的選擇！速度還是不錯的！
10樓：朱佳祺
利用資料庫的空間索引。其實對於「一般的」lbs應用，mongodb的空間索引足夠簡單和強大。
傳送門。http://www.
mongodb.org/display/DOCS/Geospatial+Indexing我們在生產環境用過這個。
但是如果你是想算某乙個時間段內某乙個區域覆蓋範圍有多少人而不是從近到遠找100個人，光是mongo可能在大資料量的時候不太夠，到時候就要自己想辦法拉。
android端與伺服器端RSA雙向加密問題
1 分成兩部分，使用對稱金鑰加密的密文 A 和使用公鑰加密的對稱金鑰 B 一起傳送給服務端 2 服務端使用私鑰解密B得到對稱金鑰 3 使用對稱金鑰來解密密文A，從而得到內容。 記住 用對方的公鑰加密是為了保密，這個只有對方用私鑰能解用自己的私鑰加密是為了防抵賴，能用我的公鑰解開，說明這是我發來的，不...
Java伺服器端有比spring還優秀的框架嗎
穿越 有，但是沒spring全家桶方便和齊全。而且spring已經快成了行業事實標準了，使用者基礎太龐大，即使有更好的但是沒有推廣開來，也不會有太多人知道，或者僅限於企業內部使用。 PrimaryK 全面優秀的應該沒有,不然也不會大一統.部分優秀的還是有一些的,比如vert.x.簡單的非同步程式設計...
好的伺服器端 Node js 日誌方案應該考慮和解決哪些問題
高效能 是乙個大前提,當然什麼是高效能,這又是比較主觀的看法 採集的話,感覺可以交給 ELK 之類的東西,日誌庫專注自己就好了 itlr 乙個非常輕量的 Node.js 伺服器端框架 裡是沒有必要去關心logging的，讓使用框架的人自己去整合就行了，除非你能作出特別好的封裝和抽象。 最初團隊有精力...