我有350000个具有纬度和经度值的城市地址，如下所示：
2500 HardToSpellName Street NW（象限），城市，州，国家
看起来，最好的数据结构应该是一个JSON文件，主要是按相反的顺序，并让用户按以下顺序输入查询：
Country.State.City.Cquadrant.StreetType-所有这些都会重复多次
然后切换到公民号码数据输入，因为数字很容易拼写；）根据以上内容，我们将实现一个查找，以在街道名称上填充"自动完成"，因为它很容易出现拼写错误。
数据的查询总是相同的，一个地址输入得到Lat/Long结果。
这是个好主意吗？有多少记录是合理的？如何将表（csv）转换为JSON树？
使用NoSQL的主要原因是硬件/主机成本较低吗？
我认为最好的想法是使用用户的输入将潜在的结果集限制为尽可能少的记录。如果用户希望按此顺序输入搜索词，则可以通过对[国家、州、城市、象限、街道类型]的组合索引来实现这一点。
如果"国家"是第一个也是唯一一个提供的输入，则索引将允许对其进行筛选。如果选择了Country并输入了"State"，则查询索引会将结果限制为输入的Country和State组合的记录，依此类推。一般来说，你的标准越多，你就可以进一步使用它来缩小结果范围。要求是使用一些排序的索引，并且只查询左侧的索引属性。
当输入最后一个条件（StreetType）时，结果集可能已经很小了，因此您可以将其中的所有街道名称返回到应用程序，并创建并自动完成输入框。您可以选择扩展索引，使其也包含街道名称。这将使您能够有效地检索搜索条件的街道名称（和坐标）的字母列表。
据我所知，数据可以放在一个平面表中，因为所有记录都有相同的结构。然后，可以在要索引的属性上创建排序索引。任何关系数据库都应该支持这一点。
为此，您也可以使用NoSQL文档数据库，它也应该可以正常工作。
为了决定哪种解决方案是最好的，我认为你还应该考虑你的工作量和其他因素，例如。-你会更新数据吗？更新频率有多高？读取和更新是否需要事务隔离？-数据库中还应该运行哪些其他操作？-你能接受平面表结构吗？还是真的需要层次数据、灵活的模式？