我需要将用户记录的 GPS 轨迹存储到数据库中。轨道将由每 5 米移动一个标记组成，以便在 map 上画一条线。我估计 200 公里的轨道意味着 40,000 个 lnlt 标记。我估计至少有 50,000 个用户，每个用户有 20 条 200 公里的轨道。这意味着至少有 400 亿个 lnlt 标记。
这也需要扩展，因此对于 100 万用户，我需要 8000 亿个 GPS 标记的容量。
由于每组 40,000 个标记都属于一个轨迹，我们说的是 1 - 2000 万条记录/GPS 轨迹集。
要求: 用户将请求在移动应用程序中的 Google map 上查看这些轨道。
关系: 我目前有 2 张 table 。表一有:[trackid]、[userid]、[comment]、[distance]、[time]、[top speed]。
表 2 有 [trackid] [longitude] [latitude]，这是存储所有 GPS 标记的地方。在保持读取性能的同时存储如此大量的 GPS 数据的有效方法是什么？
新信息:
将 GPS 数据存储在 KML 文件中以便在 Google map 上将其显示为轨迹是一种节省数据库空间的好解决方案。将 KML 压缩成 KMZ(基本上是一个带 KMZ 扩展名的压缩 KML)可以进一步大大减小文件大小。 KMZ 加载速度比 GPX 快得多，并且可以作为 KML 图层与 Google Maps API 集成。 See this information from Google为进一步协助。这似乎是迄今为止满足预期要求的最佳解决方案。
最佳答案
一如既往，特定数据库的选择取决于您希望如何存储信息以及如何使用它。因此，在不知道项目的确切要求以及数据关系的情况下，最好的办法是阅读该主题，以确定最适合的特定产品或存储模型你。
一个好的起点是阅读比较数据库的性能和使用的博客(见附件):
关于mysql - 如何在数据库中存储 8000 亿个 GPS 标记，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12825810/