<分区>
我有 350,000 个具有纬度和经度值的城市地址，如下所示:
2500 HardToSpellName Street NW(象限)，城市，州，国家/地区
最好的数据结构似乎是一个 JSON 文件，主要是相反的顺序，并让用户按该顺序输入查询:
Country.State.City.Quadrant.StreetType - 所有这些都重复了很多次
然后切换到公民号码数据输入，因为数字很容易拼写；)根据上面的内容，我们将实现查找以在街道名称上填充“自动完成”，因为它容易出现拼写错误。
数据的查询总是一样的，输入一个地址得到纬度/经度结果。
这是个好主意吗？多少记录是合理的？如何将表 (csv) 转换为 JSON 树？
使用 NoSQL 的主要原因是硬件/托管成本较低吗？
最佳答案
我认为最好的办法是使用用户输入将潜在结果集限制为尽可能少的记录。 如果希望用户按此顺序输入搜索词，则可以通过 [Country, State, City, Quadrant, StreetType] 的组合索引来实现。
如果这是第一个也是唯一提供的输入，索引将允许过滤“国家/地区”。如果选择国家并输入“州”，则查询索引会将结果限制为输入的国家和州等组合的记录。一般来说，你拥有的标准越多，你就越能用它来缩小结果范围。要求是您使用一些排序索引，并且只从左侧查询索引属性。
当输入最后一个条件 (StreetType) 时，结果集可能已经非常小，因此您可以将所有街道名称从中返回到应用程序并创建和自动完成输入框。 您可以选择扩展索引，使其也涵盖街道名称。这将允许您有效地检索按字母顺序排列的街道名称列表(和坐标)作为搜索条件。
据我了解，数据可以放在一个平面表中，因为所有记录都具有相同的结构。然后可以在待索引属性上创建排序索引。任何关系数据库都应该支持这一点。
您也可以为此目的使用 NoSQL 文档数据库，它应该也能正常工作。
要确定哪个是最佳解决方案，我认为您还应该考虑您的工作量和其他因素，例如 - 你会更新数据吗？多久更新一次？读取和更新需要事务隔离吗？ - 数据库中应该运行哪些其他操作？ - 您可以接受平面表结构还是您真的需要分层数据、灵活的模式？
关于sql-server - 最快的分层地理地址，最便宜的硬件上的数据查找？ NoSQL 还是 SQL？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25571539/