我需要将用户记录的 GPS 轨迹存储到数据库中。轨道每移动 5 米就会有一个标记，用于在地图上画一条线。我估计轨道长 200 公里，这意味着 40,000 个 lnlt 标记。我估计至少有 50,000 个用户，每个用户有 20 条 200 公里的轨道。这意味着至少有 400 亿个 lnlt 标记。
这也需要扩展，因此对于 100 万用户，我需要容纳 8000 亿个 GPS 标记的容量。
由于每组 40,000 个标记属于单个轨迹，因此我们讨论的是 1 - 2000 万条记录/组 GPS 轨迹。
要求：
用户将请求在移动应用程序中的 Google 地图上查看这些轨迹。
关系：
我目前有 2 张桌子。表一有：[trackid]、[userid]、[comment]、[距离]、[时间]、[最高速度]。
表 2 包含 [trackid] [longitude] [latitude]，这是存储所有 GPS 标记的位置。在保持读取性能的同时存储如此大量的 GPS 数据的有效方法是什么？
新的信息：
将 GPS 数据存储在 KML 文件中，以便将其显示为 Google 地图上的轨迹，是节省数据库空间的良好解决方案。将 KML 压缩为 KMZ（基本上是带有 KMZ 扩展名的压缩 KML）可进一步大大减小文件大小。 KMZ 加载速度比 GPX 快得多，并且可以作为 KML 图层与 Google 地图 API 集成。从谷歌查看此信息 https://developers.google.com/maps/documentation/javascript/layers#KMLLayers为进一步协助。这似乎是迄今为止满足预期要求的最佳解决方案。
与往常一样，特定数据库的选择取决于您想要如何存储信息以及如何使用它。因此，在不知道项目的确切要求以及数据关系的情况下，最好的办法是阅读有关该主题的内容，以确定最适合您的特定产品或存储模型。
一个好的起点是阅读比较数据库性能和使用的博客（见附件）：
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
