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