如何在数据库中存储 8000 亿个 GPS 标记
我需要将用户记录的 GPS 轨迹存储到数据库中.轨道每移动 5 米就会包含一个标记，用于在地图上绘制一条线.我估计有 200 公里的轨道，这意味着 40,000 个 lnlt 标记.我估计最少有 50,000 个用户，每个用户有 20 条 200 公里的轨道.这意味着至少有 400 亿个 lnlt 标记.
I need to store GPS tracks that users record into a database. The tracks will consist of a marker every 5 meter of movement for the purpose of drawing a line on a map. I am estimating 200 km tracks which means 40,000 lnlt markers. I estimate 50,000 users minimum and 20 pieces of 200 km tracks for each. That means at least 40 billion lnlt markers.
这也需要扩展，因此对于 100 万用户，我需要 8000 亿个 GPS 标记的容量.
This needs to scale too, so for 1 million users I need capacity for 800 billion GPS markers.
由于每组 40,000 个标记属于单个轨道，因此我们指的是 1 到 2000 万条记录/组 GPS 轨道.
Since each set of 40,000 markers belong to a single track, we are talking 1 - 20 million records/sets of GPS tracks.
要求:用户将请求在移动应用程序中的 Google 地图上查看这些轨迹.
Requirements: Users will request to view these tracks on top of a Google map in a mobile application.
关系:我目前有 2 张桌子.表一有:[trackid]、[userid]、[comment]、[distance]、[time]、[top speed].
Relations: I currently have 2 tables. Table one has:[trackid], [userid], [comment], [distance], [time], [top speed].
表 2 有 [trackid] [longitude] [latitude]，这是所有 GPS 标记的存储位置.在保持读取性能的同时存储大量 GPS 数据的有效方法是什么?
Table 2 has [trackid] [longitude] [latitude] and this is where all GPS markers are stored. What is an efficient way of storing this volume of GPS data while maintaining read performance?
新信息:
将 GPS 数据存储在 KML 文件中，以便在 Google 地图上将其显示为轨迹，这是一种节省数据库空间的好解决方案.将 KML 压缩到 KMZ(基本上是带有 KMZ 扩展名的压缩 KML)会大大减少文件大小.KMZ 的加载速度比 GPX 快得多，并且可以作为 KML 层与 Google Maps API 集成.查看 Google 提供的此信息 以获得进一步帮助.到目前为止，这似乎是满足预期要求的最佳解决方案.
Storing the GPS data in a KML file for the purpose of displaying them as a track on top of a Google map is a good solution that saves database space. Compressing the KML into a KMZ (basically a zipped KML wit a KMZ extension) greatly reduces file size further. KMZ loads much quicker than GPX and can be integrated with the Google Maps API as a KML layer. See this information from Google for further assistance. This seems to be the best solution so far for the intended requirement.
推荐答案
与往常一样，特定数据库的选择取决于您希望如何存储信息以及您希望如何使用它.因此，在不了解项目的确切要求以及数据关系的情况下，最好的办法是阅读该主题以确定哪种特定产品或存储模型最适合你.
The choice of a particular database, as always, is tied to how you want to store the information and how you want to use it. As such, without knowing the exact requirements of your project, as well as the relationships of the data, the best thing to do would be to do some reading on the topic to determine what particular product or storage model is best suited to you.
一个好的起点是阅读比较数据库的性能和使用的博客(见附件):
A good place to start is reading blogs that compare the performance and uses of the databases (see attached):
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
相关文章