目前，在一個部署的應用程序中，我們所有的實體內容都存儲在MongoDB中，我們使用的是內置的蒙戈geoNear命令收集所有誰具有給定半徑內lat和lon性質的實體。然後將此數據集輸入並行化的搜索模塊，並根據用戶的查詢進行過濾。性能足以滿足該應用程序迄今爲止的流量級別。替代MongoDB的GeoNear
使用的真正的基本方法是什麼10gen公司對蒙戈網站：
http://www.mongodb.org/display/DOCS/Geospatial+Indexing/
該方法具有內置的，我明白10gen公司目前正嘗試的幾個問題。
Sorting MongoDB GeoNear results by something other than distance?
Can geoNear in MongoDB return a subset of fields in a document?
https://jira.mongodb.org/browse/SERVER-1982
有問題的客戶正在考慮這一功能的數據架構的改造作爲開發團隊的成長，使內更直觀一點的代碼新的開發者。在解釋了所有內容之後，他們有興趣改變範圍查詢的方法，因爲他們對Mongo中的這個相對較新的特性猶豫不決，因爲它在我們的體系結構中是一個核心組件（因爲它獲得了所有其他過濾器的第一個有限數據集應用）
我很好奇，如果有任何強有力的選擇。作爲負責開發這部分邏輯的人員，我可以想到幾個，但我只能猜測他們的優缺點。後解決此谷歌搜索是我想出：
存儲的對象在蒙戈自己，那麼用的ObjectID在SQL Server上的SQL表的空間座標，支持空間索引關聯。我喜歡這種方法將所有的空間數據放在一個單一的索引中，但是這裏豐富的SQL人才傾向於MySQL，從文檔看來，空間索引的實現看起來很像mongo中的那種。另外，據我所知，我們將只修復MyISAM表格。至於專門的SQL解決方案空間解決方案，我可以在網上找到大多數Postgres和PostGIS的文檔。目前，我們所做的全部工作都是使用橫座標距離計算進行半徑搜索，因此其中一個優勢是支持使用向量和多邊形進行更高級的限制，這可能使我們在將來可以擴展到基於區域的限制。這裏主要的限制是我們根本沒有Postgres的內部人才，而且我不確定這是否會需要新僱用。
查看對象本身的不同NoSQL解決方案，並將位置元數據嵌入其中。 Neo4j似乎在這個部門承諾很多： http://www.oscon.com/oscon2011/public/schedule/detail/19822在文檔中肯定有一些引人注目的例子。
我很好奇，是否有任何一種鍵值存儲解決方案實現空間索引作爲核心任務目標？如果不是，那麼最好的方法是什麼方法來完善職責分工和最大可維護性？