全球（不仅仅是美国）的邮政编码（ZIP）优化数据结构（不是SQL，CSV或Google API），用于长期和纬度检索

我不相信有这样一种“快速”的方式来做到这一点。我为加拿大邮政编码构建了一个地理编码API，我们搜索的方式是有两个邮政编码索引 - 一个按照格式排序，另一个按经度排序。你可以做一些球形几何体并开发一个适合给定半径范围内的所有东西的边界“盒子”，但是你仍然需要返回并使用Vincenty或Haversine进行点到点距离测量，或者选择您选择的算法来确定原点之间的距离以及您找到的每个邮政编码。 有了世界范围的数据库，你的数学变得复杂，因为你可以穿过经络和赤道。 你需要某种编码方案，让你在弧度下工作，因为这是大多数距离计算hueristics所需要的。     

任何支持二维索引的数据库引擎都可以很快完成这个...而mysql支持无限维度以及我知道...这很简单..你使用二维索引将结果集限制为合理大小非常快......然后你用高精度计算算法检查你的结果集，如果你需要......不难...除非你可能需要或两个列表，如果它们穿过180 / -180经度线 制作2d索引很简单....索引（纬度，经度）...该索引仅适用于纬度或纬度，经度对...它不适用于经度...如果你想要一个额外的索引经度指数（经度）....如果我关心它，我选择一个粗略的估计方形并绕过角落。 ... 如果你有一个拉链或城市开始...邮政编码只是一个索引...没有问题使这种情况发生得很快..只需使用索引索引（zip）...如果您的硬盘驱动器是太慢了，得到一个固态驱动器来消除寻道时间..或者使用一个巨大的ram并缓存整个表...这不是一个难以解决的问题 如果这对你来说不够快，使用someones服务将无济于事，因为你有网络开销...你必须直接在ram / ssd中保存你的数据并构建你自己的2-d / 1-d索引系统如果你需要它（不是很难）......这条路线可能会超过sql 10倍左右，因为sql引擎有很多开销......我想有人可能会提供一个在你自己的机器上运行的服务，但是实际上，这不会击败sql到目前为止，因为你仍然需要通过一堆hoopdiloops来向他们的服务提出请求。带有固态驱动器的sql和2-d索引将被快速诅咒你不应该自己处理数据，除非你是邮局，用一台服务于数据的机器每秒排序10,000件邮件。那么你将不得不编写自己的数据管理例程。