我有35萬點與緯度和經度值城市的地址，如：最快的分層地理地址，在最便宜的硬件上查找數據？ NoSQL或SQL？
2500 HardToSpellName街西北（象限），市，省，國家
這似乎是最好的數據結構將是一個JSON文件大多以相反的順序，並讓用戶按順序輸入查詢：
Country.State.City.Quadrant.StreetType - 所有這些都是重複多次
然後切換到公民數量的數據輸入的數字很容易拼寫;）從上面，我們會執行查找在街道名稱上填充「自動完成」，因爲它容易出現拼寫錯誤。
數據的查詢總是相同的，一個地址輸入獲得經緯度結果。
這是個好主意嗎？有多少記錄是合理的？你如何將表（csv）轉換爲JSON樹？
使用NoSQL的主要原因是硬件/託管成本較低？
我認爲最好的想法是使用用戶的輸入將潛在結果集限制爲儘可能少的記錄。 如果用戶需要按此順序輸入搜索詞，則可以通過[國家，州，城市，象限，街道類型]的組合索引來實現。
如果這是所提供的第一個也是唯一的輸入，該索引將允許過濾「國家」。如果選擇國家並輸入「國家」，查詢索引將限制結果爲輸入的國家和州等組合的記錄。一般來說，你有更多的標準，你可以用它來進一步縮小結果。要求是你使用了一些有序的索引，只查詢左邊的索引屬性。
當輸入最後一個標準（StreetType）時，結果集可能已經很小，因此您可以將所有街道名稱返回到應用程序並創建並自動完成輸入框。 您可以選擇擴展索引，以便覆蓋街道名稱。這將允許您有效地檢索搜索條件的街道名稱（和座標）的字母列表。
據我所知，數據可以放在一個平坦的表中，因爲所有的記錄具有相同的結構。然後可以在要被索引的屬性上創建一個排序索引。任何關係數據庫都應該支持這一點。
您也可以爲此使用NoSQL文檔數據庫，並且它也應該正常工作。
要確定哪個是最佳解決方案，我認爲您還應該考慮工作量和其他因素，例如， - 你會有更新的數據和頻率？你需要事務隔離來讀取和更新嗎？ - 應該在數據庫中運行哪些其他操作？ - 你可以住在一個平坦的表結構，還是你真的需要數據，靈活的模式？
350k個記錄？對於關係數據庫來說，這是** NOTHING **，除非您的數據庫服務器是8088-4.77mhz/640k機器 – 2014-08-29 15:36:11